Opus 4.6 token consumption significantly higher than 4.5 - quota feedback from Max subscribers

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23690
2. https://github.com/anthropics/claude-code/issues/23318
3. https://github.com/anthropics/claude-code/issues/23680

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

For even straightforward tasks, I'm seeing Opus 4.6 do significantly more preparation, and pull in way too much context ahead of time, compared to 4.5.

Per https://www.reddit.com/r/ClaudeCode/comments/1qx8zu4/if_you_still_want_to_use_opus_45/, I've verified I can peg my local CC to 4.5 by adding the following to my project's .claude/settings.json file.

{
  "model": "claude-opus-4-5",
  "env": {
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-5-20251101"
  }
}

I have just exhausted session limit on Max 5x with Opus 4.6 in ~15 mins on what seemed like a simple task, maybe there is something that just hoggs tokens in Opus 4.6, haven't had this issue with Opus 4.5.

I didn't even know a new version came out until I hit 90% of my five hour session doing research that normally would have taken ~10% of my five hour limit.

Indeed, the usage limit is consumed significantly faster (Max Plan). You use it for 40-45 minutes and you've used up all your tokens (from the 5-hour batch, which has also increased; it used to be 4 hours), which didn't happen before when doing the same tasks.

Not a duplicate of any of these:

• #23690 is about Sonnet usage counting against Opus quotas
• #23318 is about limits being reduced generally (filed before 4.6 launched)
• #23680 is about requiring Extra Usage for 4.6 access

This issue is specifically about Opus 4.6's per-task token consumption being measurably higher than 4.5 - same tasks, same workflows, significantly more tokens used. The comments here are already confirming this pattern independently.

Additional data point: Artificial Analysis benchmarks show Opus 4.6 generated 11M tokens during their standardized evaluation vs a 3.8M average across models - nearly 3x more verbose at the same task. Same API pricing as 4.5, but the model is producing significantly more output per task. This aligns with what everyone here is experiencing with quota burn.

I have been working with Opus 4.5 the last two months without reaching the Max plan limit.

With Opus 4.6 and similar workloads, I reach the limit in less than 2 hours.

Opus 4.6 is completely broken. Not to mention its extreme slowness.

One request, about 30-40 files to diff in a request to create a git log.
They were all minor type error fixes, removal of unused imports.
Some redundant file deletions.
Cost me 48% of 5h usage for the prompt to "analyze unstaged work and compile a commit message".
This used to take maybe 15%? max?

Same here, I am finding this to much token consumer

Is there any way to switch back to Opus 4.5 in Claude Code?

Growing community evidence (Feb 7-9, three days post-launch)

The conversation is intensifying, not calming down. Here are the most directly relevant reports - people who explicitly compare their 4.5 experience to 4.6:

Reddit:

• 343 upvotes, 147 comments - "As a Claude Code devotee I am currently using Codex to do 95% of my coding." Top comment (104 upvotes): "the plan went from the best deal around to the biggest headache."
• 58 upvotes - "It reads EVERYTHING, sometimes repeatedly, when it shouldn't. Burns 5 hour/weekly subscription limits like crazy." Theory: "4.6 was designed with 1M context in mind so it just chews through tokens."
• 26 upvotes, data-backed - User analyzed ccusage logs showing Pro session value dropped from ~$6 to ~$4, independent of the model change.

Twitter (direct 4.5 vs 4.6 comparisons):

• @xBenJamminx: "Opus 4.6 is eating up an incredible amount of my usage. It's definitely better than 4.5, but not 70% more usage better. I actually need to downgrade to Sonnet 4.5 or I'm gonna hit my weekly limit within 3 days"
• @buildwithgreg: "Feels like Opus 4.6 consumes limits 2-3 times faster than 4.5"
• @htihle (AI researcher): "extremely token hungry... average of 32k output tokens per request with default adaptive reasoning. Several times not able to finish within the maximum 128k tokens"
• @Jungle_Fren: "I never hit the limit with opus 4.5"

Growing community evidence (Feb 7-9, three days post-launch)

The conversation is intensifying, not calming down. Here are the most directly relevant reports - people who explicitly compare their 4.5 experience to 4.6:

Reddit:

• 343 upvotes, 147 comments - "As a Claude Code devotee I am currently using Codex to do 95% of my coding." Top comment (104 upvotes): "the plan went from the best deal around to the biggest headache."
• 58 upvotes - "It reads EVERYTHING, sometimes repeatedly, when it shouldn't. Burns 5 hour/weekly subscription limits like crazy." Theory: "4.6 was designed with 1M context in mind so it just chews through tokens."
• 26 upvotes, data-backed - User analyzed ccusage logs showing Pro session value dropped from ~$6 to ~$4, independent of the model change.

Twitter (direct 4.5 vs 4.6 comparisons):

• @xBenJamminx: "Opus 4.6 is eating up an incredible amount of my usage. It is definitely better than 4.5, but not 70% more usage better. I actually need to downgrade to Sonnet 4.5 or I am gonna hit my weekly limit within 3 days"
• @buildwithgreg: "Feels like Opus 4.6 consumes limits 2-3 times faster than 4.5"
• @htihle (AI researcher): "extremely token hungry... average of 32k output tokens per request with default adaptive reasoning. Several times not able to finish within the maximum 128k tokens"
• @Jungle_Fren: "I never hit the limit with opus 4.5"

@cperezabo you can run claude with model param and it will start it with opus 4.5, or you can set env var as @andrewchilds mentioned above.

claude --model claude-opus-4-5-20251101


Towards the end of Opus 4.5, going into 4.6, I have noticed that I'm hitting my limits far too quickly on Max 20x plan. It's even worse now with 4.6

Opus 4.6 generated 11M tokens during their standardized evaluation vs a 3.8M average across models

Of course it performs better, but at what cost 🤔 I am falling back to 4.5.

Yesterday I went back to 4.5, the difference is brutal. 4.6 is not better than 4.5 in the same proportion of their cost, at all!

fwiw structured MCP output helps a lot with this. I built
https://github.com/Dave-London/pare — MCP servers for git, npm, test runners, build tools etc that return typed JSON via structuredContent instead of raw CLI text. Cuts 70-90% of tokens on verbose commands like git log, test output, lint results. Every token saved on tool output is more room for actual reasoning.

I feel bad for everyone who paid for an Annual max plan.
I understand your pain and frustration.
For everyone else : I switched to Codex and live is great again. Very low initial usage, high effort, EXTREMELY good feedback loops and therefor better work planning/execution for less costs and less mental state fluctuations.
Anthropic dropped the ball.

+1 this,

To test this I created 2 plans in planning mode and then executed it on both Opus 4.5 and 4.6. Opus 4.5 completed the entire plan and had about 20k tokens left in it's context, Opus 4.6 hit 0% context remaining before even getting close to finishing the plan..

Bug Description

After the Opus 4.6 release (Feb 5, 2026), my daily token consumption increased approximately 4x without any changes to my configuration, workflows, hooks, or CLAUDE.md files.

Evidence from /stats (Last 7 days, Models view):

| Period | Tokens/Day | Notes |
|--------|-----------|-------|
| Feb 4–6 | ~0 | Normal idle |
| Feb 6–7 | ~87k | First spike after Opus 4.6 appeared |
| Feb 8–10 | ~347k | 4x increase with same workload |

Model breakdown (last 7 days):

• Opus 4.6: 95.4% — In: 257.9k · Out: 288.8k
• Opus 4.5: 3.9% — In: 7.4k · Out: 14.7k
• Sonnet 4.5: 0.7% — In: 3.1k · Out: 1.1k

Key observations:

1. Output tokens (288.8k) exceed input tokens (257.9k), suggesting the model is generating significantly more verbose responses or consuming tokens via extended thinking
2. No changes were made to my setup — same projects, same hooks, same routines
3. The spike correlates exactly with the Opus 4.6 rollout date
4. This is consistent with issue #24243 (regression in per-turn token consumption)

Expected Behavior

Token consumption should remain consistent when user configuration has not changed. If the default model was silently upgraded to Opus 4.6, users should have been notified about the cost implications.

Questions

1. Was the default model automatically switched to Opus 4.6 without user opt-in?
2. Is extended thinking enabled by default on Opus 4.6, and does it count toward usage limits?
3. Are there known regressions in token efficiency between Opus 4.5 and 4.6?

Environment Info

• Claude Code version: 2.1.39
• Platform: macOS
• Plan: Pro Max 20
• No changes to hooks, MCP servers, skills, or CLAUDE.md

<img width="558" height="461" alt="Image" src="https://github.com/user-attachments/assets/0c745cc6-2247-409f-b11e-61228a748247" />

Agree with you, consumption is really fast.
Imo x1.5 to x3 what Opus 4.5 consume normally 😅
can even be more, if he goes looking around files many times

So broken, Weekly limit not hit, 5 Hr limit hit, Look when it says it resets

<img width="2364" height="987" alt="Image" src="https://github.com/user-attachments/assets/f8cf6938-002e-4b06-b31e-1f8eeff52741" />

<img width="1159" height="209" alt="Image" src="https://github.com/user-attachments/assets/f5b8bfa4-f557-4417-909f-e19ee1d36bd3" />

If things continue like this, Claude seems likely to lose people to Codex or Cursor. There are a lot of complaints. This excessive spending is very disturbing.

Week 2 update (Feb 11-14)

Hardest data point yet - u/leogodin217 on r/ClaudeCode analyzed actual session JSONL files. Opus 4.6 used 14.7 MB of context for a task that Opus 4.5 completed in 0.98-1.75 MB. Same coding sprint took 1 session on 4.5, required 3 on 4.6 due to context exhaustion.

Third-party pricing confirms independently - Windsurf now charges 8 credits for Opus 4.6 vs 5 for 4.5 (60% increase), despite identical API pricing from Anthropic.

Users reverting to 4.5 - Multiple reports of people switching back because 4.6 burns through limits too fast.

`## Execution Notes

• Use a Sonnet agent for integration work; test everything <<<----- didn't start Sonnet subagent
• Maintain code-quality standards (ty check, yarn lint, yarn check) <<---- mostly not relevant, 55% was used on exploring and "Fumbling" and "Drizzling"
• Do not create new components when existing ones can be upgraded <<----- Backfired when I asked to delete files because we use version control.... "it's still heavily used" . But you know youre'e going to replace it
• Do not assume; ask user when issues arise <------ didn't do it
• Track status per project-plan skill conventions <------ didn't do it.

`

It continued execution even during hard interrupts. it didn't use the project-plan skill to create a new folder inside my planning/ dir as has been the case since about first week of January, this is unfixable if you use planning mode first. It doesn't care. it just ignores you.
Even if the notes tell it what to do, it scans all the project plans... it knows what the Skill expects of it, and Codex follows it perfectly.

It auto compacted during its attempt to finally abort and write the files, and of course...it hit 100% of the 5h right at that moment, so it didn't manage to write the status file (todo list) ....
This is a cycle that will repeat forever.

• Use Sonnet: implementations garbage, does 10% and just destroys everything, try to steer it and it will just make it worse and forget other things.
• Use Opus: Half of the tokens gone before implementation starts, then ignores the workflows, finally doesn't manage to implement, and then we go back to spending 200k tokens on exploring all over again next round: "Let's check what has already been completed". And first tries to find its acknowledgement in the docs it writes itself, which it always writes in present tense.

"Oh perfect, I see the plan 41 mentions X has been implemented! Let's see what actually has been done..."

Fibrillating... (ctrl+c to interrupt).

Flatlined for 3m54s

I've already unsubscribed but it's getting to the point where I feel like even if people tell me that it has improved, I won't even try it again. I won't take the risk.
I'd rather spend 3x the money on Codex.

Anthropic dropped the ball.

The max plan just updated to enable 1 mill token usage but it charges extra usage. I am now checking out OpenAI Codex.

Somehow Anthropic manages to royally piss me off every 3-4 months to the point where I switch to OpenAI or Grok for a while until they fix whatever mess they created.

It's absolute ridiculous how unusable the claude cli has become with the claude 4.6 updates. Even compacting took 10% of my tokens in one go.

Same here. Usage with both 4.6 models burns through my Max 20 plan unbelievably fast. I've switched to Codex for now.

ME TOO

What's Wrong?

Since the Opus 4.6 update (launched ~February 5, 2026), my weekly quota consumption rate has increased approximately 2.5x compared to my established baseline usage pattern with the same plan and similar workloads.

Baseline (Pre-Opus 4.6)

• Plan: Max 5x ($100/month)
• Typical daily consumption: ~20% of weekly quota on heavy-use days
• Weekly pattern: Comfortably stayed within limits across a full work week
• Usage style: Standard development workflows via Claude Code (terminal)

Current (Post-Opus 4.6, as of February 19, 2026)

• Daily consumption: ~50% of weekly quota consumed in a single day
• Same workload type and intensity as before the model update
• No changes to workflow, context size, or parallel instance usage

Impact

At the current burn rate, my weekly quota is effectively exhausted in ~2 days instead of lasting the full week. This represents a ~2.5x reduction in usable capacity for the same subscription price, making the service significantly less viable for daily professional development work.

Expected Behavior

Weekly quota consumption should remain consistent with established baselines when performing equivalent workloads. If Opus 4.6 inherently consumes more tokens per interaction, this should be:

1. Clearly communicated to subscribers before the model switch
2. Reflected in adjusted quota allocations to maintain equivalent usable capacity
3. Accompanied by an opt-out option to remain on the previous model version

Evidence

| Metric | Pre-Opus 4.6 | Post-Opus 4.6 |
|---|---|---|
| Daily quota usage (heavy day) | ~20% | ~50% |
| Days until weekly limit hit | 5-7 days | ~2 days |
| Effective capacity reduction | baseline | ~2.5x less |

Related Issues

• #23706 — Opus 4.6 token consumption significantly higher than 4.5
• #17084 — Opus 4.5 usage limits significantly reduced since January 2026
• #16157 — Instantly hitting usage limits with Max subscription (490+ upvotes)
• #22435 — Inconsistent quota accounting changes in Max plan
• #20767 — Pro quota significantly reduced (~20 prompts per 5 hours)

Environment Info

• Platform: <!-- macOS / Linux / Windows — 여기에 OS 입력 -->
• Terminal: <!-- Terminal.app / iTerm2 / Windows Terminal 등 — 여기에 입력 -->
• Claude Code Version: <!-- claude --version 결과를 여기에 붙여넣기 -->
• Subscription: Max 5x ($100/month)
• Primary Model: Opus 4.6 (auto-upgraded)

Suggested Resolution

• Investigate whether Opus 4.6's longer reasoning chains / higher token output are being double-counted or inefficiently metered against quota
• If Opus 4.6 genuinely requires more tokens per task, proportionally increase Max plan quotas to maintain equivalent usable capacity
• Provide a user-facing dashboard with real-time token-level consumption breakdown (not just percentage)

Related: #27665 consolidates 30+ open issues around model routing (including this one). Includes binary analysis of the routing functions, real ccusage data showing 93.8% Opus on a Max plan, and a tiered fix proposal. The root cause of excessive token consumption for Max subscribers is that Claude Code has no automatic model routing — every turn uses the session model regardless of complexity.

<img width="688" height="1196" alt="Image" src="https://github.com/user-attachments/assets/6cc0280f-bc5e-4fed-b46d-d65635c6bdcb" />

Opus 4.6's extended thinking mode burns tokens 2–4x faster than 4.5 for the same tasks. There's a one-line settings fix to pin back to 4.5 while keeping all other Claude Code behavior intact. Workaround + root cause documented here: https://cacheoverflow.dev/blog/9gMRxihS

Great writeup. The token consumption difference is real and it compounds with how Claude Code handles context, it re-reads files on every request without structural awareness of what's actually needed for the task.

With 4.5 this was expensive. With 4.6 eating 20-30% more tokens per request, the same workflow costs significantly more because the waste scales with the model's appetite.

The most impactful mitigation I've found isn't on the model side, it's reducing what goes into context in the first place. Serving the agent a dependency graph of the relevant code nodes via MCP instead of letting it read entire files cuts ~70% of the input tokens. That alone absorbs the 4.6 increase and then some.

I built an MCP server for this vexp.dev but the principle applies regardless of tooling, anything that reduces unnecessary file reads will help a lot more now that per-token cost has gone up.

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

meh in free version using 4.5 model hits me the limit for chatting 3 conversations ... "in a different window for each question"

GitHub Comment Draft — anthropics/claude-code #23706

Issue: Opus 4.6 token consumption significantly higher than 4.5 - quota feedback from Max subscribers
Status: OPEN, NOT LOCKED (36 comments)
Action: NEEDS AUDITOR REVIEW before posting.

---

Prepared Comment

Great writeup, and the community data here is solid. I've been doing quantitative analysis on Claude Code session logs and can add some numbers to the discussion.

The JSONL transcripts in ~/.claude/projects/ contain per-turn token breakdowns (input, output, cache_read, cache_creation) plus model identifiers. Parsing these across sessions gives a much clearer picture than the /cost command, which only shows session totals.

What I've found in my own sessions post-4.6:

1. Output tokens per turn are higher. 4.6 is more verbose -- it generates longer reasoning chains and more detailed tool call arguments. This is arguably better quality, but it costs more per turn.

1. Cache thrashing is worse with longer outputs. Longer assistant turns shift the context window faster, which means cache entries expire sooner. You pay for cache creation more often and get fewer cache reads. This is the multiplier effect people are feeling.

1. The model selection lever is still the biggest one. Even with 4.6's higher per-turn cost, routing simple operations (file reads, grep, small edits) to Sonnet instead of Opus cuts session costs dramatically. In my analysis, 70-90% of turns in a typical session are "simple" by any reasonable definition.

For anyone who wants to see the actual per-turn breakdown of their sessions:

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

This gives you: per-model cost attribution, the 10 most expensive individual turns, cache efficiency metrics, and estimated savings from model routing. It parses the same JSONL files Claude Code already writes -- runs locally, nothing sent anywhere.

Quick preview of the output format (no install needed):

curl -s https://api.agentsconsultants.com/forensics/sample | jq .

The tl;dr from my data: 4.6 does use more tokens per turn, but the dominant cost factor is still model selection. Adding Use Sonnet for routine tasks to your CLAUDE.md is the single highest-leverage change you can make today.

Full disclosure: I built agent-forensics. It's MIT-licensed.

GitHub Comment Draft — anthropics/claude-code #23706

Issue: Opus 4.6 token consumption significantly higher than 4.5 - quota feedback from Max subscribers
Status: OPEN, NOT LOCKED (36 comments)
Action: NEEDS AUDITOR REVIEW before posting.

---

Prepared Comment

Great writeup, and the community data here is solid. I've been doing quantitative analysis on Claude Code session logs and can add some numbers to the discussion.

The JSONL transcripts in ~/.claude/projects/ contain per-turn token breakdowns (input, output, cache_read, cache_creation) plus model identifiers. Parsing these across sessions gives a much clearer picture than the /cost command, which only shows session totals.

What I've found in my own sessions post-4.6:

1. Output tokens per turn are higher. 4.6 is more verbose -- it generates longer reasoning chains and more detailed tool call arguments. This is arguably better quality, but it costs more per turn.

1. Cache thrashing is worse with longer outputs. Longer assistant turns shift the context window faster, which means cache entries expire sooner. You pay for cache creation more often and get fewer cache reads. This is the multiplier effect people are feeling.

1. The model selection lever is still the biggest one. Even with 4.6's higher per-turn cost, routing simple operations (file reads, grep, small edits) to Sonnet instead of Opus cuts session costs dramatically. In my analysis, 70-90% of turns in a typical session are "simple" by any reasonable definition.

For anyone who wants to see the actual per-turn breakdown of their sessions:

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

This gives you: per-model cost attribution, the 10 most expensive individual turns, cache efficiency metrics, and estimated savings from model routing. It parses the same JSONL files Claude Code already writes -- runs locally, nothing sent anywhere.

Quick preview of the output format (no install needed):

curl -s https://api.agentsconsultants.com/forensics/sample | jq .

The tl;dr from my data: 4.6 does use more tokens per turn, but the dominant cost factor is still model selection. Adding Use Sonnet for routine tasks to your CLAUDE.md is the single highest-leverage change you can make today.

Full disclosure: I built agent-forensics. It's MIT-licensed.

Sessions are getting shorter from both ends: Opus 4.6 with extended context burns tokens faster, and Anthropic is now throttling peak-hour sessions on top of that.

Disabling the 1M context window brought me from ~15 minutes of usable session back to 2-4 hours:

CLAUDE_CODE_DISABLE_1M_CONTEXT=1

Confirming Opus 4.6 consumption is dramatically worse. Max 20, v2.1.89, April 1: 100% in ~70 min after reset with light conversational coding. Same workflow worked fine for months on earlier Opus versions.

Full report: #41788
Related: #38335, #38239, #40895, #41663, #41779

I've been experiencing the same issue on Max 20 ($200/mo) — rate limit 100% exhausted in ~70 minutes.

After setting up a monitoring proxy using the official ANTHROPIC_BASE_URL env var, I identified two cache bugs as the root cause (#40524, #34629) and measured the impact: cache read ratio dropped to 4.3%, meaning ~20x token inflation per turn. After applying workarounds it stabilized at 89-99%.

Full analysis with per-request measured data, safe workarounds, and community references (including cc-cache-fix): https://github.com/ArkNill/claude-code-cache-analysis

Update (April 2): Much of the perceived Opus 4.6 consumption spike was likely compounded by the cache bug (Sentinel regression in standalone binary). v2.1.90 fixes this — benchmark shows 95-99% cache read in stable sessions, dramatically reducing effective token cost.

Update to v2.1.90 to isolate actual model cost from cache bug overhead: https://github.com/ArkNill/claude-code-cache-analysis

April 3 update: v2.1.91 fixes the cache regression that caused the worst drain. If you are still hitting limits after updating, there are additional unfixed mechanisms: a 200K tool result budget cap, a client-side false rate limiter, and silent context stripping — all confirmed via proxy testing. Anthropic acknowledged peak-hour tightening on X (Lydia Hallie) but stated "none were over-charging you." Measured data and analysis: claude-code-cache-analysis

Opus 4.6 consuming more tokens than 4.5 is partly because extended thinking blocks (with long signatures) accumulate in the session JSONL and get re-sent every turn.

Cozempic v1.4.1 has a thinking-blocks strategy that strips thinking content and signatures (2-5% savings), plus compact-summary-collapse that removes 85-95% of pre-compaction bloat. The guard daemon runs these automatically.

pip install cozempic && cozempic init

v1.4.1 also auto-detects 1M context models so thresholds are correct. Feedback welcome on Opus 4.6 specifically.

I built a tool that stacks the known mitigations for this. Measured 32% token reduction on real claude --print invocations (parsing usage.input_tokens, cache_read, output_tokens, total_cost_usd from the JSON result).

The biggest wins for Opus 4.6 specifically:

• MAX_THINKING_TOKENS=8000 in settings.json — caps extended thinking from 32K+ default. 50-70% savings on straightforward tasks where 4.6 over-thinks.
• Response shaping in CLAUDE.md — drops preamble/recap/filler. 40-65% fewer output tokens (benchmark: https://github.com/JuliusBrussee/caveman).
• Early compaction at 80% instead of 95% — keeps context smaller per turn.

One command to install all 12 optimizations:

curl -fsSL https://raw.githubusercontent.com/sravan27/context-os/main/setup.sh | bash

Or dry-run first to see what you'd save (no writes):

curl -fsSL https://raw.githubusercontent.com/sravan27/context-os/main/setup.sh | bash -s -- --measure

Fully reversible with --uninstall. MIT. https://github.com/sravan27/context-os