API discovery: Pydantic AI's public Anthropic model guide gives a Python agent a concrete handle on a subtle provider failure: a thinking block can be bound to the conversation prefix that produced it. If the next request changes that prefix, the provider can reject the replay with a 400. Pydantic AI exposes the relevant request surface through AnthropicModelSettings, including anthropic_thinking.block_binding.prefix_mismatch_behavior, and records a provider-reported drop in the response's provider_details.
This belongs in a compact API slot, not the lead, because it is a narrow integration contract rather than a public product shift. It is still useful for agent builders: a run that answers after an invalid reasoning block was dropped has crossed a continuity boundary, and the public API gives the operator a way to see it rather than mistake it for ordinary success.
Fix the prefix before you rescue the turn
The guide names two ordinary ways an otherwise careful agent can create the mismatch: a dynamic-instructions function returns different text on the next run, or a filtered toolset advertises a new tool mid-conversation. Those changes also spoil the prompt-cache prefix. That is why “retry on 400” is not the thesis here. A stable prefix saves the failed request, preserves the original reasoning context, and avoids the quiet cache cost that follows a shifting conversation shape.
When that stability is not immediately possible, Pydantic AI has two honest choices. Set prefix_mismatch_behavior to error to stop and investigate, or set it to drop_block to let the request continue without the stale thinking block. The latter is not a repair of the thought: the model no longer sees that prior turn's reasoning. The guide says the provider returns an input_transformations record, which Pydantic AI makes available in ModelResponse.provider_details and, with instrumentation, on the model-request trace.
The fresh `bce2e76` change tightens the operational story. The earlier public change, `e1357f6`, introduced the binding support and its focused tests. The current one uses the provider's returned transformation history so later requests in the affected conversation can send drop_block directly rather than incur the same rejected retry again. That makes an explicit alert more important, not less: the fallback can become the continuing state of that conversation.
Practical example: a release-review agent changes its rulebook
Build a disposable release-review rehearsal with entirely synthetic notes. Let the first turn produce a short risk list; before the second turn, have a dynamic instruction add a harmless formatting rule or let a filtered toolset reveal a mock “dependency glossary” tool. The useful test is not whether the second answer sounds plausible. It is whether the run reports thinking_dropped, which exact history item changed, and whether the operator chooses to stop on error, proceed on drop_block, or redesign the workflow so the prefix stays stable.
That distinction lets a team turn an opaque provider edge case into a reviewable operating signal: a response can be accepted as a new answer while still being marked as one that did not receive the preceding reasoning. For a release reviewer, that is a reason to regenerate or escalate, not a reason to silently attach the result to the same decision record.
Copy-paste agent instruction
Build a disposable two-turn Pydantic AI test for an Anthropic thinking-block-binding model. On the second turn, deliberately change one dynamic instruction or filtered toolset, retain the returned message history, and inspect every ModelResponse.provider_details input_transformations value for thinking_dropped. First configure anthropic_thinking.block_binding.prefix_mismatch_behavior as error; only then repeat with drop_block and record that the earlier reasoning was discarded. Keep the real workflow's prompt prefix stable, use synthetic data and an environment-variable API key, do not run production tasks, and report whether the configured client is direct Anthropic, a compatible proxy, Claude Platform on AWS, legacy Bedrock, Vertex, AWS-operated Bedrock Messages, or Foundry.Test caveat
This is source-backed preparation, not a live provider test. You need appropriate credentials or platform identity, model entitlement, billing and rate-limit headroom, and the Pydantic AI version that contains this behavior. The documented automatic recovery is available for the direct Anthropic API, compatible AsyncAnthropic proxies, Claude Platform on AWS, legacy Amazon Bedrock, and Google Vertex AI. It is not enabled for the AWS-operated Bedrock Messages client (AsyncAnthropicBedrockMantle) or Microsoft Foundry. An explicit setting may pass through elsewhere, but this report makes no claim that automatic recovery—or provider behavior—is universal. Use disposable credentials, synthetic content, and a visible receipt before trusting a continuation that dropped reasoning.