Something felt off for a lot of Claude Code users recently.
Usage was climbing. Credits were draining faster than usual. But the prompts hadn't changed. It took developers setting up HTTP proxies and capturing actual request traffic to find an answer: in Claude Code v2.1.100, each API request may be automatically appending roughly 20,000 tokens that users never see, never wrote, and can't control.
There's a second piece to this. According to community reports, Anthropic quietly reduced Claude Code's cache TTL from 1 hour to 5 minutes back in March. Individually, either change would be worth noting. Together, they describe a tool whose real cost structure may have been rewritten without any announcement.
Both claims currently come from developer community analysis — proxy captures, forum threads, independent reproduction attempts. Anthropic has not published a full official response. That silence is part of the problem.
Most Users Only Track the Visible Costs
Claude Code's pricing looks transparent on the surface. Token-based billing, subscription tiers with usage caps, model-specific rates — all of it is documented somewhere.
Most developers' mental model of "what Claude Code costs" stops there: I send X, I pay for X.
That's a reasonable assumption. It's also incomplete.
Where the Hidden Costs Actually Live
Claude Code isn't a chatbot. Running it in a real development environment means carrying a lot of context that has nothing to do with what you typed: tool call instructions, security constraints, behavioral rules, shell state, project structure, environment descriptions. These are appended at the system level, automatically, invisibly.
How much of this exists has always been unclear to users. If the developer findings hold up, v2.1.100 may be attaching close to 20,000 tokens of this invisible context per request. For scale: 20,000 tokens is roughly equivalent to a 15,000-word document, or a moderately complex function with full inline documentation. That's being sent — and billed — whether your prompt is a paragraph or a single sentence.
The Shorter Cache Window Makes It Worse
If the hidden system context were at least reliably cached, users could partially absorb the cost. One expensive request, then the cache carries the overhead forward for a while.
A 5-minute TTL removes that option for most real workflows.
Development doesn't happen in continuous five-minute sprints. You write something, run tests, read an error message, switch windows, think for a bit, come back. That's normal. Under a 1-hour cache window, the system context from your last request stays warm through most of that. Under 5 minutes, it almost certainly doesn't. The invisible 20,000 tokens get re-sent and re-billed on the next request.
The compounding math isn't complicated: if hidden token overhead is fixed at ~20,000 per request, and cache hit rate drops from 70% to 20% due to the shorter TTL, actual token consumption more than doubles — with zero change to what the user typed.
Visible vs. Hidden Cost Breakdown
| Cost Component | What It Is | User Can See? | User Can Control? |
|---|---|---|---|
| User prompt | What you actually typed | ✅ | ✅ |
| Model output | Response tokens | ✅ | Partially |
| System prompt | Platform instructions | ❌ | ❌ |
| Hidden context (v2.1.100) | ~20,000 tokens/request | ❌ | ❌ |
| Cache savings | Reduced significantly at 5-min TTL | ❌ | ❌ |
Who Gets Hit Hardest
Most affected: Developers using Claude Code daily for real engineering work, especially those with fragmented workflows — debug, switch context, come back, iterate. Short cache TTL and high hidden token overhead compound directly against this pattern.
Moderately affected: Developers doing longer code reviews or refactoring sessions. Higher per-request cost, but denser task sequences mean cache expiry matters slightly less.
Least affected: Occasional users running one-off queries without needing session continuity. For them, the cache strategy barely matters and the hidden token overhead is spread across fewer requests.
FAQ
Is the hidden token claim confirmed? Has Anthropic said anything officially?
Multiple developers have reported independent reproduction via proxy analysis. As of now, there is no complete official statement from Anthropic on what v2.1.100 changed or why.
Was the cache TTL reduction announced?
Community reports place this change around March. No formal changelog or announcement from Anthropic has surfaced.
How much does this actually affect billing?
It depends heavily on usage frequency and workflow patterns. For high-frequency daily users, if both changes hold up, real monthly costs could run significantly higher than what users would estimate from the documented pricing. Precise figures require Anthropic to disclose the actual system context size and caching policy.
Can users opt out or work around this?
There's no in-tool setting to reduce system context. Direct API access is more transparent but loses the IDE integration that makes Claude Code useful. Not a practical option for most users.
The Real Issue
System prompts exist in every serious AI tool. Nobody expects a blank slate. The problem here isn't that hidden context exists — it's that it apparently grew to 20,000 tokens per request with no explanation, while a caching change that directly amplifies the cost impact was also made silently.
Developers can work with expensive tools. They do it constantly. What they can't work with is a cost structure they can't model, can't verify, and found out about through packet captures rather than release notes.
If the v2.1.100 findings continue to be reproduced, Anthropic has two specific questions to answer: what those 20,000 tokens actually contain, and whether the TTL reduction is a permanent platform decision or something that will be revisited.
Until those get answered directly, the community conclusion writes itself.
Note: The hidden token and cache TTL claims in this article are based on developer community reports and proxy analysis. Anthropic has not published an official response at time of writing. If official clarification is released, this article will be updated.