Under the hoodTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
Thinking ModeArea: what it touches
Internal ChangesKind: in v2.1.280,
Internal ChangesSection of the release
What
Telemetry/event schemas gained thinkingMode and thinkingDisplay string fields, each validated against a fixed set of allowed values and defaulting to an empty string.
The tracker that compares successive API request configurations now also flags thinkingModeChanged and thinkingDisplayChanged, alongside existing fields like effortChanged and extraBodyChanged.
The request-cache invalidation-reason table gained thinking_mode_changed and thinking_display_changed entries, explaining why a cached prompt/request was dropped and re-sent.
The turn-configuration-diff logger now reports "thinking mode changed" / "thinking display changed" (with previous/new values) alongside other turn changes like effort or model.
The general status-diff helper used to compare snapshots also flags these two changes, but only once a non-empty thinking mode was already set on both sides.
Why
This lets Claude Code correctly explain and log why a request was rebuilt or a cached prompt was invalidated when you change thinking mode or thinking display, instead of leaving those changes unaccounted for in diagnostics and telemetry.
