Fix Sonnet 5.5 API 400 errors after upgrading

Changing only the model ID can break a working Sonnet 5 integration. Sonnet 5.5 changes accepted thinking settings, forced tool use, thinking-history handling and some tool compatibility. If your client starts returning HTTP 400 after the upgrade, inspect the error body and the outgoing request before changing authentication or retrying the same payload.

This guide follows Anthropic’s Sonnet 5.5 migration guide and change documentation, checked September 29, 2026. The examples are documentation-based request shapes, not a claim that Ofox has reproduced every error against a live API. A 401, 429 or provider-specific 404 needs a different investigation.

Identify the incompatible field

Do not apply the computer-use row to all providers. The same official page says Amazon Bedrock accepts the older computer_20251124 tool. Platform scope is part of the fix.

Replace disabled thinking carefully

For a minimal text request with no tools, this is a documentation-based body for POST /v1/messages on the native Claude API:

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "thinking": {"type": "between_tools"},
  "output_config": {"effort": "high"},
  "messages": [{"role": "user", "content": "Return a one-sentence summary of this task: verify a CSV total."}]
}

The body alone is not a complete HTTP client. Supply the authentication and API-version headers required by the Messages API. Keep credentials in your own environment, outside copied examples and logs.

between_tools disables up-front thinking, but it is not a promise that every tool workflow has no thinking blocks. Progress notes between tools can still use that block type. It accepts low, medium and high effort, not xhigh or max, and does not accept extra fields such as display or budget_tokens. To use xhigh or max, use adaptive thinking. Do not combine incompatible settings and expect retries to resolve the validation error.

Replace forced tool calls without losing validation

Switching tool_choice to auto changes behavior: the model can choose whether to call a tool. Adding strict: true to a supported tool definition validates the shape of a tool input; it does not force the model to select that tool. Your application must still check whether the expected call happened. These schema options are platform-dependent: the migration guide says structured outputs, including strict tool use, are unavailable for Sonnet 5.5 on Amazon Bedrock.

For an extraction service, consider whether you need a tool call at all. Structured output can be the appropriate design when the result is data rather than an action. Test valid output, omitted required data, refusal and an unexpected natural-language response. Do not declare the migration complete merely because the request stops returning 400.

Preserve conversation history

Sonnet 5.5 binds its thinking blocks to the model and conversation. Editing an earlier system prompt, tool definition or message while replaying a later block can trigger a binding error. The official default enforcement applies to accounts created on or after August 31, 2026, 00:00 UTC on specified platforms; older accounts and explicit opt-in settings require separate checking.

The simplest design is append-only history. Keep returned blocks unchanged and use the documented mechanisms for mid-conversation changes. If you deliberately edit history, follow the migration guide’s handling of affected blocks and beta controls. Do not strip every thinking block from every request as a universal fix: that changes the conversation and can discard useful context.

Model switching has its own rules. A block that cannot be read by the target model can be dropped, which is different from an edited-prefix binding failure. Log the actual error or transformation metadata instead of assigning every problem the label “invalid signature.” For older cases, see the thinking signature troubleshooting guide.

Check successful responses too

Some regressions do not return an HTTP error. Longer progress notes between tool calls can arrive in thinking blocks whose text is omitted under the default adaptive display behavior. A UI that renders only text blocks can look silent while the request is otherwise valid. Check the documented thinking.display behavior for adaptive thinking or the supported between_tools mode.

Also distinguish a refusal from a transport failure. The documentation describes HTTP 200 with stop_reason: refusal and additional details. A successful HTTP status is not proof that the requested task completed. Handle the result explicitly rather than repeatedly submitting the same declined task.

Validate before switching production traffic

Keep a small fixture set: plain text, a tool call, a multi-turn conversation, edited history, streaming updates and a refusal-handling path. Verify the request schema, response parser, tool-result pairing and user-visible output. Save client version and exact model ID with each result. Keep a rollback configuration for the older integration while you investigate failures.

Use the upgrade decision guide for the broader rollout checklist and the Claude Code setup guide for CLI selection. This article addresses native API changes; a third-party gateway may add its own translation layer and errors.