The $0.02-Per-Email Math: Prompt Token Economics at Outbound Scale

There is a conversation happening inside every growth team running AI-personalized outbound, and it has nothing to do with messaging or targeting or deliverability. The subject is cost per email.

When you are sending 500 emails a month, the unit economics of your prompts do not matter. The API bill is a rounding error on your total outbound spend. At that volume, you could run the most bloated, inefficient prompt imaginable and the financial impact would be invisible. Most teams never move past this stage, which is why most teams never develop any intuition for prompt economics.

But at 10,000 emails a month, the math changes completely. The difference between a well-structured prompt that costs $0.02 per email and a poorly structured one that costs $0.08 per email is $600 a month. That is $7,200 a year. At 50,000 emails a month, the same gap becomes $36,000 annually. These are not theoretical numbers. I have seen outbound teams burning five figures a year on prompt inefficiency without realizing it, because nobody on the team understood that prompt engineering at scale is a finance discipline, not a creative one.

The teams that figure this out early build a structural cost advantage into their outbound engine. The ones that do not end up subsidizing their competitors’ margins.

Why most prompts are expensive

Why most prompts are expensive reframed as system design.

The fundamental unit of cost in any LLM API call is the token. Tokens map roughly to word fragments: a typical English word is about 1.3 tokens, and both the input you send and the output you receive get billed. The pricing varies by model, but the principle is universal. More tokens in, more money out.

The problem is that most outbound prompts are written for clarity to the human author, not for efficiency at the token level. A typical personalization prompt looks something like this: a long system prompt explaining the company, the product, the target persona, the tone guidelines, the formatting rules, and the compliance constraints, followed by the prospect-specific data, followed by the generation instruction. That system prompt might be 800 to 1,200 tokens. It gets sent identically with every single API call. At 10,000 emails a month, you are paying for those same 1,000 tokens 10,000 times.

This is the most common source of waste. The static portion of your prompt, the part that never changes between calls, is often the largest portion of your total token consumption. And most teams treat it as free because they wrote it once.

Over-specification is the next culprit. Teams include instructions the model does not need because they are guarding against failure modes that occur in 1% of outputs. “Do not use exclamation marks. Do not mention competitors by name. Do not make claims about ROI without data.” Each of these instructions consumes tokens on every call to prevent something that rarely happens. At scale, you are better off catching those edge cases in a post-generation filter and removing the instructions from the prompt entirely.

Then there is redundant context. Prospect data often includes fields the model does not use. Full LinkedIn bios when only the job title matters. Complete company descriptions when only the industry and headcount are relevant. Every unused field is dead weight on the token bill.

The prompt caching gap

There is a feature available from every major LLM provider that most outbound teams either do not know about or have not implemented. It goes by different names, but the concept is the same: prompt caching. The idea is simple. If you are sending the same system prompt with every API call, the provider can cache that static prefix and charge you a fraction of the normal rate for those cached tokens. The savings range from 50% to 90% depending on the provider and the cache hit rate.

At outbound scale, this stops being a mere optimization and becomes a structural cost reduction. If your system prompt is 1,000 tokens and you send 10,000 emails a month, you are consuming 10 million tokens on the static portion alone. With prompt caching, the effective cost of those tokens drops by 75% or more after the first call in each cache window.

The implementation is not complex. You structure your API calls so that the static portion of the prompt (system instructions, company context, tone guidelines) comes first, and the variable portion (prospect data, specific generation instructions) comes after. The provider caches the prefix and only charges full price for the variable suffix. Most teams could implement this in an afternoon.

The reason most teams have not is that the person writing the prompts is usually not the person paying the API bill. The growth marketer who designs the outbound sequence thinks in terms of messaging quality. The finance team sees a line item for “AI tools” and assumes it is fixed. Nobody is doing the per-unit cost analysis that would reveal the waste, because at the organizational level, the bill looks like one number, not 10,000 individual transactions.

Structural prompt optimization

Beyond caching, there are specific techniques for reducing token consumption without degrading output quality. I think of these as structural optimizations because they change the architecture of the prompt rather than the content.

The first is prompt compression. Most natural-language instructions can be shortened significantly without changing the model’s behavior. “You are a professional sales development representative writing personalized cold emails for a B2B SaaS company that sells workflow automation to mid-market operations teams” contains useful context, but most of it can be encoded in a shorter format. A compressed version might read: “Role: SDR. Company: B2B SaaS, workflow automation. Target: mid-market ops leaders.” The model interprets both identically. The second version is 60% fewer tokens.

The second technique is output length control. If you need a three-sentence email, say so explicitly. Without length constraints, models tend to generate longer outputs than necessary, and you pay for every token of output. A simple instruction like “respond in exactly 3 sentences, under 75 words” saves meaningful output tokens at scale.

The third technique is template decomposition. Instead of generating the entire email from scratch every time, you can pre-write the structural elements (greeting format, sign-off, CTA) and only use the model to generate the personalized middle section. This reduces both input and output tokens because the model is doing less work per call.

The fourth is few-shot example pruning. Many prompts include three to five example outputs to guide the model’s style. Each example adds hundreds of tokens to every call. In most cases, one well-chosen example performs identically to five. Test this empirically. If one example produces the same quality distribution as three, you just cut your per-call cost by a measurable percentage.

The open-source cost floor

For teams operating at serious scale, there is a more aggressive cost reduction available: running open-source models instead of commercial APIs. Models like Mistral and Llama have reached a quality level where they handle the majority of GTM text generation tasks competently. They are not as good as frontier models at complex reasoning or highly nuanced writing, but outbound email personalization doesn’t need a frontier model. At its core it is pattern-matching and template-filling, the kind of task mid-tier models handle well.

The economics are straightforward. A commercial API might charge $3 to $15 per million input tokens depending on the model. Running an equivalent open-source model on rented GPU infrastructure can bring that cost below $0.50 per million tokens. At 10,000 emails a month with a 1,500-token average prompt, you are processing 15 million tokens monthly. The difference between $3 per million and $0.50 per million is $37.50 versus $7.50 per month on raw compute. That gap widens with volume.

The tradeoff is operational complexity. You need someone who can deploy and maintain a model inference endpoint, handle scaling, and monitor quality. For a team sending 10,000 emails, the API is almost certainly the right choice because the operational overhead of self-hosting exceeds the savings. At 100,000 emails or above, the calculation flips. The savings justify the infrastructure investment, and you gain additional benefits: no rate limits, no dependency on a third-party provider’s pricing changes, and complete control over your data pipeline.

The middle path that many teams are settling into is a tiered approach. Use a small, cheap model (or a self-hosted one) for the 80% of emails that require simple personalization: name, company, role, one relevant detail. Route the remaining 20%, the high-value prospects that warrant more sophisticated personalization, to a frontier model. This hybrid architecture captures most of the cost savings while preserving quality where it matters.

Building the measurement layer

Building the measurement layer as a maturity path.

None of these optimizations matter if you cannot measure them. And this is where most outbound teams fall down. They can tell you their reply rate and their booking rate, but they cannot tell you their cost per generated email, their average tokens per call, or their cache hit rate.

The measurement layer does not need to be complex. At minimum, you want four metrics tracked per prompt variant: average input tokens, average output tokens, cost per call, and output quality score (measured by whatever downstream metric you care about, whether that is reply rate, positive sentiment rate, or booking rate). With those four numbers, you can make informed decisions about every optimization.

The workflow looks like this. You establish a baseline by measuring your current prompt’s token consumption and cost per email. You implement one optimization at a time, whether that is caching, compression, example pruning, or model swapping. You measure the impact on both cost and quality. If cost drops and quality holds, the optimization stays. If quality drops, you measure whether the cost savings justify the quality loss based on downstream conversion.

This is boring, incremental work. It is also the kind of work that separates outbound operations running on tight margins from the ones hemorrhaging cash on a line item nobody examines.

The compound effect of prompt economics

The reason I keep coming back to this topic is that prompt economics compound in a way that most growth expenses do not. When you reduce your cost per email from $0.08 to $0.02, that savings applies to every email you send from that point forward. As your volume grows, the absolute savings grow proportionally. A team that optimizes their prompts at 10,000 emails a month and then scales to 50,000 emails a month captures five times the savings without doing any additional optimization work.

Compare this to other outbound cost levers. Negotiating a better rate with your email infrastructure provider saves you a fixed amount. Better deliverability reduces waste but does not change the cost of generation. A better copywriter improves quality but does not scale with volume. Prompt optimization is one of the few investments in outbound infrastructure that pays more as you grow.

There is also a competitive dimension. If your cost per email is $0.02 and your competitor’s is $0.08, you can afford to send four times as many emails for the same budget. Or you can spend the same amount and pocket the margin. Or you can invest the savings into better data enrichment, better targeting, or higher-quality personalization on your top-tier prospects. The cost advantage creates strategic flexibility that compounds over time.

What this looks like in practice

What this looks like in practice translated into operating choices.

I will make this concrete. A team I worked with was spending roughly $2,400 a month on API costs for their outbound personalization engine, generating about 30,000 emails. Their prompts were well-written from a messaging perspective but had never been optimized for token efficiency.

We made four changes over a two-week period. First, we implemented prompt caching, which cut the effective cost of their system prompt by about 80%. Second, we compressed their system prompt from 1,100 tokens to 450 tokens without changing the output quality. Third, we pruned their few-shot examples from four to one. Fourth, we added explicit output length constraints.

The result was a drop from roughly $0.08 per email to just over $0.02. Monthly API spend went from $2,400 to about $650. The quality metrics, reply rate and positive response rate, did not move. The team had been paying a 4x premium for identical output because nobody had thought to optimize the prompts for cost.

That $1,750 monthly savings is $21,000 a year. Not life-changing for a well-funded company, but meaningful for a startup running outbound on a budget. And the savings scaled linearly when they grew to 50,000 emails three months later. At the old rate, that would have cost $4,000 a month. At the optimized rate, it cost just over $1,000.

Prompt engineering is an economics problem

Most of the discourse around prompt engineering focuses on getting better outputs. More detailed, more creative, more accurate. At the individual level, this makes sense. You want the best possible result from each interaction.

At the systems level, prompt engineering is an economics problem. The quality of each individual output matters less than the cost-adjusted quality across millions of outputs. An email that is 95% as good at 25% of the cost is a better business decision than a perfect email at full price, every time, at every scale.

The teams that internalize this build their prompt development process around cost-quality tradeoff curves instead of pure quality maximization. They test cheaper models before expensive ones and measure token consumption alongside output quality. The prompt library becomes a cost center to be optimized, not a creative asset to be perfected.

This is not a popular framing in a world that celebrates the artistry of prompt engineering. But at outbound scale, the art is in the economics.