First metered Opus 4.7 session — elevated Q5h burn rate observed

[cnighswonger]

We ran our first metered Opus 4.7 session today (CC v2.1.111, Max 5x, US). The interceptor and meter worked correctly, but we observed an unusually high Q5h burn rate.

The data

Metric	Value
Model	claude-opus-4-7
CC version	2.1.111
Duration	38 minutes
API calls	71
Cache hit rate	99%+ (after initial cold start)
Cache creation	225K tokens
Cache read	5.95M tokens
API-equivalent cost	$6.20
Q5h consumed	~15%

What we observed

While the 4.7 agent was active alongside our long-running 4.6 session, Q5h burned at a rate we have never seen — even when running 3 agents simultaneously on 4.6. The Q5h went from 1% to 52% in approximately 30 minutes with both agents active.

After the 4.7 agent exited, burn rate appeared to normalize on the remaining 4.6 session.

What we can't isolate yet

Three variables changed at once:

• New model (Opus 4.7)
• New CC version (2.1.111)
• The specific workload (PBX analysis, code-intensive)

We cannot yet say whether the elevated burn rate is model-specific, version-specific, or workload-specific. It could also be a server-side change coinciding with the 4.7 launch.

What we're asking

If you're running Opus 4.7, please compare your Q5h burn rate to your 4.6 baseline. Key data points:

• Q5h % consumed per hour of active work
• Same workload type on both models if possible
• CC version

Report here or via claude-meter analyze.

Interceptor compatibility

For anyone wondering: the interceptor (v1.11.0+) works correctly with Opus 4.7. Salt, indices, fingerprint, TTL injection — all confirmed. The burn rate observation is about quota accounting, not cache behavior.

---

Data from Max 5x (US), April 16, 2026. Single session observation — seeking community validation before drawing conclusions.

[cnighswonger]

Update: Adaptive thinking may explain the burn rate

From the community discussion on anthropics/claude-code#42796:

Opus 4.7 deprecates manual extended thinking. The thinking: {type: "enabled", budget_tokens: N} parameter returns a 400 error on 4.7+. Only thinking: {type: "adaptive"} with an effort parameter is supported. Anthropic controls how much the model thinks, not the user.

This is potentially the missing variable in our Q5h burn rate observation:

• Adaptive thinking tokens may count against Q5h but are not visible in the standard usage response object
• @ArkNill identified "thinking token blind spot" as an open question in his analysis — thinking tokens are not returned in API responses, making them unmeasurable via normal instrumentation
• If 4.7's adaptive thinking allocates more thinking budget than 4.6's manual thinking, the invisible token consumption would show up as elevated Q5h drain with no corresponding increase in visible token counts

Our data is consistent with this hypothesis: The 4.7 session's visible token counts ($6.20 API-equivalent for 71 calls) don't explain ~15% Q5h consumption. Something invisible is adding to the quota bill.

What would confirm it:

• Compare Q5h drain per visible token on 4.6 vs 4.7 for equivalent workloads
• If 4.7 consumes more Q5h per visible token, the gap is likely thinking overhead
• @fgrosswig's gateway proxy may be able to capture thinking token data from the SSE stream that standard usage responses don't include

Also worth noting: multiple users on #42796 are reporting quality regressions on 4.7, with CLAUDE_CODE_EFFORT_LEVEL=max as a workaround. If "adaptive" means "less thinking by default," the cost savings for Anthropic come at the expense of output quality AND higher quota drain (less efficient reasoning = more iterations = more tokens).

This is developing. Will update as more data comes in.

[cnighswonger]

Update: Quantified the gap — 4.7 burns Q5h at 2.4x the rate of 4.6

We diffed visible token costs against actual Q5h consumption for the 4.7 session:

Metric	Opus 4.6	Opus 4.7
Avg Q5h per turn	~0.3%	~0.73%
Ratio	1x	2.4x
Q5h per visible MTok	~1.05e-5	~1.35e-5

The visible token counts (input, output, cache_read, cache_creation) don't account for the difference. The gap is consistent with invisible thinking token overhead being charged against quota but not reported in the API usage response.

With 4.7's mandatory adaptive thinking, the model consumes thinking tokens on every call. These tokens are invisible in the usage response but DO count against Q5h. The 2.4x burn rate is the thinking overhead made measurable by its shadow on the quota meter.

Filed: anthropics/claude-code#49320 — feature request for thinking_tokens in the usage response.

For users upgrading to 4.7: Expect your Q5h budget to go roughly half as far as it did on 4.6 for equivalent workloads. Plan accordingly.

[cnighswonger]

Update: CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 may be the key

@X-15 suggested testing with CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1. Quick result:

Call	Adaptive thinking	Output tokens	Q5h delta
4.7 with adaptive (earlier)	Enabled	152	+37%
4.7 without adaptive (test)	Disabled	17	0%

Single data point, tiny call, cold start (no cache_read). But the contrast is striking — zero Q5h impact with adaptive thinking disabled vs massive impact with it enabled.

The env var is confirmed present in CC v2.1.111 source. Planning a longer test session tonight to validate with sustained multi-turn work.

If you want to test on your end:

export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1

Add to your wrapper or shell profile, run a normal workload on 4.7, and compare Q5h burn rate.

Credit: @X-15 for the suggestion.

Caveat: disabling adaptive thinking may affect output quality. 4.7 was designed around adaptive thinking — turning it off may produce 4.6-equivalent or degraded reasoning.

[cnighswonger]

Update: Primary source confirms three compounding cost increases in 4.7

From Anthropic's own documentation (What's New in Claude Opus 4.7):

1. Tokenizer inflation (documented: up to 35%)

"This new tokenizer may use roughly 1x to 1.35x as many tokens when processing text compared to previous models (up to ~35% more, varying by content)"

2. Adaptive thinking overhead (undocumented cost)

"Extended thinking budgets are removed in Claude Opus 4.7. Setting thinking: {type: 'enabled', budget_tokens: N} will return a 400 error. Adaptive thinking is the only thinking-on mode."

Critically:

"Adaptive thinking is off by default on Claude Opus 4.7. Requests with no thinking field run without thinking."

Yet Claude Code enables it — and the thinking tokens are invisible:

"thinking blocks still appear in the response stream, but their thinking field will be empty unless the caller explicitly opts in."

3. High-res images (if applicable)

"High-res images use more tokens. If the additional image fidelity is unnecessary, downsample images before sending."

The math

Factor	Cost increase	Source
Tokenizer	up to 35%	Documented
Adaptive thinking	~105% (estimated from Q5h gap)	Measured, not documented
Total observed	~140% (2.4x)	Our metered data

Anthropic documents the 35% tokenizer change. They do not document the adaptive thinking cost against quota. Our data shows the total increase is 2.4x — the tokenizer accounts for roughly a quarter of it.

The transparency gap

Anthropic's own docs say: "Keep in mind that these controls may trade off model intelligence." So disabling adaptive thinking (the CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 workaround) will reduce cost but may degrade quality. Users are being asked to make this tradeoff blind — they can't see how many thinking tokens are being consumed, can't control the budget, and can't verify the cost.

Feature request for thinking_tokens in usage response: anthropics/claude-code#49320

---

Source: platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7

[cnighswonger]

Warning: v2.1.111 defaults to Opus 4.7 silently

Just confirmed: after upgrading CC to v2.1.111, claude --resume starts on Opus 4.7 by default. No prompt, no notification. Users upgrading CC will silently switch to 4.7 and its 2.4x Q5h burn rate without realizing it.

Use /model claude-opus-4-6 to switch back. This costs one additional cold start but avoids the elevated burn rate until the adaptive thinking cost is understood and controllable.

Most users won't notice the switch — they'll just see faster quota drain and blame the same cache issues this interceptor was built to fix.

[cnighswonger]

Data: model switch cost — double cold start penalty

Sim Agent resumed on v2.1.111 which defaulted to 4.7. We switched back to 4.6 via /model. The cost:

Event	Time	Model	Cache creation	Q5h delta
Resume (cold start)	18:19	opus-4-7	121,979	~21%*
/model switch (cold start)	18:22	opus-4-6	92,811	21%
Normal turn	18:23	opus-4-6	6,675	2%
Settled	18:23+	opus-4-6	<1,000	0%

*The 4.7 call reported 0% delta but Q5h jumped from 61% to 82% between the 4.7 and 4.6 calls — the delta was likely consumed by 4.7 but not reported until the next response.

Total cost of the silent 4.7 default: ~23% Q5h for two cold starts (one on 4.7 resume, one on /model switch back to 4.6). That's nearly a quarter of a Q5h window lost to an unannounced model default change.

After settling on 4.6, the burn rate returned to normal — mostly 0% delta per turn with occasional 1% on heavier calls. The 4.6 baseline is confirmed stable.

Takeaway for users upgrading CC: If you don't want 4.7, switch models BEFORE your first real turn. The longer you work on 4.7 before noticing, the more Q5h you burn at 2.4x rate. And if you switch mid-session, you pay one additional cold start.

[fgrosswig]

Cross-reference: 4.6 baseline data from our gateway

We can provide the 4.6 baseline comparison you're asking for. Our gateway has been capturing per-request token data for 11 days on Max 5x.

4.6 Burn Rate (our data)

Metric	Opus 4.6 (our gateway)	Opus 4.7 (your meter)
Q5h burn rate	~9%/hour	~24%/hour
Q5h per API call	~0.07%	~0.21%
Cache read/request	400-800K	84K (5.95M/71)
Multiplier vs 4.6	1x	2.6x

The 2.6x multiplier is consistent with your 2.4x observation when disabling adaptive thinking brought it to 0%.

What we see on 4.6 at similar session lengths

Our 18-hour session today (still running):

• 71 calls in 38 minutes would burn ~5-6% Q5 on our 4.6 setup
• You saw 15% for the same call count on 4.7
• That's the ~2.6x gap

The adaptive thinking hypothesis is strong

If CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 drops the delta to 0%, then the entire overhead is invisible thinking tokens. This maps to what Anthropic documented: manual budget_tokens is deprecated on 4.7, only adaptive is supported. The user has no visibility or control over how many thinking tokens are consumed.

This connects to our live findings today:

1. Our Efficiency Chart shows 0.09% output efficiency on 4.6 — meaning 99.91% of tokens are overhead. If 4.7 adds 2.4x more invisible thinking on top, the actual efficiency drops even further
2. The VCache Quota Tax we documented (99.4% cache overhead) would compound with adaptive thinking overhead — both are invisible, both charge against Q5

Recommendation for your longer test

When you run the sustained session tonight, it would be valuable to capture:

• Q5 delta per call WITH adaptive thinking
• Q5 delta per call WITHOUT (env var disabled)
• Whether the Haiku burst pattern we documented changes on 4.7 (do the server-side cache flushes still happen, or does adaptive thinking change the caching behavior?)

We can't test 4.7 yet (still on 2.1.96), but we'll monitor our gateway for when it appears in our traffic.

[cnighswonger]

Thanks for the cross-validation — 2.6x from your gateway data vs our 2.4x is strong convergence from independent measurements.

For tonight's sustained test, we'll capture:

1. Q5h delta per call WITH adaptive thinking (4.7 default)
2. Q5h delta per call WITHOUT (CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1)
3. Haiku burst monitoring (our meter captures requested vs served model per call since v0.3.0)

Your efficiency point is sharp — if 4.6 is already 99.91% overhead and 4.7 adds 2.4x invisible thinking on top, the actual useful-output percentage becomes vanishingly small. That's the flywheel spinning faster with more friction and less useful work delivered.

Will report results here tomorrow.

[fgrosswig]

A/B Test: 4.6 vs 4.7 simultaneous on same Max 5x account — 12.5x burn rate

We just ran both models through our gateway at the same time. Windows on 4.6 (CC 2.1.96), Linux on 4.7 (CC 2.1.111). Same account, same 5h window, within the same minute.

Raw gateway data

20:52:06  q5=79%  opus-4-6  cr=821K  (Windows)
20:53:39  q5=79%  opus-4-7  cr=0     (Linux, 1st call)
20:54:23  q5=84%  opus-4-7  cr=301K  (Linux, 2nd call) ← 5% Q5 jump
20:54:33  q5=84%  opus-4-7  cr=0     (Linux, 3rd call)
20:55:06  q5=84%  opus-4-7  cr=301K  (Linux, 4th call)
20:55:34  q5=84%  opus-4-6  cr=823K  (Windows, back)

Comparison

Metric	Opus 4.6	Opus 4.7
Q5 per call	~0.1%	~1.25%
Multiplier	1x	12.5x
Cache read	821K	301K
Visible overhead	High CR	Low CR

4 calls on 4.7 consumed 5% of the 5h quota. Same call count on 4.6 would consume ~0.4%.

The invisible gap

4.7 shows less cache_read (301K vs 821K) but burns more quota (12.5x). The gap is invisible adaptive thinking tokens — not in the response usage block, not in cache_read, but charged against Q5.

Difference from your 2.4x measurement

Your 38-minute session showed 2.4-2.6x. Our first 4 calls show 12.5x. Possible explanations:

• Cold start overhead: the first calls on a fresh 4.7 session may have disproportionate thinking warmup
• Amortization: over 71 calls the per-call overhead normalizes; at 4 calls it's front-loaded
• Workload difference: your PBX analysis vs our session may trigger different adaptive thinking levels

Your longer test tonight should clarify if the rate normalizes over time or stays elevated.

The CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 test is critical

If disabling adaptive thinking brings our 12.5x down to ~1x, then we have definitive proof that the entire overhead is invisible thinking tokens. We'll test this on our Linux host next.

At 12.5x, a Max 5x user who normally exhausts the 5h window in ~5 hours would hit it in 24 minutes on 4.7. That makes the env var workaround not optional — it's essential.

[cnighswonger]

Warning: settings.json model pin does NOT prevent 4.7 default

Our global ~/.claude/settings.json has "model": "claude-opus-4-6" set explicitly. Despite this, resuming a session on CC v2.1.111 defaulted to Opus 4.7.

// ~/.claude/settings.json
{
  "model": "claude-opus-4-6",
  ...
}

Sim Agent resumed on 4.7 anyway. The settings.json model preference is ignored by v2.1.111.

This means users cannot protect themselves via configuration — the only defense is manually running /model claude-opus-4-6 on every resume. There is no config-based workaround to avoid the 2.4x burn rate.

This should be filed as a bug — if settings.json has an explicit model preference, the session should respect it.

[seanGSISG]

CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1

Can this be added to ~/.claude/settings.json ENV vars?

[fgrosswig]

Nope 👎 breaks it

[cnighswonger]

v2.0.0 stable released

Seven new cache-stability fixes from @deafsquad merged today, bringing the interceptor to 15 total fixes. The combined stack reduces first-request cache creation by up to 99.8% on affected sessions (940K → 1.7K tokens measured).

New in v2.0.0:

• smoosh_split — universal un-smoosh of tool_result content (Add smoosh_split — universal un-smoosh complementing smoosh_normalize (#49585) #26)
• session_start_normalize — resume→startup rewrite (Add session_start_normalize — fix SessionStart:resume byte drift on --continue #27)
• continue_trailer_strip — remove --continue nudge block (Add continue_trailer_strip — remove the --continue resume-nudge text block #28)
• deferred_tools_restore — MCP reconnect race fix (Add deferred_tools_restore — survive MCP reconnect race on --continue #29)
• reminder_strip — drop bookkeeping system-reminders (Add reminder_strip — remove bookkeeping system-reminder blocks entirely #30)
• cache_control_normalize — pin marker at canonical position (Add cache_control_normalize — pin marker at canonical position to stop per-turn drift #31)
• tool_use_input_normalize — new miss class: tool_use.input field-set drift (Add tool_use_input_normalize — prevent tool_use.input field-set drift between turns #32)

146 tests, all passing. Compatible with CC v2.1.112 and Opus 4.7.

npm install claude-code-cache-fix@latest or npm update claude-code-cache-fix.

The 4.7 burn rate advisory from this thread is included in the release notes. Cache optimization does not eliminate the adaptive thinking overhead, but it ensures you are not paying for cache rebuilds on top of it.