You switch the Claude model used in an internal system to a newer one, and requests that used to go through start coming back with 400 errors. Between September and October 2026, Claude Sonnet 5.5 (September 28) and Claude Haiku 5.5 (October 7) were released, and it was announced that Claude Sonnet 4.5 is scheduled to be retired from the Claude API on November 30, 2026. Opportunities to rewrite model IDs keep coming.
The Haiku 5.5 migration guide states that budget_tokens, which specifies the amount of thinking, and sampling settings such as temperature (other than the fixed allowed values) result in a 400 error. You can find these differences by reading each model's migration guide, but if you use many features, some may slip through.
According to the October 1, 5, and 6 release notes, three fields that return a model's support status were added to Claude's Models API (GET /v1/models). This article lays out how to compare two models before switching, based on the official documentation and on results the editorial team checked with the TypeScript SDK in its test environment.
The three new fields
Summarizing the release notes and the documentation ("Using the Models API" in the Models overview), the fields are as follows.
line(October 1): The model family. Claude Opus 4.5 and 4.6 are bothopus. Models that do not belong to a family arenull. The documentation says to read this field rather than inferring the family from the model ID string. More kinds of values may be added in the futurecapabilities.thinking.types.disabled(October 5): Whetherthinking: {type: "disabled"}(the setting that turns thinking off) is accepted. Iffalse, it results in a 400 error. For models that do not support thinking, it istruecapabilities.server_tools(October 6): Whether the model supports the web search (web_search) and code execution (code_execution) tools
The Models API already returned the input limit (max_input_tokens), the output limit (max_tokens), and the capabilities object (batches, structured outputs, image and PDF input, effort levels, thinking types, and more). With these three additions, even more of the items that can cause 400 errors when switching models can now be checked through the API.
Be careful about what "supported" means

The documentation cautions that, for several fields, true does not guarantee success.
server_tools: Covers only web search and code execution, and does not include other server tools such as web fetch.supportedistrueif the model supports at least one version of that tool, so it does not necessarily support every version. Even if supported, requests can fail because of organization settings, for example when an administrator has turned web search offthinking.types.disabled: Even whentrue, requests may be rejected if combined with an effort level that is not allowed when thinking is turned off- Top-level
code_execution: This is separate fromserver_tools.code_execution. It indicates whether other tools in the request can be called from within the code execution tool (programmatic tool calling). In the documentation's example, Claude Haiku 4.5 hasserver_tools.code_executionset totrueand the top-levelcode_executionset tofalse
In other words, the Models API is a check for "finding combinations that clearly won't work in advance," not a guarantee that a request will succeed. In the end, you confirm by sending real requests in a test environment.
A script to compare models before switching
The editorial team wrote a TypeScript script that retrieves capabilities for two models and displays only the differences.
import Anthropic from '@anthropic-ai/sdk';
const client = new Anthropic();
const [fromId, toId] = process.argv.slice(2);
const from = await client.models.retrieve(fromId);
const to = await client.models.retrieve(toId);
const checks: Array<[string, (m: Anthropic.ModelInfo) => unknown]> = [
['line', (m) => m.line],
['max_input_tokens', (m) => m.max_input_tokens],
['max_tokens', (m) => m.max_tokens],
['thinking: enabled (budget_tokens)', (m) => m.capabilities?.thinking.types.enabled.supported],
['thinking: disabled', (m) => m.capabilities?.thinking.types.disabled.supported],
['structured_outputs', (m) => m.capabilities?.structured_outputs.supported],
['batch', (m) => m.capabilities?.batch.supported],
['server_tools.web_search', (m) => m.capabilities?.server_tools.web_search.supported],
['server_tools.code_execution', (m) => m.capabilities?.server_tools.code_execution.supported],
['effort: low', (m) => m.capabilities?.effort.low.supported],
];
for (const [name, read] of checks) {
const a = read(from);
const b = read(to);
if (a !== b) console.log(`${name}: ${fromId}=${a} -> ${toId}=${b}`);
}
To use it, just pass the current model ID and the target model ID. Among the items displayed, check whether your current code uses any that changed from true to false. For example, if thinking: enabled changes to false, requests that specify budget_tokens need to be rewritten to specify effort instead.
What we confirmed in the test environment
In the editorial team's test environment (Node.js v22.22.0, @anthropic-ai/sdk 0.135.0, TypeScript 5.9.3), we confirmed the following.
- The script above passes type checking with the
strictsetting line,server_tools, andthinking.types.disabledwere added to the SDK's type definitions starting with 0.132.0 (published on npm on October 7, 2026), and are absent through 0.131.0. With an older SDK, they cannot be read at the type level- The type definitions in 0.135.0 (released October 15) also include
thinking.types.between_tools. On the other hand,server_tools.web_fetchis absent, which matches the documentation's explanation above - We ran it against a local stub server (one that returns responses in the shape of the Models API, with fictitious values for testing) and confirmed that it retrieves two models and displays only the differences
We did not send queries to the actual Claude API, so we have not confirmed the values each model actually returns.
Building it into your operations
As a suggestion from the editorial team, building Models API checks into the following situations can reduce oversights when switching.
- Checks on PRs that change model IDs: Run the script above in CI and post the differences as a PR comment
- Branching by family: Rewrite code that decides based on the model ID string, such as "if it's an Opus model...", so that it reads
lineinstead - Toggling features: Disable features that use web search or code execution for models where
server_toolsisfalse(but since requests can also fail due to organization settings, keep the error handling in place)
Planned model retirements are announced on the Model deprecations page, not in the Models API. Use both when planning a switch.
For points to watch in recent model switches, see Before switching to Claude Sonnet 5.5; for the cost perspective, see A cheaper new model won't automatically lower your bill; and for designs that use multiple models, see our article on multi-model routing.
Scope of verification
On October 16, 2026, we directly retrieved and checked the Claude Platform release notes (September 28 and 30, and October 1, 5, 6, and 7, 2026), "Using the Models API" in the Models overview, and List Models in the API reference (document research). We also compared the type definitions of
@anthropic-ai/sdk0.128.0 through 0.135.0 published on npm, and with 0.135.0 ran type checking on the script above and executed it against a local stub (hands-on testing; no requests were sent to the actual Claude API). We have not confirmed the values each model actually returns, or how the Models API behaves through other routes such as Amazon Bedrock and Google Cloud.
For model switches or maintenance planning for systems that incorporate the Claude API, please contact us through Development, AI, and automation inquiries.









