People budget for coding agents by thinking about output: how much code will it write, at what price per token. Then the bill arrives and it is several times the estimate, and the output was not the reason.
Short answer: the conversation is resent in full on every single turn. A forty-turn session does not send your context once, it sends a growing version of it forty times, and input dominates the bill by a wide margin. The four levers that matter are cache hit rate, how much the agent reads, session length, and model choice, roughly in that order. The first one is nearly free and most people have it switched off by accident.
Where the tokens go
Four buckets, and the largest is not the one you would guess.
Conversation history. Every previous turn, resent. This grows monotonically through a session and it is the single biggest line for most people. Turn thirty carries turns one through twenty-nine on its back.
File contents. Everything the agent has read. A handful of large files early in a session becomes a fixed tax on every turn after.
Instruction and tool definitions. Your project instructions plus the schema of every connected tool. Individually small, resent constantly, and surprisingly large once several MCP servers are attached.
Output. The actual generated code and explanation. Priced higher per token and usually a minority of the total.
The consequence is counter-intuitive and worth stating plainly: an agent that reads a lot and thinks briefly costs more than one that reads little and thinks hard. Reading is not a one-off cost. It is a subscription for the rest of the session.
The lever almost nobody pulls
Prompt caching lets the stable prefix of a request be reused rather than reprocessed, at a large discount on the cached portion. Tools enable it by default, and then people invalidate it without realising.
Caching is a prefix match. Any byte that changes anywhere in the prefix invalidates everything after it. Which means:
- Editing your instruction file mid-session invalidates the cache for the whole session from that point. Edit between sessions, not during.
- Connecting or disconnecting a tool changes the tool block and invalidates everything after it.
- Anything non-deterministic near the front kills it permanently: a timestamp, a session id, an unsorted list serialised differently each time.
The practical rule is the same one that governs context generally: stable content first, volatile content last. Instructions and tools at the front, the changing question at the end.
If your costs feel wrong, this is the first thing to check, and most tools will tell you the cache hit rate if you look. A session that should be mostly cache reads and is not has something invalidating it every turn.
Four ways to spend less without working worse
One: start fresh sessions more often. The cheapest change available. A long session carries dead context: abandoned attempts, files that turned out irrelevant, tool output from a path you dropped. All of it resent, every turn. Finishing a task and starting clean costs nothing and removes the accumulated weight. This is also better for output quality, for the reasons in why your agent forgets.
Two: keep the instruction file short. It sits at the front of every request forever. Four hundred lines of aspirational prose is a permanent line item and it degrades output as well, which is the argument in writing instruction files an agent will follow.
Three: disconnect tools you are not using. Every connected MCP server contributes its schema to every request. Eight servers connected because they looked interesting is a real, silent, per-turn cost. Connect what the task needs.
Four: match the model to the task. Frontier models for architecture, ambiguity and anything where being wrong is expensive. Smaller and faster ones for mechanical work, bulk edits and subagents doing narrow jobs. The current lineup and rates are on the pricing page and they move, which is why there are no numbers in this post.
What is actually driving my bill?
Diagnose before optimising. Three checks, in order.
Check the cache hit rate. If cached reads are near zero across a long session, something is invalidating the prefix every turn. Fix that first, because it is the largest available win and it costs nothing in capability.
Check how much is being read. If the agent is pulling in large files to answer small questions, the problem is discoverability: it cannot find the specific thing so it reads the general thing. Better structure and a searchable codebase fix this more cheaply than any setting.
Check session length. If your typical session is a hundred turns, the tail of it is enormously more expensive per turn than the head. That is not a pricing problem, it is a workflow one.
Claude Code documents its own cost tracking, and any tool worth using will expose per-session usage somewhere. Look at it once a week for a month and the pattern will be obvious.
The comparison people get wrong
Comparing agents on price per token is close to meaningless, because the pricing model matters far less than your usage pattern.
A tool that reads aggressively and reasons briefly can cost several times more than a tool with a higher headline rate that reads narrowly. A flat subscription is a bargain if you run long sessions daily and terrible if you use it twice a week. The variable is you, not the rate card.
Model your own pattern for a fortnight before letting price decide, which is also the honest caveat on every ranking including the best coding agents sorted by what they are for.
The cost nobody puts on the invoice
Worth saying because it dwarfs the token spend.
Review time. Agents produce changes faster than anyone can carefully read them, and the reading is now the bottleneck. If your reviewers are the constraint, saving on tokens is optimising the cheap side of the equation. The fix is automating more of the checking, which is the argument in verifying agent work.
Rework. An agent that produced something subtly wrong that shipped costs more than the entire month’s usage. This is the real reason to spend up on the model for high-consequence work rather than down.
Cleanup. Duplicated helpers, invented conventions, dependencies nobody reviewed. Cheap to create, expensive to unwind, and largely invisible until someone tries to change something.
Judge cost per completed and verified task, not per request. A cheaper turn that needs three more turns to get right was not cheaper. And the decisions with the longest cost tail are not tokens at all: they are the ones in the infrastructure your agent picks for you, which outlive every session and every model.