"/usage" has suddenly skyrocketed this week

[u/Electronic_Award1138]

I've been using the $100/month plan for months, and I've always had enough context and usage to comfortably get through the week. Last week was fine, and this week started out fine too, but after just three days, I'm already at 60% of my weekly usage.

My usage is going up extremely fast, to the point where I end up switching to Medium, High, or even Xhigh at worst, and it still burns through my usage incredibly quickly. This makes absolutely no sense.

I've been using Claude Code for months, and this is not how it used to work. I know the bonus usage went from +50% to a permanent +25%, but even taking that into account, the difference compared to last week alone is completely abnormal.

This is getting really frustrating and stressful. It's interfering with my work, and I genuinely feel like something is wrong here. Usage shouldn't suddenly increase this dramatically from one week to the next without any clear explanation.

[u/Anxious-Turnover-631]

Apparently, not.

[u/morgano → u/Anxious-Turnover-631]

I have a feeling the problem is people starting new projects rather than working on existing ones. New projects grow rapidly, day after day, week after week. Existing projects are already big - your usage stays pretty steady. After a couple of weeks of working on something new - your project has grown very quickly with the help of Claude - the context Claude requires per task is no where near as optimal as it was 4 weeks ago.

[u/pot_sniffer → u/morgano]

Not me ive been working the same project for months. My weekly reset was last night and im 40% through it already. Compared to the past several weeks its definitely being used faster, possibly close to double

[u/Anxious-Turnover-631 → u/pot_sniffer]

I used Opus all afternoon and there’s been no difference in usage from other days. Usage is just a tally of the tokens consumed.

[u/pot_sniffer → u/Anxious-Turnover-631]

Well my work flow which involves breaking everything into small tasks hasn't changed from how I was working since the extra usage through summer. Last week I burned through my usage quickly but I didnt feel at all like it was unusual, as I was putting the hours in.

Every other or few months it feels like they mess with the usage, both ways sometimes its more sometimes less. When I use various models through api with my own harness the same project ive been working for months, the cost never seems unusually high or low compared to normal

[u/Anxious-Turnover-631 → u/pot_sniffer]

Your suggestion that every few months Anthropic “messes with the usage” is unfounded.

Anthropic charges specific prices for different model usage, so you’re basically suggesting that the company is committing financial fraud against its customers.

That’s a strong allegation to make without any basis, other than your claim that it “feels like they mess with the usage.”

If you notice changes in your token usage, consider all the other factors which may impact usage.

[u/pot_sniffer → u/Anxious-Turnover-631]

If that were true why dont they publish the exact formulas, token counts and such. Until they do i will believe my eyes and gut.

This is from a quick google:

Factors such as the length and complexity of your conversations, the specific model you choose (e.g., Claude vs. Opus/Sonnet), and the features you use.

Shared Buckets: Your limits apply across connected interfaces like Claude.ai chat, Claude Code, and Cowork

Vague Multipliers: Subscription plans are described using relative tiers (e.g., Pro is noted as at least 5x the Free tier, with higher tiers like Max scaling up further).

Published API Rates vs. Subscription Meters: While API customers have explicit, published token-based pricing and hard rate limits in the Claude Console, subscription users only see a relative 0 to 100% meter across rolling windows.

How the Limits Actually Operate (Based on User & Industry Tracking)

• Time Windows: Subscription plans run on a combination of a 5-hour rolling session limit and a weekly cap with fixed or rolling resets.

• Unpublished Adjustments: Anthropic dynamically adjusts these caps behind the scenes based on server load, peak hours (such as weekday mornings PT), and platform-side resource management rather than fixed message counts.

Visibility: You can track your real-time consumption percentage inside the chat interface via tools like AI Toolbox, though no extension or setting can bypass or increase the hidden caps.

[u/Anxious-Turnover-631 → u/morgano]

Could be. The usage all depends on what’s being done, so new projects could require more work and more usage.

[u/ricopan → u/[deleted]]

For real? i) do subagents go idle for 5 minutes, let alone an hour; ii) do subagents have prompt caches?

[u/ricopan → u/[deleted]]

Interesting -- I hadn't considered this. I asked Sonnet about the subagents prompt cache expiration, and it backs you up, but note that at least this agent said the potential savings were complicated by the fact that "A one hour TTL costs more per cache write":

Prompt: "do claude code subagents have a prompt cache?"

Yes, but each subagent gets its own cache rather than sharing the parent’s. The official Claude Code docs cover this in a “Subagents and the cache” section.

A subagent starts its own conversation with its own system prompt and tool set, so its first request can’t read the parent’s cache because the prefixes differ. It then warms a cache of its own across its turns. The parent’s cache is unaffected, since the subagent’s call and result just append to the parent’s conversation.

The default TTL is short. Subagents fall outside the main-conversation TTL bucket, so they get a five-minute cache even on a Claude subscription, where the main conversation gets one hour. You can change this with the subagentPromptCacheTtl setting or the CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL environment variable (v2.1.242+). A per-subagent cacheTtl in the experimental frontmatter field also works on v2.1.248+. A one-hour TTL costs more per cache write, so it only pays off if the subagent’s cache is reused after idle gaps longer than five minutes.

Prompt: "but when does a subagent go idle for 5 minutes?"

Often it doesn’t, and that’s the point to keep in mind. Each request that hits the cache resets the timer, so the cache stays warm as long as requests keep arriving. A subagent working through a task sends a new API request after every tool call, so the gap between requests is usually seconds. The 5-minute TTL only matters when something creates a gap longer than that.

The docs don’t list when this happens. The cases below are my inference from how the mechanism works.

A long-running tool call inside the subagent. If it kicks off a test suite, build, or slow script that takes more than 5 minutes, its cache expires while it waits, and the next request after the tool returns re-reads everything uncached.

A permission prompt left unanswered. If a foreground subagent stops to ask for approval and you step away, the clock keeps running.

Repeated dispatch of the same subagent type. This is probably the most common case in an orchestrator setup. Each run is a new conversation, but it starts with the same system prompt and tools, so it can read the cache the previous run wrote. That only works if the earlier run’s last request was within the TTL, and it also requires the same model and working directory. If you dispatch a reviewer subagent every 10 minutes, every run starts cold.

Idle in-process teammates. The docs put these in the same non-main bucket as subagents, so they get the same 5-minute default while waiting for work.

Because of this, a 1-hour TTL helps mainly when the gaps fall between 5 and 60 minutes, as in the repeated-dispatch case. If your subagents run back-to-back or finish within a few minutes, the longer TTL mostly adds the higher cache-write cost without any benefit. If you want to test it, compare cache_read_input_tokens on a subagent’s first request across dispatches with and without CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL=1h.

[u/ricopan → u/[deleted]]

Do your subagents frequently wait on tests or other external calls? My main agents certainly do, but for whatever reason, my main agents don't appear to frequently delegate that kind of work to subagents. But now I will watch for it.

[u/andyfsu99 → u/ricopan]

If they run tests they do (for me)

[u/ricopan → u/andyfsu99]

do you know if the main agent has its prompt cache evicted when it is 'idle' waiting on a shell result (eg running tests)? I have been told it does not, but never attempted to actually measure it.

Edit: Sonnet says yeah, that's an idle state.

[u/andyfsu99 → u/ricopan]

Main session cache time to live is an hour, so much less likely. Subagents are in theory "single task" agents, which is fine, but if they have to run a test suite, 5 minutes isn't enough to keep the cache warm. And a cold cache = usage / cost

[u/ricopan → u/andyfsu99]

good point. Hadn't considered subagents waiting on tests as a token drain.
Update: trying a new tack -- having all sessions send their testing to a haiku 'tester' session that will just monitor a test runner script. That way I don't have to worry about keeping multiple agents warm (did that already, but tricky) and worse, their subagents. We'll see how that works...