Your AI agent burns through tokens? Here is where ours went
We blamed the subagents. The logs blamed the main thread, a 98% cache hit rate and a clock set one minute too late. What 136 agent sessions taught us, and how to audit your own.
If your AI agent keeps running out of tokens, or your usage page climbs faster than the work gets done, this post is for you.
The bill
For ten days we let our coding agents run a real project: 136 sessions, each one taking a ticket from plan to code, review and QA. The work got done. Then we looked at the usage: about 680 million weighted tokens.
We already knew who to blame. Every review starts a handful of helper agents (subagents), one per angle: logic, security, cleanup. They all ran on the big model. The fix looked obvious: move the helpers to a smaller, cheaper model, and the bill drops.
Before changing anything, we decided to measure. That turned out to be the most useful decision of the week.
Surprise 1: the helpers were not the problem
The subagents cost 19%. The other 81% came from the main conversation, the one agent doing the actual work.
So even if the helpers had become free, four fifths of the bill would still be there. The fix we were about to make was real, but small. The big cost was somewhere we were not looking.
Surprise 2: a 98% cache hit rate, and it was still expensive
Our prompt cache hit rate was 98.4%. That sounds like a solved problem. It isn't, and the reason is the most important idea in this post.
An agent has no memory between calls. On every turn it sends the whole conversation again: instructions, files it has read, every tool result so far. The cache makes that re-send cheap, about a tenth of the normal price, but not free.
Our median session had about 165k tokens of context and ran about 150 turns. A tenth of 165k, 150 times over, is a lot of tokens, even when every one of them is a cache hit. Cache reads alone were more than half of the bill.
So the cost of an agent is roughly:
what it carries × how many turns it takes
The cache only changes the price per unit. It does not change the shape. And whenever the cache is missed, because a new session starts or the agent waited too long, the whole context is written again at 1.25 to 2 times the price. One cold start costs about as much as twenty warm turns.
Once we saw it that way, the real leaks were easy to find.
Leak 1: turns spent guessing
Every turn re-reads the whole desk, so a wasted turn is never cheap. We counted:
- 644
--helpcalls. The agent guessed at command flags the instructions did not spell out, then looked them up. - About 230 rejected tool calls on one verification command: wrong gate name, a missing argument, an extra key in a results file. Each rejection is a turn, and each retry is another.
- 22 of 68 code reviews were repeats that re-read the whole change to check a small fix. One ticket was fully reviewed six times.
None of this is the model being bad. It is the instructions leaving gaps, and the agent paying to fill them. The fix is plain writing: exact flags, exact error recovery, and a rule that a second review looks only at what changed since the first.
Leak 2: sessions that start cold
Our project ran as tickets, one agent session per ticket. Half the tickets needed an extra session, and each one cost about 2 million tokens: the agent re-reads the plan, re-learns the code, runs its own review and QA.
Almost every extra session had the same cause: a sibling ticket in the same phase edited the same files or changed an interface this ticket used. We had split the work by size ("2 to 5 tickets per phase"), and the pieces kept stepping on each other.
New rule: split by context, not by size. Work on one module, or on an interface that is still being shaped, stays one ticket in one long session, even if it is big. We split only where the parts are truly separate.
Leak 3: a clock set one minute too late
Our orchestrator (Foreman) wakes up now and then to check on its workers. Its status ping defaulted to 3600 seconds. The prompt cache lives for one hour. So whenever Foreman sat idle until the ping, it woke up just after the cache had expired: 21% of its wakes started cold, each one re-writing 0.2 to 0.45 million tokens.
The fix was one number: 3300 seconds.
The same clock hurt in the other direction. We had set the subagents' cache to the one-hour lifetime, which costs 2× per write instead of 1.25×. Most review helpers live for a few minutes and never read that cache back. That setting alone cost about 4%. We removed it.
Leak 4: what every session carries before it starts
Before your agent reads a single file, it already carries a load: the list of installed skills, project instructions, a memory index. That load sits in every turn.
Ours had grown to about 7,500 tokens of skill descriptions, most of them never used: synced skills we had forgotten, old copies, operations skills only a human ever starts. Our memory index had grown past its read limit (25.1 KB against 24.4 KB), so the end of it was being silently cut off.
We removed unused skills (moved aside, not deleted), turned operations skills into commands you type yourself, and compacted the memory index. The listing went from about 7.5k to about 3k tokens, in every session, on every turn.
What we chose not to do
Some savings cost more than they save:
- Shorter skill prompts: 1–2% at most, and our prompts are tuned word by word.
- Merging review voters: about 2%, but it breaks the "one finding, one vote" design that keeps reviews honest.
- Compacting the conversation earlier: about 10%, but the agent forgets more. That trade is the user's to make, not ours.
- A smaller model for the logic reviewers: that is where the real bugs are found. We judge them by findings, not tokens.
The cleanup reviewers did move to a lighter model, and every vote is kept.
Where we are now
To be honest: this post describes a measured before, and changes made on 25 October 2026. The after window needs about a week of real work. We wrote down the numbers we expect, and we will publish the real ones whether they match or not.
Audit your own agent in five minutes
We turned the whole investigation into a skill, so the next audit is one command. It ships with 2build from v1.108.
1. Install or update 2build.
brew tap 2found/2build https://github.com/2found/2build
brew install 2found/2build/bbs # already installed? run: bbs update
bbs install # detects Claude Code, Codex, AntigravityRestart your agent afterwards.
2. Ask your agent for an audit.
| Agent | Type |
|---|---|
| Claude Code | /bbs:token-audit |
| Codex | $bbs:token-audit |
| OMP | /token-audit |
You can add a scope, for example: /bbs:token-audit last 14 days, this repo only.
3. Read the report. It ends with a short block like this:
STATUS: DONE
VERDICT: AUDITED
WINDOW: last 14 days · claude · 42 sessions · 96.1M
SPLIT: main 78% (read 51% · write 15% · output 12%) · subagents 22%
BACKGROUND: listing ≈6.8k tokens · instructions 9.2 KB · memory 23.9 KB/182 lines
PROPOSALS:
1. Fix the docs behind 310 --help lookups — saves ≈3% — risk none
2. Hide 14 unused skills — saves ≈2% — risk low
...
REJECTED: shorter skill text — under 1%
NEXT: apply item 1The numbers above are an example. Yours will differ, and that is the point.
What it looks at:
- Where the tokens went: main conversation against helpers; cache reads, cache writes and output; by skill, by model, by helper.
- Friction: failed calls,
--helplookups, repeated commands and repeated skill runs. - What every session carries: each installed skill, whether it was used in the window, duplicate and stale copies, instruction files and the memory index against its limit.
It reads Claude Code, Codex and OMP session logs on your own machine. It prints counts and command names, never the text of your conversations, and sends nothing anywhere. It only proposes. Nothing changes until you ask it to apply a proposal, and every proposal says how much it saves and what it risks.
No 2build? Check these yourself
- Measure before you switch models. Find out whether the main conversation or the helpers cost more.
- Count turns, not just tokens. Every turn re-reads everything the agent carries.
- Look for guessing:
--helpcalls, retries of the same command, repeated reviews. - Keep sessions alive when the work shares files. A new session costs about twenty warm turns.
- Check your timers against the cache lifetime. A ping one minute too late is a cold start every time.
- Trim what loads first: unused skills, long instruction files, a memory index past its limit.
Your agent is probably not wasteful. It is just paying, on every turn, for everything it carries and everything it has to guess. Make both smaller and the bill follows.
Technical detail, method and every table: token economics and Foreman cache economics in the 2build repository.
