The Burn-Rate Problem: Why AI Agents Are So Expensive to Run

Table of Contents

• The Number Nobody Puts on the Slide
• Why Agents Cost So Much More Than Chatbots
• The Anatomy of an Agent's Compute Bill
• Inference Is the Obvious Cost
• The Hidden Multipliers: Retries, Context, and Tool Calls
• How Burn Rate Distorts GaaS Funding
• The Pricing Trap: When Per-Outcome Billing Backfires
• What Actually Brings the Burn Down
• Insights Most People Overlook
• References

The Number Nobody Puts on the Slide

Walk into a GaaS pitch in 2026 and you'll hear about pipeline, net revenue retention, design partners, and the unstoppable march toward autonomous work. What you almost never hear, unprompted, is the cost to serve a single completed task.

That silence is the story. A traditional SaaS company spends roughly 20 to 30 cents to deliver a dollar of revenue once it's at scale, which is why the category supports 75 to 85 percent gross margins. Agent companies routinely run their cost of goods at 40, 50, sometimes 60 percent of revenue. I've seen vertical agent startups posting triple-digit growth that, when you finally pry the gross margin out of them, are operating closer to a logistics business than a software one.

This matters more than founders want to admit. Burn rate isn't just a finance footnote here. It's structural. When every customer interaction triggers a chain of expensive model calls, growth and cost scale together in a way they simply don't for a company shipping bits off a server it already paid for.

Why Agents Cost So Much More Than Chatbots

The mental model a lot of investors carry over from the early LLM wave is wrong. A chatbot is one prompt, one response. Cost is bounded and predictable. You ask, it answers, the meter stops.

An agent is a different animal. It plans, it acts, it observes the result, and then it decides what to do next, looping until the job is done or it gives up. Each turn of that loop is at least one model call, often several. A moderately complex agent task, say reconciling an invoice discrepancy or triaging a support ticket end to end, can fire off anywhere from a handful to a few hundred model calls before it produces a single billable outcome.

That's the core of the burn-rate problem. You're not paying for one inference. You're paying for the entire deliberation, including the dead ends. And because agents are designed to be thorough rather than cheap, they tend to over-reason. A human would glance at a record and move on. An agent re-reads the context, double-checks itself, calls a tool to verify, and re-reads again. Reliability and cost are in direct tension, a theme that runs through the entire reliability conversation in this cluster.

The Anatomy of an Agent's Compute Bill

To understand why the burn is so stubborn, you have to break the bill into its parts. Most of it hides in places that never show up in a casual cost estimate.

Inference Is the Obvious Cost

Start with the visible line item: tokens. Every model call consumes input tokens (the prompt, the context, the instructions, the tool definitions) and output tokens (the model's response). Frontier-model pricing has fallen hard over the past two years, and the Anthropic model pricing documentation and equivalent provider pages make the per-token math look almost trivial in isolation.

The trap is that agents are token gluttons on the input side. A single agent step might carry tens of thousands of input tokens just to remind the model what it's doing, what tools it has, and what happened in prior steps. Output tokens are usually the smaller half. People budget for the answer and forget that the agent re-reads the entire situation on every single turn. Multiply that by dozens of turns and the input cost dominates.

The Hidden Multipliers: Retries, Context, and Tool Calls

This is where the bill quietly doubles.

Retries are the first multiplier. Agents fail mid-task constantly: a tool returns a malformed response, an API times out, the model hallucinates a step. Good agent design retries, sometimes several times, sometimes escalating to a more expensive model. Every retry is full price.

Context accumulation is the second. As an agent works, its context window grows. By turn twenty it may be dragging a small novel of accumulated history through every call. Cost per turn rises as the task progresses, so the longest, hardest tasks (the ones customers value most) are also the most expensive to serve. Worse, they're the ones most likely to fail and retry.

Tool calls are the third. Each tool a vertical agent uses, a database query, a CRM write, a code-execution sandbox, carries its own infrastructure cost on top of the model calls that decide to invoke it. Companies running agents that write and execute code are effectively paying twice: once for the reasoning and once for the compute the reasoning spins up. Andreessen Horowitz has written about how this layered cost structure makes agent unit economics fundamentally different from classic SaaS, and that framing is worth sitting with.

How Burn Rate Distorts GaaS Funding

Here's where the cost problem becomes a market problem, which is the real concern for this beat.

Investors evaluating agent companies are still, by and large, using SaaS reflexes. They look at growth, retention, and ARR, and they extrapolate margins they assume will arrive at scale. But agent margins don't necessarily improve with scale the way SaaS margins do. SaaS gets cheaper per customer as fixed engineering costs amortize. Agents have a large variable cost component baked into every transaction. More usage means more inference means more spend. The flywheel that saved SaaS doesn't spin the same way here.

This creates a dangerous gap between the metrics that win funding rounds and the metrics that determine survival. A startup can grow revenue 4x while its compute bill grows 4x right alongside it, and on a topline-only slide that looks like a rocket ship. The McKinsey analysis of the economic potential of generative AI is bullish on the value agents can create, but value created and margin captured are not the same line. The companies that confuse the two are exactly the ones at risk in a tighter capital environment, the kind of crunch that shows up in the bridge-round and down-round conversations elsewhere in this cluster.

The honest read: a non-trivial slice of well-funded agent startups are subsidizing their own compute to show growth, betting that token prices fall faster than their burn rises. Sometimes that bet pays. Sometimes it just delays the reckoning to the next round, at a worse valuation.

The Pricing Trap: When Per-Outcome Billing Backfires

GaaS sold the market on outcome-based pricing: pay per resolved ticket, per qualified lead, per closed book. It's a beautiful pitch because it aligns price with value. It's also a quiet way to transfer the burn-rate risk from the customer onto the vendor's balance sheet.

When you charge per outcome, you've fixed your revenue per task but not your cost per task. A task that takes the agent three clean calls and a task that takes forty calls with six retries both pay you the same. You eat the difference. And the messy, expensive tasks are disproportionately common because the easy ones often didn't need an agent in the first place.

The result is a margin distribution that's wildly uneven across customers. A handful of power users running pathological workloads can quietly destroy the unit economics of an otherwise healthy book. Founders who don't instrument cost-per-outcome at the customer level often don't discover this until a board meeting where someone finally divides total compute spend by total outcomes delivered and the room goes quiet.

This is why the revenue-quality and revenue-durability questions in this beat matter so much. Usage-based revenue can look fantastic while concealing that your most active customers are your least profitable ones.

What Actually Brings the Burn Down

The good news is that burn rate is an engineering problem as much as a market one, and the levers are real.

Model routing is the biggest. Not every step needs the smartest, most expensive model. Mature agent systems cascade: a small, cheap model handles classification and simple steps, escalating to a frontier model only when the task genuinely demands it. Done well, routing can cut inference cost by half or more without meaningfully hurting quality.

Caching is the second lever, and it's underused. When agents repeatedly send the same system prompts, tool definitions, and context preambles, prompt caching lets providers charge a fraction for the repeated portion. For agents that re-send large static context on every turn, caching attacks the exact part of the bill that hurts most.

Then there's the unglamorous work: shortening context windows aggressively, summarizing history instead of carrying it raw, capping retry loops, and setting hard budgets per task so a runaway agent can't burn $40 chasing a $2 outcome. The teams winning on margin treat compute as a first-class product constraint, not an afterthought. They monitor cost-per-outcome the way a SaaS company monitors churn.

And falling token prices help, genuinely. The per-token cost of frontier inference has dropped by an order of magnitude in a remarkably short window, and there's no sign that curve has flattened. But betting your entire business model on continued price collapse is a strategy, not a guarantee. The companies that will still be standing are the ones that get their burn under control assuming prices stay flat, and treat further drops as upside rather than oxygen.

Insights Most People Overlook

The cheapest agent is often the most reliable one, not despite cost discipline but because of it. Teams that obsess over minimizing model calls are forced to design tighter, more deterministic workflows. That discipline reduces the surface area for hallucination and runaway loops. Cost optimization and reliability optimization turn out to be the same project wearing two hats.

Gross margin in GaaS is a moving target tied to someone else's pricing decisions. Unlike SaaS, where you control your cost base, an agent company's COGS is hostage to foundation-model providers. A single provider price change, up or down, can swing your margins overnight. That's a category of risk SaaS investors have never had to underwrite, and most still don't model it.

The most expensive customers are usually invisible until you instrument per-outcome cost. Aggregate gross margin hides a brutal distribution. A company can show a respectable blended 55 percent margin while a fifth of its customers are served at a loss. Without per-customer, per-outcome cost telemetry, founders are flying blind on the exact metric that decides whether scaling helps or hurts them.

Outcome-based pricing quietly converts a software company into an insurance company. When you guarantee a price for a variable-cost task, you're underwriting workload risk. The discipline you need is actuarial, not just product: understand the distribution of task difficulty, price for the tail, and refuse the workloads you can't serve profitably. Almost nobody frames it this way, and it's the framing that matters most.

Burn rate is the real moat killer, not competition. The agent graveyard won't mostly be filled with companies that lost to a better product. It'll be filled with companies that grew into a cost structure they couldn't outrun, ran out of runway mid-pivot, and couldn't raise because the margins finally showed up in diligence. Compute discipline isn't a finance concern bolted on at Series B. It's existential from day one.

References

• Anthropic, Model Pricing Documentation
• Andreessen Horowitz, The Economics of AI Agents
• McKinsey, The Economic Potential of Generative AI: The Next Productivity Frontier