We ran a normal ten-turn session through a coding agent. The kind of afternoon a developer actually has. Trace a Slack event through Kafka into another service. Find where OAuth lives. Check whether a Jira integration already exists before building a new one. Add a field, wire up an error type.
The session cost $6.81, and $5.30 of that went to the agent grepping and reading files to find the code before it could do anything with it. 78% of the bill.
We ran the experiment five times, both configurations, to make sure the first result wasn’t a fluke. It held every time, so every number in this post is the average across the five sessions. Roughly three of every four dollars paid for the search.
Where the money actually goes
An agent starts every task knowing nothing about where your code lives. So it greps for a symbol, reads a file, follows a pointer into another file, opens three more, and only then starts answering. Everyone expects that part.
The part people miss is that the cost compounds. The agent works in a loop, and each step sends everything it has gathered so far back to the model. A file read on turn two is still riding along on turn twenty, billed as input every single time. So a wrong turn in the search doesn’t cost you once. You keep paying for it, turn after turn, until the session ends.
The usage records make this concrete. Over the baseline session the model generated about 44,000 tokens of actual answers. To produce them, it processed 5.3 million tokens of input. Almost all of that input was material the agent had already seen, resent on the next loop iteration: on average, every token the agent gathered got run back through the model about 50 times before the session was over.
And yes, prompt caching was on, with cached rereads billed at the discounted rate. The split below is what survives the discount.
| Cost | Share | |
|---|---|---|
| Searching / reading code | $5.30 | 78% |
| Everything else (the actual answers) | $1.51 | 22% |
Most of what you pay a coding agent has nothing to do with reasoning about your problem. It’s the agent reconstructing where your code lives, from zero, every time you ask it something.
Same prompts, but the agent already knows where the code is
Then we reran the identical ten prompts with one change. The relevant code was handed to the agent up front, pulled from an index of the whole codebase, before it started working. No hunting for the OAuth flow, because the OAuth flow was already in front of it. No tracing across repos to find the Jira client.
Same prompts. Same model. Same caching.
| Model calls | Tool calls | Files read | Time | Cost | |
|---|---|---|---|---|---|
| Normal agent (searches for everything) | 63 | 162 | 62 | 25 min | $6.81 |
| Given the right context up front | 24 | 14 | 3 | 8.5 min | $1.13 |
Six times cheaper, in a third of the time. The work didn’t shrink. The agent answered the same ten questions, and answered them well. What got deleted was the search: 162 tool calls became 14, and 62 file reads became 3. Total tokens through the model dropped from 5.3 million to 1.4 million.
The gap was widest on cross-repo questions like “do we already have a git-provider integration we could reuse?” An agent on a laptop can only search what’s checked out on that laptop, so it either grinds through the local repos or answers “we don’t have one” while the integration sits in a repo three teams over. Given the index, the agent pointed straight at real code in git-provider and jira-insights. The developer had never cloned either repo.
The setup, because you should be suspicious of vendor benchmarks
Both configurations ran on Claude Sonnet 5 at high reasoning effort, identical settings on both sides, prompt caching on, n = 5 sessions per configuration. The per-question tables in the appendix are the averages across those five sessions.
Worth knowing: Sonnet is the cheap case here. Stronger models explore harder. Opus opens more files and runs longer search loops than Sonnet does before it commits to an answer, which means the search share of your bill grows with model tier. If your team runs Opus, this problem is bigger for you, not smaller.
The takeaway
If you’re paying for AI coding agents, most of the bill isn’t intelligence. It’s rediscovery, plus interest, as everything the agent read gets re-billed on every following turn. Hand the agent a map instead of making it draw one per request and the number that drops isn’t small.
That map is what Bito’s AI Architect builds. A live index of your whole codebase that resolves each question to the relevant code and feeds the agent exactly that span before it starts hunting. Same agent, same questions, a sixth of the cost.
Appendix: the data behind this post
Ten questions, five sessions per arm, Claude Sonnet 5; the numbers below are averages across the five. “Baseline” is a normal agent with the developer’s checked-out repos to read. “With context” is the same agent fed relevant code from an index of all the company’s repos before each question.
A “model call” is one round-trip to the model. A single question usually takes several, because the agent calls the model, the model asks to read a file, that read runs, and the model gets called again with the result. “Files read” counts the agent opening a file to look at it.
Baseline, the normal agent:
| # | Question | Model calls | Time | Files read | Cost |
|---|---|---|---|---|---|
| 1 | Trace a Slack event across repos to the consumer | 1 | 128s | 11 | $0.81 |
| 2 | Trace the publish path in the Kafka service | 11 | 59s | 3 | $0.20 |
| 3 | Do we have a git-provider integration to reuse? | 1 | 289s | 20 | $1.74 |
| 4 | Do we have an OAuth impl to adapt? | 11 | 161s | 3 | $0.47 |
| 5 | Do we have a Jira integration to reuse? | 1 | 277s | 18 | $1.56 |
| 6 | Research: OAuth token storage best practices | 10 | 111s | 2 | $0.45 |
| 7 | How does it decide transient vs permanent errors? | 5 | 57s | 2 | $0.30 |
| 8 | Plan: add “connect GitLab account” | 6 | 82s | 0 | $0.28 |
| 9 | Implement a new transient error kind | 11 | 227s | 2 | $0.60 |
| 10 | Implement a traceId field through the pipeline | 6 | 126s | 1 | $0.39 |
| Total | 63 | 25.3 min | 62 | $6.81 |
With context (Bito Governor):
| # | Question | Model calls | Time | Files read | Cost |
|---|---|---|---|---|---|
| 1 | Trace a Slack event across repos to the consumer | 1 | 32s | 0 | $0.25 |
| 2 | Trace the publish path in the Kafka service | 1 | 51s | 0 | $0.05 |
| 3 | Do we have a git-provider integration to reuse? | 1 | 47s | 0 | $0.05 |
| 4 | Do we have an OAuth impl to adapt? | 1 | 30s | 0 | $0.06 |
| 5 | Do we have a Jira integration to reuse? | 1 | 21s | 0 | $0.05 |
| 6 | Research: OAuth token storage best practices | 2 | 58s | 0 | $0.13 |
| 7 | How does it decide transient vs permanent errors? | 1 | 24s | 0 | $0.05 |
| 8 | Plan: add “connect GitLab account” | 1 | 21s | 0 | $0.06 |
| 9 | Implement a new transient error kind | 8 | 169s | 2 | $0.21 |
| 10 | Implement a traceId field through the pipeline | 7 | 59s | 1 | $0.22 |
| Total | 24 | 8.5 min | 3 | $1.13 |
Costs in this table are all-in: everything it takes to answer the question, against baseline’s $6.81.
Implication
Read the two “files read” columns against each other. The baseline opened 62 files across the session. The context agent opened 3, all on the last two questions, where it was writing code and needed to see the exact spot to edit. On the eight questions about understanding or finding code, the baseline read 59 files and the context agent read none.
The token ledger tells the same story from a different angle. Baseline: 5.3M tokens through the model to produce 44K tokens of answers. With context: 1.4M in, 10K out. In both arms the answers themselves are under 1% of the tokens processed. The bill is the ferrying, and the ferrying is what the index removes.
Questions 3 and 5 show the effect at its sharpest, the two “do we already have one of these?” questions. The baseline spent $1.74 and $1.56, opened around 20 files each, and ground through the local repos for nearly five minutes apiece. The context agent answered both in one model call, a nickel apiece, under a minute, because the code in question lived in repos the developer didn’t have checked out. It was handed the answer instead of failing to find it locally.
And notice where the context agent still spends: questions 9 and 10, the two that write code. Real model calls, a couple of file reads, because implementing a change means touching actual code no matter how much context you inject. That’s an honest boundary on the claim. The index collapses the search, and the search happens to be most of a normal session.
