Unit Economics Teardown: What a Coding Agent Actually Costs at Scale

Table of Contents

• The unit we're actually measuring
• Anatomy of a single coding task
• Building the cost stack from the bottom up
• The tail is the business
• What scale does to the numbers
• Pricing against a moving cost base
• A worked margin example
• Insights Most People Overlook
• References

The unit we're actually measuring

Before you can tear down the economics of a coding agent, you have to decide what one unit is. For a SaaS company the unit is obvious and boring: a seat, billed monthly. For an agentic AI-as-a-service product it is neither obvious nor boring, and getting it wrong poisons every downstream number.

The cleanest unit for a coding agent is the completed task: one bounded request that ends in a verifiable result. "Open a pull request that makes the failing test pass." "Migrate this file from JavaScript to TypeScript." "Find and fix the null-pointer crash in the checkout flow." Each has a clear start, a clear definition of done, and, critically, a binary outcome you can check. That binary check is what separates a coding agent from a chat product, and it's why coding is the canonical proving ground for the whole GaaS category. You can run a test suite. You cannot run a test suite on "write me a nice email."

So the unit is the completed task, and the number we want is cost-per-completed-task. Hold onto the word completed. It is doing enormous work, because the agent does not complete every task it starts, and the failures are not free.

Anatomy of a single coding task

Watch what happens when a developer types "the build is broken, fix it" and hits enter. A naive mental model says: the agent reads the error, writes a patch, done, maybe two model calls. The real trace looks nothing like that.

A production coding agent typically runs a loop. It plans, it gathers context (reading files, grepping the repo, sometimes pulling documentation), it proposes a change, it runs something to check the change, it reads the result, and it decides whether it's done or needs another pass. Each turn of that loop is at least one model call, and most turns drag a pile of input tokens along with them because the agent re-sends conversation history and file contents on every step.

Here's the part the pricing page never mentions. Anthropic's own guidance on building effective agents describes the agent as a model running tools in a loop until it judges the task complete, and "until it judges complete" is an open-ended number of iterations. For an easy task that's three or four turns. For a gnarly one it's twenty, plus a few abandoned branches where the agent tried an approach, ran the tests, saw red, and backed out. Every one of those dead-end branches burned tokens and produced nothing the customer can see.

Then there's the reasoning overhead. Modern coding agents lean on extended "thinking", internal token generation the model does before it commits to an answer. Those thinking tokens are billed like any other output tokens, and on a hard debugging task they can dwarf the visible response. You pay for the agent's deliberation whether or not the deliberation was any good.

Building the cost stack from the bottom up

Let's put real layers on this. For a single completed coding task on a frontier model, the cost stack looks roughly like this, from largest contributor down:

1. Input tokens, re-sent every turn. This is usually the biggest line, and it's the one people underestimate most. If your agent re-feeds a 40,000-token context on each of twelve loop iterations, you've billed ~480,000 input tokens before a single line of output. Prompt caching claws a lot of this back, the cached read is a fraction of the full input price, but only if the agent's context is structured so the stable prefix actually stays stable. Many agent frameworks accidentally invalidate the cache every turn by reordering messages.

2. Output and thinking tokens. Generated patches are small; the reasoning that produced them often isn't. Output tokens are priced several times higher than input tokens on most frontier models, so even a modest volume of thinking tokens punches above its weight.

3. Tool-call round-trips. Each file read, test run, and shell command is cheap on its own, but they compound, and every tool result gets fed back into the model as more input tokens next turn. Tool calls don't just cost the tool; they inflate the context.

4. Retrieval and embeddings. If the agent does any semantic search over the codebase, you're paying for embedding calls and a vector store. Small per task, real at volume.

5. Orchestration compute. The sandbox the agent runs code in, the container holding the repo, the queue, the logging. This is the part GaaS operators routinely forget to attribute, and it's the cloud-style COGS that the category still hasn't learned to model well.

Notice that the frontier model API is the headline cost but rarely the only cost, and that the structure of your agent loop, not the per-token price, decides which layer dominates.

The tail is the business

Average cost-per-task is a comforting lie. Coding-task cost is not normally distributed; it's a power law with a brutal tail.

Most tasks are easy. The agent reads two files, writes a five-line patch, the test goes green, done, maybe a few cents. But a meaningful slice of tasks are hard, and on those the agent thrashes: it loops, it retries, it explores three approaches, it re-reads the whole context a dozen times. A single hard task can cost fifty times the median. Because those tasks are rare but enormous, your mean cost-per-task is dragged up far above your median, and if you priced off the median you are now losing money on every difficult job, which is, of course, exactly the kind of job a customer most wants an agent for.

This is where success rate and completion rate stop being abstractions and start being P&L. The standard benchmark for coding agents, SWE-bench, measures the share of real GitHub issues an agent can resolve, and even the strongest agents leave a large fraction unresolved. Every unresolved task in production is pure cost with no completion to bill against (if you price per outcome) or a frustrated customer staring at a bill for nothing (if you price per attempt). The retry problem and the gap between "the agent finished" and "the agent finished correctly" are the quiet margin-killers of the entire category, and they deserve their own teardown.

The operational takeaway: you must model the cost distribution, not its average. Set a hard budget ceiling per task and let the agent fail loudly when it hits the wall, because an agent with no spend cap will occasionally chase one impossible bug straight through your gross margin.

What scale does to the numbers

Run one coding agent and the economics are dominated by per-task variance. Run ten million tasks a month and entirely new forces show up, some helpful, some not.

Caching gets dramatically better at scale. When thousands of tasks touch the same repository, the same library docs, the same system prompt, your cache-hit rate climbs and your effective input-token price falls. Caching and memory are among the few levers that genuinely move gross margin in the right direction, and they reward concentration: a vendor serving one big codebase a million times has structurally better unit economics than one serving a million codebases once.

Volume discounts are real but lag. You can negotiate committed-use rates with model providers, but those commitments are bets on future volume against a cost base that moves weekly. Commit too aggressively and a token-price drop strands you above market; commit too little and you pay rack rate on your best months.

Fan-out cuts the other way. Sophisticated coding agents increasingly spawn sub-agents, a planner that dispatches workers to handle files in parallel. Parallelism feels free because it's faster, but each sub-agent carries its own context and its own token bill. A task that fans out to five sub-agents can cost five-plus times a sequential run for the same outcome. Speed and cost are in direct tension here, and "we made it faster" often quietly means "we made it more expensive."

The idle and orchestration costs stop being rounding errors. At a few thousand tasks the sandbox and queue infrastructure is noise. At scale it's a fixed-cost layer you're paying for whether agents are busy or idle, and vendors are notoriously good at hiding it inside a blended per-task number.

The honest version of scale economics: your variable cost per task tends to fall (better caching, better rates) while your structural costs (orchestration, fan-out, the long tail) tend to rise. Whether the business gets healthier as it grows depends entirely on which curve wins, and most GaaS decks only show you the first one.

Pricing against a moving cost base

Here's the cruelty unique to this category: your single biggest input cost can be re-priced by a vendor on a Tuesday with no warning.

Token prices have fallen steeply and repeatedly. You'd think that's pure good news for a coding-agent business, and yet most agent bills haven't fallen with them. The reason is that capability and cost rise together: as soon as a cheaper, smarter model ships, agents are pointed at harder tasks, run longer loops, and burn more thinking tokens, so per-task spend stays stubbornly flat even as per-token price drops. Falling token prices fund more ambitious agents, not cheaper bills. McKinsey's work on the economic potential of generative AI frames software engineering as one of the highest-value functions for this technology, which is exactly why the demand absorbs every efficiency gain.

For pricing, this creates an impossible-looking problem. If you price per task at a fixed rate, you're short the volatility: a bad week of inference prices eats your margin and you can't re-quote existing customers. If you pass costs straight through, you've made your revenue as lumpy and unforecastable as your costs, and your customer's finance team, who already hates consumption pricing, revolts. The vendors getting this right tend to price per outcome with a healthy buffer baked in, eat the week-to-week volatility themselves, and use caching plus model-routing (cheap model for easy tasks, frontier model only when needed) to defend the spread.

A worked margin example

Let's make it concrete with round, illustrative numbers, not a real vendor's books, but a plausible shape.

Say a coding agent charges $2.00 per completed task (open a passing PR). Across a large sample:

• 70% of tasks are easy. True cost ~$0.15 each in model and compute. Margin: ~$1.85.
• 22% are medium. Several loop iterations, more context. True cost ~$0.70. Margin: ~$1.30.
• 8% are hard. Heavy thrashing, sub-agent fan-out, multiple retries. True cost ~$4.50. Margin: negative $2.50, you lose money on every one.

Blended cost per task: (0.70 × 0.15) + (0.22 × 0.70) + (0.08 × 4.50) = 0.105 + 0.154 + 0.36 = ~$0.62. Against $2.00 revenue, that's a gross margin around 69%, respectable, SaaS-adjacent, the kind of number that makes a deck look healthy.

Now change one assumption. Let the hard-task share drift from 8% to 15% (a harder customer cohort, or an agent given more autonomy), and let those hard tasks creep to ~$6.00 each as loops lengthen. Blended cost jumps to roughly $1.07, and gross margin collapses to about 46%. Nobody changed the price. Nobody changed the model. The mix shifted, and a third of the margin evaporated.

That sensitivity is the whole point of the teardown. A coding agent's unit economics are not set by the model's price list; they're set by the distribution of task difficulty you're exposed to and how hard you cap the tail. Two vendors on the identical model can post wildly different margins purely because one of them lets its agent chase impossible bugs and the other doesn't.

Insights Most People Overlook

Capping autonomy is a margin decision dressed up as a safety decision. When a vendor limits how many steps an agent may take or how much it may spend per task, the public framing is reliability and safety. The private spreadsheet says something blunter: the uncapped tail is where the losses live. Several agent startups are quietly throttling autonomy specifically to protect gross margin, and customers experience it as "the agent gave up too early."

Prompt caching is a moat, not a feature. Because caching economics reward serving the same codebase many times, the vendor with the deepest penetration into a given customer's repo has structurally cheaper tasks than a newcomer, even on the identical model at the identical list price. That's a compounding cost advantage that looks invisible on any pricing comparison, and it's why land-and-expand inside one big account beats spreading thin.

Faster is often more expensive, and the demo hides it. Sub-agent fan-out makes the live demo dazzling because the work happens in parallel. It also multiplies the token bill. The impressive speed you're sold on is frequently the most margin-destructive architecture choice in the product, and the cost only shows up in aggregate at scale.

Falling model prices won't save a broken agent. Operators keep waiting for the next price cut to fix their margins. It won't, efficiency gains get reinvested into harder tasks and longer reasoning, so per-task spend stays flat. If your economics only work assuming inference gets cheaper, you don't have a business, you have a bet on someone else's roadmap.

Per-outcome pricing requires a measurable outcome, and "the test passed" is the only clean one in software. Coding is the easiest GaaS vertical to price per outcome precisely because correctness is checkable. That's also why coding agents are the canary: if outcome-based unit economics can't be made to work here, where the outcome is unambiguous, they're in deep trouble in support, sales, and every fuzzier vertical.

References

• Building Effective Agents, Anthropic
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
• The economic potential of generative AI, McKinsey