Opus 5 at xhigh: thinking on ~100% of requests and 2-7x output tokens per request since ~02:30 UTC 11 Sep, with no client or settings change

Same behaviour measured from a different workload — and the client binary is the variable.

Setup: Linux, Claude Code CLI in -p mode (--input-format stream-json --output-format stream-json, --setting-sources '', --strict-mcp-config, --tools ''), subscription login (OAuth), claude-opus-5. Every number below comes from the CLI's own transcripts (~/.claude/projects/**/*.jsonl, message.usage.output_tokens_details.thinking_tokens) — not estimates.

Timeline (client held constant). My last "normal" Opus 5 call on 2.1.263 was 2026-09-10 02:07 UTC (thinking 40 tokens on a 43k-token input). The first "exploded" call was 2026-09-11 00:25 UTC, same 2.1.263 binary, same app, same prompt template (no code change on my side since 08-28): 25–35k thinking tokens per request. That is ~2 h before the 02:30 UTC onset you report — consistent with a staged rollout.

Same prompt, same effort, two binaries, run in parallel at the same minute (2026-09-11 15:21 UTC). 165 KB input (~76k tokens), 17k-char system prompt, --effort medium, CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000:

| binary | thinking_tokens | output_tokens | text | wall time |
|---|---|---|---|---|
| 2.1.237 | 0 | 25,148 | 58.6 KB | 5.4 min |
| 2.1.268 | 16,128 | 48,586 | 74.4 KB | 10.3 min |

In production the same request on 2.1.268 had produced 50,788 thinking tokens (15.8 min). Small-prompt A/B, --effort high, 3 runs each: 2.1.237 → 966 / 964 / 781 thinking tokens (57–64 s); 2.1.263 → 12,455 / 8,746 / 18,057 (191–324 s).

Real workloads before/after (same pipeline, similar input sizes, --effort high unless noted):

| workload | date | client | thinking per call | wall time |
|---|---|---|---|---|
| 3-call transcript analysis chain (37k/58k/76k input tokens) | 09-02 | 2.1.237 | 0 / 0 / 1,122 | 14.5 min total |
| same chain, 3 calls (33k/51k/76k), medium | 09-11 | 2.1.268 | 6,093 / 33,909 / 50,788 | 33 min total |
| JSON extraction task, ~60 calls 08-10 → 09-09 | — | 2.1.237 / 2.1.263 | ≈ 0 (median 0) | — |
| same task, 15 calls | 09-10/11 | 2.1.263 / 2.1.268 | 25k–53k each | — |
| sentence review + double-check (65k / 75k input) | 09-11 03:16 UTC | 2.1.268 | 26,553 / 18,576 | 13.6 min |
| same review + double-check, same document | 09-11 16:27 UTC | 2.1.237 | 11,085 / 7,753 | 6.6 min |

Across ~60 calls of the JSON task between 08-10 and 09-09 the exact counter was 0 on nearly every call, even with 150k-token inputs. Since 09-10 it is 25k–53k on every call.

What is (and is not) different on the wire. I put a logging proxy on ANTHROPIC_BASE_URL and captured the /v1/messages bodies of both binaries. Identical: model, thinking: {"type":"adaptive"}, output_config: {"effort": ...}, max_tokens: 64000, the three system blocks. Different: 2.1.26x adds a second message with role: "system" (the "# Environment" block: cwd, platform, model name, date) and moves cache_control onto it, and sends one extra beta (mid-conversation-tool-changes-2026-07-01). So the parameters that are supposed to govern thinking are the same; the request shape (and the cc_version in the billing header) is what distinguishes the client that gets heavy thinking from the one that doesn't.

Practical consequence. Output tokens per request are 2–5× for the same work; my longest analysis went from 14.5 to 33 min. Hitting the CLI's default 64k per-turn cap also became routine (the CLI then auto-continues and the result event carries only the last turn's text — separate issue). Workaround that restores the previous behaviour today: run the pinned 2.1.237 binary (still authenticates fine).

I'm seeing the same thing on a different account. On my side the Claude Code version did not change: it switched on the same binary, between 06:00 and 07:00 UTC on 2026-09-10.

Setup: VS Code extension on Windows, claude-opus-5, effort xhigh, adaptive thinking. All numbers come from Claude Code's own transcripts (~/.claude/projects/**/*.jsonl): main-thread requests only (subagents excluded), de-duplicated by message.id, using usage.output_tokens_details.thinking_tokens.

Same 2.1.263 binary, before and after

| Period (UTC) | Claude Code | Requests | Median thinking tokens | Zero-thinking share | p90 |
|---|---|---|---|---|---|
| 09-07 03:21 – 09-10 06:29 | 2.1.263 | 9,630 | 182 | 28% | 1,196 |
| 09-10 06:30 – 09-10 19:09 | 2.1.263 | 516 | 1,336 | 4% | 8,159 |
| 09-12 – 09-14 | 2.1.268 | 2,071 | 1,598 | 3% | 7,659 |
| 09-14 | 2.1.270 | 1,151 | 1,600 | 4% | 7,079 |

Earlier versions 2.1.251–2.1.259 (09-01 to 09-07) had medians of 85–170, the same level as before the switch.

Sep 10, by hour (UTC)

| Hour | Requests | Median thinking tokens | Zero-thinking share |
|---|---|---|---|
| 04:00 | 80 | 68 | 41% |
| 05:00 | 281 | 102 | 42% |
| 06:00 | 190 | 216 | 32% |
| 07:00 | 40 | 2,068 | 0% |
| 08:00 | 65 | 1,395 | 3% |
| 09:00 | 88 | 1,360 | 1% |

It changed mid-session. Four sessions had at least 5 requests on each side of the switch, all on 2.1.263 throughout. Their median thinking tokens, 04:30–06:29 UTC vs 06:30–09:29 UTC: 255 → 1,056, 0 → 1,795, 0 → 768, 320 → 876.

The onset differs by account. Mine: 09-10 06:00–07:00 UTC. The comment above: between 09-10 02:07 and 09-11 00:25 UTC. The original report: 09-11 01:30–03:30 UTC. Since it switched at a point in time without a client change, it looks like a staged server-side rollout, though I have no way to confirm that from the client side.

The #93683 reminder alone doesn't explain it. The batching_reminder_sent injection from #93683 also jumped at the same moment on my side (11 → 678 per 1,000 main-thread requests). But thinking also rose on the first request of a conversation, before any tool result or reminder exists: the zero-thinking share went from 96% (n=100) to 0% (n=26), and the median from 0 to 946. Since it rose even where no reminder was present, the reminder doesn't seem to be the whole cause.

I'd also like an answer to the question in the original report: was there a server-side change around this time?

Adding data from another account: macOS, Claude desktop app (Code tab), claude-opus-5, 1M context, mostly effort max. Same pattern, plus one more point: the extra thinking stays in context, so in long multi-step sessions it compounds.

Onset on our account: about 00:00–02:00 UTC on 12 Sep, roughly 22 hours after we were already on 2.1.266. Main-thread requests from our transcripts, usage.output_tokens_details.thinking_tokens, de-duplicated by message.id:

| UTC | Claude Code | effort | requests | median thinking / request |
|---|---|---|---|---|
| 8–9 Sep | 2.1.260 | max, xhigh | ~5,400 | 124–313 (6-hour buckets) |
| 11 Sep 10:00 | 2.1.266 | max | 18 | 458 |
| 11 Sep 21:00 | 2.1.266 | max | 11 | 568 |
| 12 Sep 00:00 | 2.1.266 | max | 4 | 623 |
| 12 Sep 01:00 | 2.1.266 | max | 7 | 8,109 |

The 00:00 and 01:00 rows are the same session on the same binary. Hourly counts are small, but with the timelines above this looks like the same account-scoped switch, not the client update.

Effect on long multi-step sessions. Each of our sessions runs a scripted start-up before any work; a start-up is counted up to its first report.

• Median context at the end of start-up: 202k (66 start-ups, 1–11 Sep) → 422k (9 start-ups, 12–13 Sep).
• Thinking per request at max: 470 → 5,080 during start-up, and 279 → 2,185 in ordinary work (11,739 requests before vs 809 after).
• Each request's context grows by the previous request's full output, thinking included, so start-up thinking is carried for the rest of the session. With 1M context, sessions now use roughly a quarter to a third of it before doing any work.

Still present on 2.1.270 (14 Sep). Five start-ups at max used 69–83k thinking tokens each. One comparison on identical instructions: max used 74.3k over 12 requests (6.2k each), and xhigh used 45.3k over 16 (2.8k each). Lower effort helps but does not restore the earlier level; start-ups at max used about 26k before the change.

One addition to the asks above: a supported way, for long agentic sessions, to keep earlier thinking out of context or to cap thinking per request at a given effort.