[Bug] Excessive token consumption in API requests

Same issue here. I'm on the $100 Max plan (5x limits) and for the last 2 days the 5-hour window limit gets exhausted in just a few prompts. Today I watched my usage jump from 27% to 57% after sending a single message to a teammate agent. Previously this plan lasted me a full week without hitting limits.

Environment Info

• Platform: darwin
• Terminal: iTerm2
• Version: 2.1.83
• Shell: zsh
• Usage: Claude Code with agent teams (teammates in iTerm2 split panes)

This started around March 24-25, 2026. Before that, the same workflows consumed significantly less tokens.

Same here. It happened around the 24th-25th as well. This is quite annoying; I actually thought my account had been hacked for a moment.

Yeah, same reaction here — I also suspected a security breach at first. I disconnected all active sessions, disabled all MCP servers, and even shut down all teammate agents. None of that helped — usage kept spiking.

And i thought i was tripping yesterday. Contacted the support and who answers: AI :'D
Said i use so much because i do other tasks then i did before. - No, i dont.
Used him today and did 2 Coding lines and boom... he was on 30% usage. Now everytime i ask a question or let him code something i can see the usage just go tick by tick. Thats NOT like it was before on max 5x

But i bet they try to blame it on us.

This is terrible.
If this was done intentionally, it would have been better to issue an official press release.
It's become impossible to work with Claude.

Seems to be fixed now.

No..still chunking up tokens like crazy.....codex is the way to go, its predictable atleast

The worst part of these spikes is you can't tell if it's a real increase in your usage or something broken on the metering side. You're just suddenly locked out.

Something that's helped me: CC v2.1.80+ pipes rate_limits data to the statusline, so you can watch your 5h/7d % move in real-time. I have a statusline plugin (claude-lens) that shows a pace indicator. If you're burning faster than the window allows, it goes red. At least makes the invisible visible.

Oh nice....I will enable the rate_limits in the status...i wonder if there are other plugins which also help identify where the tokens are most spend..but even then I dont think that will help...limiting too usage or file reads will then degrade the code quality

They keep on doing it, it is absolutely unethical https://github.com/anthropics/claude-code/issues/38910#issuecomment-4134768536

For where the tokens go, check out ccusage (https://github.com/ryoppippi/ccusage). It parses your JSONL session logs and shows per-session breakdowns.

And yeah, knowing won't raise the limit, but it can catch stuff that shouldn't be burning tokens. Someone just found that auto-memory silently forks your entire context into a parallel API call on every message. That alone can double your cost.

The core frustration here is the same one across a dozen related issues: there's no independent way to verify what's actually being consumed vs what the system reports.

One thing that can help: Claude Code writes per-turn token counts to JSONL transcript files in ~/.claude/projects/. By parsing these independently, you can get your own accounting of actual token consumption and compare it against what the API reports.

I did this for my own sessions and found that cache tokens (both creation and read) dwarf input/output tokens by 10-100x. In one 37-turn session:

• Input tokens: 81
• Output tokens: 7,322
• Cache read: 835,487
• Cache create: 160,485

If you're seeing "excessive" consumption, the JSONL data can tell you whether the issue is (a) cache creation thrashing, (b) Opus being used for simple tasks, (c) sub-agent sprawl, or (d) something on the accounting side.

A quick way to run this on your own sessions:

npx agent-forensics analyze ~/.claude/projects/-Users-you/ --full

This gives you per-turn token breakdowns, cache efficiency ratios, model attribution, and the single most expensive turns — enough to build your own accounting of what a session actually consumed.

Full disclosure: I built this tool. It runs locally and processes everything in-memory. The real fix is transparent quota accounting from the platform. But independent analysis of the JSONL logs can at least help document the discrepancy.

Experiencing the same issue. Max plan, Opus 4.5 — burned through 100% of my usage allocation in ~1 hour this morning. Currently at 20% after just 30 minutes across two light sessions (10-15% each). This is completely inconsistent with months of normal Claude Code usage on the same plan.

I have timestamped screenshots confirming the spike. Filed separately as #39966 with cross-references to other related reports (#38335, #38239, #39938, #39940, #37436, #39492). This is clearly affecting a large number of subscribers right now.

Yes...this is still going on...no relief..I burned through my whole 5 hrs in 2 prompts today..I think they are doing IN region the worst

Well... they said they dont. They did...

Has Anthropics commented on this? I'm considering informing the press and consumer protection agencies, as the payment plans are not being honored. These aren't isolated incidents; it looks like a problem or fraud being carried out in secret.

This kind of issue is tough because the token usage often isn’t obvious from what you think you’re sending — especially once you factor in system prompts, tool calls, or any injected context behind the scenes.

I’ve run into cases where everything looks normal at the surface level, but small structural differences end up causing massive token swings depending on how the request is assembled.

One thing that helped was breaking down the full request payload step-by-step (including hidden context) to see where the expansion is actually happening.

Are you seeing this consistently across sessions, or does it spike under certain workflows?

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.