[Bug] Usage limits (weekly and session) depleting much faster than expected

Same here, and I have numbers showing it is not a change in my usage.

Setup: I run a self-built "software factory" (Claude Code agents that plan, implement and review code across my own projects) on a Max 5x plan. Every agent session exports Claude Code's OpenTelemetry metrics (claude_code.cost.usage, claude_code.token.usage) to a local Prometheus, and I record the account's weekly utilization every 5 minutes from the rate-limit headers. So I can compare "API-equivalent $ spent" against "% of the weekly limit consumed" across weekly windows.

Result (same account, agent-only use, no manual chat):

| | Previous weekly window | Current weekly window (reset Oct 8, 18:00 UTC) |
| --- | --- | --- |
| Measured span (UTC) | Oct 3 09:30 – Oct 6 16:50 | Oct 8 18:04 – Oct 10 05:09 |
| Weekly utilization | 10% → 100% | 4% → 100% |
| API-equivalent cost in that span | $711 | $285 |
| $ per 1% of weekly limit | $7.90 (~$790 per full week) | $2.97 (~$297 per full week) |
| Opus 5.5 / Sonnet 5.5 share of cost | 89% / 11% | 68% / 32% |
| $ per 1M cache-read tokens | $0.273 | $0.281 |

The step change starts exactly at the weekly reset. It does not line up with any Claude Code version bump (versions moved almost daily from 2.1.283 to 2.1.296 with no step).

What did not change: the workload and token composition are essentially the same (cache reads per $ are flat), and this week actually has more Sonnet than last week, which should make the limit last longer, not shorter.

So the same workload now consumes the weekly limit roughly 2.5x faster than in the previous window. Could you confirm whether the weekly limit (or how usage is counted against it) changed around Oct 6–9?

Version: 2.1.294–2.1.296, Linux (WSL2)

Follow-up with a root cause candidate, and a correction to my previous comment: this does line up with a Claude Code version — 2.1.292. I missed it before because the OpenTelemetry metrics barely count 1-hour cache writes (see the last section).

I parsed the session transcripts (~/.claude/projects/**/*.jsonl, deduplicated by message id + request id) and looked at cache_read_input_tokens / cache_creation_input_tokens per request.

1. Cache writes jumped ~4–5x starting with 2.1.292 (main-thread requests, all agents)

| Version | Requests | cache write / cache read | Cache "busts" per 100 requests | Median gap before a bust |
| --- | --- | --- | --- | --- |
| 2.1.289 | 43,930 | 1.5% | 0.48 | 5,988 s |
| 2.1.291 | 17,343 | 1.9% | 0.59 | 768 s |
| 2.1.292 | 11,381 | 8.2% | 5.53 | 4 s |
| 2.1.293 | 1,815 | 11.1% | 6.67 | 5 s |
| 2.1.294 | 4,965 | 7.6% | 4.95 | 4 s |
| 2.1.295 | 14,738 | 6.7% | 4.04 | 4 s |
| 2.1.296 | 7,717 | 8.3% | 4.44 | 4 s |

A "bust" here = a request whose cache read drops below 50% of the previous request's prompt (>60k tokens) and writes >40k. Up to 2.1.291 busts happen after long idle gaps (TTL expiry). From 2.1.292 they happen ~4 seconds after the previous request: the cache read falls back to ~22k–47k tokens (tools + system prompt) and the whole conversation is re-written to the 1h cache. All of these writes are ephemeral_1h_input_tokens.

2. Trigger: a mid-session deferred_tools_delta attachment

Almost every bust is preceded by an attachment of type deferred_tools_delta (deferred tool list changed mid-session, e.g. MCP tools removed/re-added). The delta itself is not new; what changed is how often it busts the cache:

| Version | Mid-session deferred_tools_delta | Followed by a cache bust |
| --- | --- | --- |
| 2.1.286–2.1.291 | 99–3,234 per version | 6–14% |
| 2.1.292–2.1.296 | 170–1,193 per version | 52–71% |
| Busts without a preceding delta | — | 0–8 per version (rare in all versions) |

So since 2.1.292, a change to the deferred tool list mid-session seems to rewrite something early in the prompt (after the system prompt, before/within the first messages), invalidating the cached conversation.

A short claude -p run (30 sequential Read calls, no MCP churn) does not reproduce it on 2.1.296 (0 busts, with or without MCP_PROTOCOL_NEGOTIATION=legacy), which is consistent with the delta being the trigger.

3. Impact on limits

Using list prices as a proxy (Opus 5.5: cache read $0.20/M, 1h write $8/M), the effective cost per cache-read token went from ~$0.32/M (Oct 5) to ~$0.73/M (Oct 9), i.e. ~2.3x — which matches the ~2.5–2.7x faster weekly-limit drain I reported above.

4. Separate issue: OpenTelemetry under-counts 1h cache writes

For the same session, claude_code.token.usage{type="cacheCreation"} reports only 1/17–1/75 of the cache_creation_input_tokens in the transcript (where all writes are ephemeral_1h). claude_code.cost.usage is correspondingly low. This is why the regression was invisible in OTel-based dashboards; I can file it separately if useful.

Environment: Linux (WSL2), Claude Code 2.1.283–2.1.296, interactive sessions in tmux, several MCP servers (HTTP + stdio) and plugins with hooks.

One more follow-up. I checked whether the cause was on my side rather than in Claude Code: my orchestrator relaunches each agent session with claude --session-id … "<prompt>" for every new turn, and every relaunch reconnects the MCP servers (including an HTTP server the agents use heavily).

My side does not look like the cause:

• The number of relaunches per day did not change around Oct 7 (Oct 1–6: 326–935/day, Oct 7–10: 273–739/day).
• Nothing changed in my orchestrator around the step (which starts at ~19:00 UTC on Oct 6, when the machine picked up 2.1.292).
• The MCP reconnect-on-relaunch pattern (deferred tool list changing a few seconds into the turn) is just as frequent on 2.1.286–2.1.291, but there it rarely invalidated the cache (6–14% of deltas vs 52–71% on 2.1.292+).

What the debug log shows on 2.1.296 (one relaunch, times UTC):

11:52:23.405  MCP server "plugin:…": Successfully connected (transport: http) in 176ms
11:52:34.219  Dynamic tool loading: 0/20 deferred tools included
11:52:34.226  [API REQUEST] /v1/messages source=repl_main_thread      <- 1st request, MCP tools not in the deferred list yet
11:52:37.671  ToolSearchTool: cache invalidated - deferred tools changed
11:52:37.701  Dynamic tool loading: 8/105 deferred tools included
11:52:37.708  [API REQUEST] /v1/messages source=repl_main_thread      <- 2nd request: cache_read falls to the system prompt, whole conversation re-written

So the MCP server is already connected ~11 s before the first request, but its tools are not in the deferred tool list for that request; they are added ~3 s later, which changes the prompt and busts the cache. 973 of the busts since 2.1.292 are at the first requests of a turn (only 11 mid-run). The 2.1.292 changelog entry "the first turn no longer waits for HTTP and SSE MCP servers to answer resources/list" may be related, although these are interactive sessions, not -p.

MCP_CONNECTION_NONBLOCKING=0 and CLAUDE_CODE_MCP_STARTUP_WAIT_MS=10000 did not change the first-request deferred list in my quick -p --resume test (the plugin MCP tools never appeared there at all, so that test is not conclusive).

As a workaround I pinned Claude Code to 2.1.291 (claude install 2.1.291 + DISABLE_AUTOUPDATER=1) and will report whether the cache-write ratio goes back to ~1.5–2%.

Correction: pinning to 2.1.291 did not help, so the version is probably not the cause.

After claude install 2.1.291 + DISABLE_AUTOUPDATER=1, all of my agent processes ran the 2.1.291 binary (checked via /proc/<pid>/exe and the version field in the transcripts). In the first ~35 minutes:

| Binary | Requests | Turn starts | Cache busts | Busts / 100 requests | cache write / cache read |
| --- | --- | --- | --- | --- | --- |
| 2.1.291 (freshly relaunched agents) | 442 | 207 | 35 | 7.9 | 10.7% |

Before Oct 7, the same 2.1.291 binary ran 17,343 requests at 0.59 busts / 100 requests and 1.9% write/read. So the same binary behaves differently now. The step on Oct 6 ~19:00 UTC coincided with my machine auto-updating to 2.1.292, which misled me.

What still holds:

• The busts happen on the first requests of a freshly launched/resumed session (mid-run busts are rare).
• They follow a deferred_tools_delta (MCP tools added to the deferred tool list a few seconds into the turn, even though the HTTP MCP server is already connected before the first request).

So this now looks like something that changed around Oct 6 ~19:00 UTC outside the binary — e.g. a server-side / remote-config change to tool search / deferred tool loading or to prompt caching — rather than a specific Claude Code release. I've removed the pin and am back on the latest version.

Update after a day of A/B tests on my side. Short version: nothing I can change locally brings the cache-miss rate back to the pre-Oct-6 level, and the symptom matches #100065 / #99833 (resumed sessions on Opus 5.5 / Sonnet 5.5 re-writing history since Oct 6, also on binaries that were fine before).

Metric: a "bust" = a main-thread request whose cache_read_input_tokens drops below 50% of the previous request's prompt (>60k tokens) while it writes >40k. Counted from transcripts (deduplicated by message id + request id).

Turn starts (first request of a turn), all agents

| | Relaunched process (claude --session-id … with history) | Same process |
| --- | --- | --- |
| Before Oct 6 ~19:00 UTC | 5.0% bust (9,247 turns) | 0.8% (40,392) |
| After | 37.2% (2,535) | 6.8% (15,222) |

Gap before a bust

| Gap since previous request | Before Oct 6 (797 busts) | After (2,041 busts) |
| --- | --- | --- |
| < 10 s | 1% | 72% |
| 10 s – 5 min | 11% | 7% |
| 5 min – 1 h | 25% | 9% |
| > 1 h | 63% | 12% |

So before Oct 6 busts were mostly genuine TTL expiry; after, most happen seconds after the previous request.

What I tried (each on all agents, ~30–60 min windows, Claude Code 2.1.291–2.1.296):

| Change | Result |
| --- | --- |
| Pin binary to 2.1.291 (+ DISABLE_AUTOUPDATER) | No change (7.7 busts / 100 requests, write/read 10.4%) — this binary was at 0.6 / 1.9% before Oct 6 |
| ENABLE_TOOL_SEARCH=false | deferred_tools_delta events went to 0, busts did not drop (5.1 / 100 requests) — so the deferred-tool churn I suspected earlier is not the cause |
| Same MCP tool list for every agent (my server filters tools per agent) | No improvement |
| CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 | Busts < 10 s after the previous request dropped (72% → 19% of busts) but the total did not (6.9 / 100 requests, write/read 7.0%); inconclusive, small sample |
| Checked TTL | 100% of cache writes are ephemeral_1h before and after Oct 6, so it is not a TTL change |

Account switches (different org between turns) bust ~97–100% of the time, as expected, but they are <1% of turns and unchanged across Oct 6.

My conclusion: a server-side change around Oct 6 ~19:00 UTC makes resumed / relaunched sessions on the 5.5 models miss the cached history, which roughly doubles–triples weekly-limit consumption for a relaunch-heavy agent workload. As a mitigation I'm going to keep agent processes alive between turns instead of relaunching them.

Result of the mitigation (keeping agent processes alive between turns instead of relaunching them with history).

Since 2026-10-10 18:44 UTC my orchestrator keeps an agent's process alive for 60 minutes after its turn ends, so the next turn usually goes to the live process instead of claude --session-id … --resume-style relaunch. Same time window (18:44–23:07 UTC), previous day vs. after the change:

| | Oct 9→10 (before) | Oct 10→11 (after) |
| --- | --- | --- |
| Relaunches (orchestrator log) | 111 | 26 |
| Turns continued in the live process | 16 | 52 |
| Cache busts / 100 requests | 3.56 | 0.96 |
| cache write / cache read | 7.3% | 3.1% |
| Bust rate at turns that relaunched | 50% (70/140) | 8% (8/100) |
| Bust rate at turns in the same process | 4.4% (60/1,363) | 1.6% (16/992) |

So avoiding resume/relaunch removes most of the extra cache writes, which is consistent with #100065 / #99833 (resumed sessions on Opus 5.5 / Sonnet 5.5 not reading the cached history since ~Oct 6). It is a workaround, not a fix: the pre-Oct-6 baseline was 0.5–0.8 busts / 100 requests and ~1.5–1.9% write/read, and any workflow that resumes sessions is still affected.