95% of AI Coding Quota Burned in Two Days: Logs Reveal the Token Truth

A developer who uses Claude Code every day to build a SaaS product found himself at 95% of his weekly quota before Wednesday even arrived. He assumed he'd written a massive amount of code. That wasn't what happened.

Since every request leaves a local log, he aggregated three days of data and saw these numbers:

• 65,000 requests
• 12.6 billion tokens processed
• 14 million tokens of actual output

In other words, 99.9% of the tokens weren't code at all. They were spent on the model re-reading what it already knew.

The real cost is context, not code

The data shows 97.6% of tokens were cache reads. On every turn of the conversation, the agent re-sends the entire prior conversation: files it read, tool results, earlier decisions—everything gets read again.

When the context has already accumulated to 200,000 tokens, replying with a single line still costs 200,000 tokens of reading.

Even more striking is the distribution: two-thirds of all token volume came from requests with contexts over 200,000 tokens, while requests under 50,000 tokens contributed only 2.5%.

A long session is expensive not because it does more, but because each new turn is more expensive than the last.

What is a cache read? In Anthropic's API billing system, prompt caching lets developers mark a stable prefix (such as the system prompt, conversation history, or files already read) as cached content. When the same prefix is sent again, the server doesn't need to recompute its attention—it reuses the cached key-value (KV) pairs, and those tokens are billed as "cache reads." Their unit price is typically about one-tenth that of fresh input tokens, so the bill looks cheap, but when counted against quota they're often weighted equivalently. That's why 97.6% cache reads can still rapidly drain a quota. In other words, caching reduces cost, not the size of the context itself; the model still has to "perceive" those 200,000 tokens every turn—it just perceives them more cheaply. Understanding this is essential to grasping that "saving money" and "saving quota" are two different things.

Subagents are multipliers

This developer's workflow breaks tasks down very finely. Each task is implemented by one subagent and reviewed by two—one checks spec compliance, the other gates code quality. It does produce clean results.

But it also accounted for 78% of requests and 53% of token consumption.

Each subagent starts with a fresh but still substantial context, performs plenty of tool calls, and every call re-reads that context. One task becomes dozens of requests.

Subagents and context isolation A subagent is an independent execution unit spawned by the main agent, with its own conversation history and context window. The design intent is to isolate tasks and keep the main session from being polluted by intermediate results—but the cost is that each subagent, when it starts, cannot share the cache the main session has already built; it must re-read its own copy of context. When the main agent hands off a task along with relevant files and specs, that "starting context" can itself be large, and every tool call inside the subagent re-sends it again. So the larger the fan-out, the more the total re-reads multiply: splitting one task into N subagents can mean N large contexts being read over and over. This is why reducing parallel subagents—or keeping just a single review pass—often cuts usage dramatically.

Five sessions ate 75% of the week's quota

Out of 46 total sessions, five accounted for three-quarters of total usage. They were multi-hour marathons, context ballooning continuously, and the developer never restarted. One of them averaged nearly 400,000 tokens of context per request.

The distribution across models is also worth noting:

Model	Share of tokens
Sonnet	82%
Opus	14%
Fable (premium tier)	3.6%, almost all in a single day

Context windows and the "long-session tax" Mainstream models have context windows between 200,000 and 1,000,000 tokens, and bigger windows look like they can hold more. But the real cost curve isn't linear: turn 1 sends just one copy of content, turn 10 sends the accumulated content of the previous 9 turns, turn 100 sends 99 turns of accumulation. If the added content per turn is roughly constant, total consumption grows quadratically with the number of turns. That's the "long-session tax"—the longer a session runs, the more expensive each request becomes, and most of that content has already been processed by the model. Proactively compressing or resetting a session around 150,000 tokens essentially cuts the quadratic curve while it's still gentle. Splitting a long task into several independent sessions, each starting from clean and lean context, is far more economical than chatting all the way to 400,000 tokens.

What's changing

In response to the problems the logs exposed, the developer listed five adjustments:

1. Divide sessions by task blocks: proactively clean up or compress before context reaches 150,000 tokens.
2. Reduce parallel subagents: for routine work, do only one round of review instead of two.
3. Switch routine subagents to smaller models, such as for review and exploration tasks.
4. Use premium models only for planning and difficult decisions.
5. Write a small local script that summarizes logs each morning, so the curve is visible before the usage meter alarms.

A note on the numbers

These are raw token counts. Cache reads are billed and quota-counted differently from fresh tokens, so this dataset explains the scale of usage, not the exact percentage shown on the usage meter. What really matters is the underlying pattern.

Key takeaways

If your AI coding quota disappears far faster than your output, look first at context size and subagent fan-out before blaming the model.

Tokens aren't spent on the answer—they're spent on remembering the question.

How do you usually track agent usage? Do you proactively reset sessions, or wait until something breaks before restarting?

One-line Summary

A developer burned 12.6 billion tokens in three days—99.9% wasn't code, but the model re-reading context.

Paragraph Summary

Analyzing three days of Claude Code logs, a developer found that 65,000 requests processed 12.6 billion tokens, but actual output was only 14 million—99.9% went to the model re-reading what it already knew. 97.6% were cache reads, and two-thirds of usage came from requests with contexts over 200,000 tokens. A subagent workflow that split tasks contributed 78% of requests and 53% of token consumption, because each subagent carried a large context that was re-read repeatedly. Of 46 sessions, just 5 long ones accounted for 75% of usage. The author proposes five adjustments: keep context under 150,000 tokens, reduce parallel subagents, switch routine tasks to smaller models, and reserve premium models for planning—emphasizing that the real cost is context size and subagent fan-out, not code output.