Opus 4.7 burn rate data: DISABLE_ADAPTIVE_THINKING reduces Q5h consumption by 3.3x

[cnighswonger]

Background

We ran controlled burn rate testing on Opus 4.7 across two phases, measuring Q5h consumption per call and per hour on a Max 5x account. Both phases used the same long-running coding session (kanfei weather inference engine) routed through a local proxy for isolated per-request telemetry.

Results

Metric	Phase 1 (adaptive thinking ON)	Phase 2 (thinking OFF)
Calls	230	93
Burn rate	12.9%/hr	3.9%/hr
Q5h/call	0.87%	0.75%
Avg output/call	522	1,174
Avg cache_read/call	111,910	128,936

3.3x reduction in Q5h burn rate with CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1, despite Phase 2 producing 2.25x more output per call with larger context.

What this means

Adaptive thinking tokens are invisible — they don't appear in the API response's output_tokens field — but they're charged against your Q5h quota. In our testing, they account for roughly 2/3 of total Q5h consumption on Opus 4.7.

The per-call Q5h cost dropped from 0.87% to 0.75% even though Phase 2 had heavier output and larger context. The invisible thinking overhead dwarfs the visible token cost.

Workaround

export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1

Set before launching Claude Code. This disables adaptive thinking on 4.7, giving you a burn rate comparable to 4.6. The tradeoff: you lose the model's self-directed reasoning depth, which may affect quality on complex tasks. In our sustained coding workload, we didn't notice a quality difference — but your mileage may vary.

Methodology

• Both phases used the same session, same codebase, comparable coding workloads
• Telemetry captured via local HTTP proxy (request/response isolation per call)
• Q5h data from anthropic-ratelimit-unified-5h-utilization response headers
• Only proxy-routed calls counted (no contamination from other sessions on the same account)
• Phase 1 spanned ~15 hours, Phase 2 spanned ~18 hours
• Multiple Q5h windows analyzed; segments crossing reset boundaries excluded

For contrast

OpenAI's Codex GPT reports reasoning tokens as an explicit line item in usage data (reasoning: 77,473). Anthropic's adaptive thinking tokens are invisible in the API response but charged against quota. The transparency gap makes it impossible to build accurate cost models from API data alone.

[cnighswonger]

Update: Q7d is the binding constraint, not Q5h

After sustained multi-session work on Max 5x, we've confirmed that Q5h is a burst limiter but Q7d is the actual budget ceiling. Q5h resets every few hours — even at 80%+ utilization, it naturally rolls over. Q7d accumulates all week and decays slowly (oldest day rolls off, not a full reset).

At the time of this testing we focused on Q5h burn rate. What we've since observed: every Q5h window you burn through adds to the Q7d pile. The 3.3x reduction from disabling adaptive thinking doesn't just help per-session — it compounds across the entire week. On a Max 5x account doing regular multi-agent coding work, Q7d hits allowed_warning (surpassed-threshold: 0.75) well before any individual Q5h window maxes out.

The anthropic-ratelimit-unified-7d-surpassed-threshold: 0.75 header started appearing in our telemetry at Q7d=76%, with representative-claim shifting from five_hour to seven_day — the server telling us Q7d is now the governing limit.

@ArkNill independently measured Opus 4.7 burning Q5h at 2.4x–2.6x the rate of 4.6 across two different intercept setups (advisory). That multiplier, applied across a full work week, explains why Q7d becomes the wall even when individual sessions feel manageable.

Bottom line: CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 isn't just a per-session optimization — it's the difference between hitting the Q7d ceiling mid-week or not.