Follow Discord
Sweep 25 Sep 2026 · 19:33Z Build v2.1.283 504 read Stable v2.1.274 Latest v2.1.283 Next v2.1.283 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.282 ·

Requests for 'highlights' thinking display now fail when the session cannot use it

set_max_thinking_tokens with thinking_display highlights now returns an error and changes nothing when highlights is unavailable, instead of silently falling back

Group of 2 You'll notice Improvements
JSON All of v2.1.282
You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
SDKArea: what it touches
ImprovementsKind: in v2.1.282,
ImprovementsSection of the release

What

Programs that drive Claude Code through the SDK or Remote Control can send a set_max_thinking_tokens request to set Claude's thinking budget and how its thinking is shown (thinking_display). A request for "highlights" is now checked before anything is applied. If highlights is not available, the request fails with the error "thinking_display "highlights" is not available in this session, so neither the budget nor the display was changed", and neither setting changes. It fails:

  • after the API has already refused highlights;
  • on Bedrock, Vertex or another provider without Anthropic's first-party beta features;
  • when experimental betas are off, through CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS or organisation policy;
  • on a Claude 3 model, except on Microsoft Foundry.

The same check runs in the Remote Control handler (onSetMaxThinkingTokens) and in the interactive session's thinking-budget handler. Before, the only check was that the budget was a whole number or null, and for these clients the request succeeded and the display fell back to "omitted".

Why

Programs asking for highlights where it cannot work now get a clear error instead of a partial change where the budget moved but the display did not.

How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtOnly the request's description was checked, not the code that enforces it.

See this entry in the whole of v2.1.282 →

Feedback