Burned 30% of my Claude Code 20x weekly usage in a Day: Discover Why and Fixes

Forensics includes 32,900 agent API calls, six causes, six fixes, and the one number that explains most of it.

The morning after

On 14th October 8:30 PM, my weekly limits got refreshed, On 15 October my coding agents used about 30% of a whole week's limit in one working day. Nothing was broken. The agents shipped 24 pull requests that day, which is normal for me. The work was not the problem. The way the work was paid for was the problem.

I am a solo founder building EduDojo, a writing platform for students. Almost all of the code is written by AI agents in Claude Code: one main session plans, subagents build, and an AI reviewer (Codex) reviews every pull request. In the first two weeks of October I merged 197 pull requests. The median PR touched 11 files and merged 53 minutes after it opened.

So instead of guessing, I read the logs. Claude Code keeps every turn of every session as a JSONL file on disk. A 60-line Python script can read them and price every call.

The one number: every turn re-reads the whole context

Between 12 and 15 October the harness made 32,900 API calls. Each call carried, on average, about 31,000 input-equivalent tokens of context that it had already sent before.

This is how agent pricing works. A model has no memory between calls. Each turn sends the full conversation again. Prompt caching makes the repeat cheap (a cache read costs 0.1 of a fresh token), but it is never free, and it gets expensive in three cases:

1. 01The context is very large, so even 0.1 per token adds up.
2. 02The cache expires, so the next turn writes the whole context again at 1.25 to 2 times the price of fresh input.
3. 03The agent takes many small turns, so it pays the re-read many times.

My data hit all three.

What the calls looked like

Read the last three rows together. The tool outputs were tiny. A shell command returned half a kilobyte. But to get that half kilobyte, the agent paid to re-read 31,000 tokens. The output was never the cost. The turn was the cost.

The six causes of 15 October

1. 01The builder was secretly the most expensive model. My routing file says build work runs on a middle-tier model. On 15 October several build subagents ran on the strongest tier. A strongest-tier token costs more than a middle-tier token, so every build turn cost more, and build work is most of the turns. Nothing enforced the routing rule; it was text in a file.
2. 02Worker contexts were huge. The average build worker carried about 280k tokens of context. A worker that reads a large part of the codebase and then takes 200 small turns pays for 280k tokens 200 times.
3. 03Parallelism multiplied it. Several workers ran at once. Each one paid its own context. Parallel work saves wall-clock time, but it does not save tokens; it adds them.
4. 04The compact window was 500k. Claude Code compacts (summarises) a conversation when it reaches a set size. Mine was 500k tokens. A context near 500k makes every turn re-read near 500k.
5. 05The cache expired between turns. The default prompt cache lives 5 minutes. When a worker waited on CI, a test run, or its parent, the cache died, and the next turn wrote the whole context again.
6. 06Single-tool turns. 79% of calls ran one tool. Independent reads, such as three files and a git status, went out as four turns instead of one.

The six fixes

What I learned

• Measure turns, not tokens of output. A tool result of 0.5k tokens rode on a 31k re-read. Context re-reads were most of the bill.
• A rule that is only text will slip. The model routing rule existed. It did not stop the slip. A hook did.
• Bigger context is not better context. A 300k window costs less on every single turn, and the agent rarely needs the old 200k.
• Cache life is a trade, not a default. A longer cache costs more per write, but it saves a full rewrite after a long pause. You need your own pause data to choose (post 3 has mine).
• Parallel agents buy time with money. Use them where time matters, and give each one a short, focused context.

Try it on your own logs

Your Claude Code transcripts are in ~/.claude/projects/**/*.jsonl. Each assistant line has a usage block with cache_read_input_tokens, cache_creation_input_tokens and output_tokens. Group by message id (a single message can span several lines), weight the fields with the multipliers in the data notes, and sum by day, by model, and by tool. That one table will show you where your money goes.

Interactive: cost explorer

Enter token counts in millions for each category. The weights are the published prompt-cache multipliers, so the result is in input-equivalent units, not dollars.

<details>

<summary><strong>Data notes and references</strong> (click to expand)</summary>

Source of the numbers

Every number in this article comes from the coding harness: Claude Code transcripts, GitHub pull request data, and hook tests. None of it comes from student data.

Cost weights

All costs are in input-equivalent units, relative to one fresh input token. They are the published prompt-cache multipliers:

• Input: 1
• Cache write, 5-minute life: 1.25
• Cache write, 1-hour life: 2.0
• Cache read: 0.1
• Output: 5

Caveats

• The P1 and P2 counts are badge counts on Codex review comments. One finding can repeat across rounds, so do not read them as unique bugs.
• The 15 October cause ranking is my analysis of transcript data. The fixes are verified as merged, but their saving is measured only for the cache setting so far.

References

1. 01Claude Code transcripts: ~/.claude/projects/**/*.jsonl, one JSON object per line, with a usage block on assistant turns.
2. 02Prompt caching multipliers: published Anthropic prompt-caching pricing (verify current values before reuse).
3. 03Codex review data: GitHub REST API, merged pull requests in the EdudojoAI/Edudojo-MVP repository, 2–16 October 2026.
4. 04Companion pieces (Coming Soon): Article 2 (review loop cap) and Article 3 (portable plugin).