Jean-Pierre

Appearance

View Markdown

Thinking blocks are repaired after a 400 JP could have predicted ​

  • Status: Todo
  • Kind: Feature
  • Authors: jp
  • Date: 2026-09-22
  • Label: domain=llm
  • Label: llm-provider=anthropic
  • Label: package=jp_llm
  • Label: type=enhancement

Anthropic validates replayed thinking blocks against the request that would have produced them. A request whose system, tools, or earlier messages changed since the blocks were generated is rejected with thinking blocks ... cannot be modified, and a block whose signature does not validate for the model being called is rejected with Invalid 'signature' in 'thinking' block. For accounts created on or after 2026-08-31 the first of these is the default rather than an opt-in.

JP handles both, in anthropic.rs: classify_thinking_rejection names the rejection, build_thinking_patches rewrites the whole assistant turn holding the offending block as <think> text, and the stream yields FinishReason::Retry so turn_loop reissues the request. It is tested and it converges.

It is also entirely reactive. Every repair costs a round trip that ends in a 400, and it pays for that round trip by discarding that turn's native reasoning — the API keeps the text, but the model no longer sees the blocks as its own. On a turn-scoped rejection that is one round and one turn's reasoning. On a signature rejection spanning a long conversation it is one round per turn that carries thinking.

What JP already knows ​

The conversation's config is an ordered series of deltas in the stream (jp_conversation::stream::config_delta), so the model, the tools, and the system prompt in force at every point are recoverable by folding forward. When JP is about to issue a request it can compare the config that produced the stored thinking blocks against the config it is about to send, and strip the provider metadata itself when the two disagree in a way the API rejects. That turns a failed request plus a repair into no failed request at all, and lets JP say what it dropped and why instead of logging a warning about someone else's 400.

Why this surfaces now ​

Two of JP's own features are the trigger. A --cfg delta applied mid-conversation changes system or tools between one turn and the next, which is the exact edit the append-only requirement forbids. Changing assistant.model.id mid-conversation moves the conversation to a model that may not read the stored blocks at all.

Claude Opus 5.5 makes both more likely: thinking cannot be turned off, so every assistant turn carries blocks, and its blocks are read only by Opus 5.5, Fable 5.1, and Mythos 5.1.

To settle first ​

Whether a cross-model replay is a 400 or a silent drop. The migration guide's wording — "runs those turns without them" — reads like the blocks are ignored rather than rejected, which would make the model-switch half of this a silent context loss rather than a failed request. If so it still deserves a notice, but it is a different fix from the tools-and-system half, and possibly a different ticket.

Severity ​

Low and self-correcting today. The repair works, and the user sees a slower turn rather than a broken one. It gets worse the longer a conversation runs and the more often its config changes, and it is silent about the reasoning it discards to get unstuck.