"How much does it cost when an agent does a coding task" sounds like a question with a mysterious answer. It is not. It is arithmetic, and you can do it on the back of an envelope well enough to make decisions. The only trick is knowing what to count, because the intuitive number (the code the agent writes) is the small part, and the part people forget (everything the agent reads) is the large part.
This is an LLM token cost calculation for real agentic coding work, not a chatbot reply. Once you see the shape of it, the levers that actually lower the bill become obvious, and the scary-sounding total stops being scary.
The unit: a lot of input, a little output
A useful reference point, widely cited across 2026 pricing analyses, is that one realistic agentic coding task runs on the order of 200,000 input tokens and 30,000 output tokens. Treat those as ballpark, not gospel, but the ratio is the point: input dwarfs output, often by six or seven to one.
That lopsidedness is not waste. It is the job. To make a correct change, the agent has to read: the relevant files, the interfaces it touches, the conventions, the test expectations, and the running conversation of its own previous steps. The output, by contrast, is just the diff and some explanation. An agent that produced 200k tokens of output would be alarming. An agent that consumed 200k tokens of input is simply one that looked before it typed.
The rates, and why output still costs the most
Per-million-token pricing is public. As of mid-2026 (verify current rates before you quote them), the Claude range looks roughly like this:
- Opus: about $5 input, $25 output per million tokens
- Sonnet: about $3 input, $15 output per million tokens
- Haiku: about $1 input, $5 output per million tokens
Notice the constant across all three: output costs about five times input. That single fact does a lot of work. It means the 30,000 tokens of output, small as they are in count, punch far above their weight in cost. Cheap tokens read; expensive tokens are written.
Working the numbers
Take one pass of that reference task on Sonnet:
- Input: 200,000 tokens x $3 per million = $0.60
- Output: 30,000 tokens x $15 per million = $0.45
- Total: about $1.05
So output is only about 13 percent of the tokens but roughly 43 percent of the cost. Run the same pass on Opus and it is about $1.00 input plus $0.75 output, near $1.75. On Haiku, about $0.20 plus $0.15, near $0.35. The spread between the cheapest and most capable model on the exact same work is roughly five to one, which is why routing work to the right model is one of the biggest levers you have.
One pass, one model, one dollar-ish. If that were the whole story, nobody would worry about cost. It is not the whole story.
Iterations are where the bill actually grows
A real task is not one call. It is a small pipeline: a planning step, then a few implement-and-test iterations, then a check that the work meets its acceptance criteria, then usually a review. Every one of those steps is its own model call, and most of them re-send the context.
That is the part that surprises people. A task that lands in one clean pass costs about what the arithmetic above says. A task that takes four rounds of "try, run the tests, read the failure, fix" can cost three or four times as much, because the expensive input is paid for again on each round. This compounding is worth its own treatment, covered in agent loops and quadratic token growth, but the headline is simple: iterations, not the base task, are what separate a cheap feature from an expensive one.
This is also why a flat "cost per feature" number is a fiction. A one-line config change and a gnarly multi-file refactor can differ by more than ten to one, and they should. If you want a grounded way to estimate across a real backlog rather than a single task, what an AI coding agent actually costs per feature works the problem from the feature level down.
Caching changes the shape
Here is the lever that makes the iteration problem manageable. Most of that 200k input is stable across a task: the same files, the same conventions, the same instructions, sent again and again. Prompt caching charges the repeated prefix at a steep discount, commonly around a tenth of the normal input rate.
Rerun the Sonnet math with the input cached:
- Cached input: 200,000 tokens x $3 per million x roughly 0.1 = about $0.06
- Output: unchanged at $0.45
The input cost nearly vanishes, and suddenly a four-iteration task is not four times $1.05, it is four small outputs on top of one cheap, cached read. For a repo-grounded agent that re-sends a large stable context on every step, this is the single biggest saving available, which is why it gets its own deep dive in prompt caching for repo-grounded agents.
The honest limitation
These numbers are order-of-magnitude, not a quote. Real repositories are messier than the reference task: some changes need far more context, some models are more verbose than others, cache hit rates vary with how your pipeline is structured, and rates move (the ones above will be stale by the time you read this). Do not build a business case on a-priori token math. Use it as a sanity check, then measure. A representative sample of your own real work, with the actual token counts and the actual bill, will tell you more in a week than any spreadsheet will up front.
What the math gives you is not precision. It is intuition: input is large but cheap and cacheable, output is small but expensive, and iterations are the real multiplier. Hold those three facts and you can reason about any agent's bill.
That framing is deliberate in how we built Loopsfinity: you bring your own model account, so you pay these public rates directly with no markup, and each run records what it actually cost so your estimate becomes your telemetry. The math above is yours to use on any agent you run, ours included, before you spend a cent.