The economics of an agent's context window
Why does a one-line fix at the end of a long session cost so much more than the same fix in a fresh one? Nothing is wrong with your setup, and the answer is the same for every agent you might be using.
Every turn an agent takes sends the whole conversation again. The provider keeps
nothing between calls on the ordinary APIs these tools use, so each request
carries the system prompt, the tool descriptions, your AGENTS.md, every
earlier message and every file the agent has read, all of it a second time, and
a third, and so on. The loop this comes from is described in
Context engineering in practice.
Almost everything an agent costs follows from one fact: the whole context is sent again on every turn.
Why sessions get expensive
So a session costs what it costs because of how long it is, not because of how much work you got done in it. A one-line fix at the end of a long conversation is billed against the whole conversation.
Where the cost comes from
Each turn sends every turn before it again, plus every file read and test log. Most of what you pay for is what goes in, not what comes out.
Cost and quality get worse together
The clutter that raises the bill also makes the answers worse. Both problems arrive at the same time.
Caching saves you
Providers keep a copy of the repeated part and charge less for it, which is what makes running agents affordable at all.
How the cache works
The provider keeps a copy of the front part of your context, and charges less when you send that same part again. Anthropic charges about 1.25× the normal rate to make the copy, and about a tenth of the normal rate to read it back. The copy is thrown away five minutes after it was last used. There is also a one-hour version that survives longer gaps, and it costs double the normal rate to make, so it needs about three requests to pay for itself rather than two. The figures change. The shape of the deal is what matters.
Each turn reads everything before it again at roughly a tenth of the normal rate, for as long as that part is left alone. Over a 100k-token context and twenty turns, that is about two full-price passes rather than twenty.
Anything you add at the end is cheap. Anything you change near the beginning puts everything after it back to full price.
Editing the system prompt or AGENTS.md mid-session
The front part changed, so everything after it has to be copied again.
Adding or removing MCP servers
The tool descriptions move, and they sit near the front.
Changing earlier messages instead of adding to the end
The same problem, further down the window.
Long idle gaps
Five minutes after you last used it, the copy is gone. Stop and restart sessions deliberately, or pay double to make a one-hour copy if long gaps are simply how you work.
What my own bill showed
I went through the token accounting for one of my projects line by line. The model is Claude Opus, and the split below is representative of what I see across many sessions rather than a figure drawn from a single run.
≈ 94%
of what I spent went on making and reading the cached copy
- cache read 57%
- cache write 37%
- output 6%
Producing code was under 6% of what I paid. The rest went on sending the same context over and over, and text sent without a cached copy rounded to under a percent. Reading costs a tenth of the normal rate and copying costs 1.25×, so spending 57 on reads and 37 on copies means about nineteen reads for every copy. Every token I paid to copy was read back roughly nineteen times. Without the cache, the same traffic would have cost about six times more.
An idle session is not a free session
A one-hour break threw away the copy, so the whole front part had to be made again at the higher rate instead of read back at the lower one. Stop or close sessions rather than leaving them open.
Watch the ratio, not the total
Restarts and expiries copy text I had already paid to copy once, which drags that nineteen down. If that number starts falling, something is throwing the copy away, and you will see it there well before you see it in the monthly total.
What changes with a team
The figures change when a whole team works this way. The mechanics do not.
Budget for it, or it gets decided for you
AI spend is easy to leave out of a project budget, and it stays invisible until someone goes looking. When it does surface, the response I have seen is a blanket move to cheaper models, settled quickly and without anyone knowing what that costs in engineer hours. Budget it the way you budget cloud spend, per project and up front, and the same conversation happens with numbers in it.
Price per token is not price per task
I measured the same task on Opus and on cheaper models: Sonnet, Qwen and GLM-5.2. Opus finished in about ten minutes. The cheaper models took around an hour, and cost me almost the same in the end. The lower rate simply bought more attempts, each one re-sending a context that had grown since the last. I judge models on what a finished task costs, and I count the hour of my attention as part of it.
Cost per feature becomes visible
This one I welcome. You can finally see what a feature costs, as long as you count all of it: tokens, engineer hours, review and maintenance, set against what it delivered.
The five habits I now use
- 1
Cut back AGENTS.md and CLAUDE.md
It is the most valuable file you own, because whatever is in it is sent again on every turn, by every engineer. Cut it until each line earns its place.
- 2
Disconnect unused MCP servers
Unused tools still cost you on every message.
- 3
Start a fresh session for each task
No reason to carry 80k tokens of yesterday into a one-line fix.
- 4
Leave the front of the context alone
Add at the end rather than editing the start, and change settings between sessions rather than during one.
- 5
Push big file reads onto a sub-agent
Send the 5,000-line file to a sub-agent rather than into your own window. It reads the file in a context you then throw away, and hands back the twenty lines you needed. Most tools offer this as a task or sub-agent.
Working to cut the cost and working to improve the quality turned out to be the same job.
The rates will move, and the terms of the cache will change more than once. The fact underneath will not. A model that forgets everything has to be told it all again on every turn, and someone has to decide what all of it is.