Claude API 2026-10-21 drops temperature, top_p and top_k

What breaks, and when

Claude API version 2026-10-21 removes temperature, top_p and top_k. A request that sends any of them gets a 400 error, even at the default value. That covers Messages requests, token counting and every request in a Message Batch created with that version (Claude migration guide).

You can hit the same error without changing API versions. On earlier versions, Claude 4.7 and later models and Claude Mythos Preview return it when any of the three is set to a non-default value (Claude deprecations page).

In practice you'll see it right after one of two changes: an SDK upgrade to a new major version, or a newer model ID. Claude Sonnet 4.5 retires on November 30, 2026, and its replacement, claude-sonnet-5-5, is a Claude 4.7 or later model, so moving off it runs into this even on 2023-06-01.

How your API version is set

Every request carries an anthropic-version header (Claude API versions). If you call the API over HTTP, you set it yourself.

The SDKs set it for you: your requests use the API version that was current when your SDK's major version came out. Earlier majors send 2023-06-01. These are the first versions that send 2026-10-21 (Claude migration guide):

The new majors also drop the three parameters from their types, so in TypeScript, Go, Java or C# the compiler flags the ones you pass directly. Values that arrive at runtime, from a config file or a dict you build, won't show up that way. In the C# SDK, the IChatClient adapters now ignore ChatOptions.Temperature, ChatOptions.TopK and ChatOptions.TopP instead of failing (Claude migration guide).

On Amazon Bedrock and Google Cloud

• On Amazon Bedrock, 2026-10-21 works only with Claude 4.7 and later models (Claude API versions). The latest SDKs send it through Bedrock too, so if you still call an older model there, such as Claude Sonnet 4.5, keep your SDK on its current major and pin it. The boto3 route sets anthropic_version in the request body, such as bedrock-2023-05-31, and isn't affected (Claude on Bedrock page).
• On Claude Models on Google Cloud (Google managed), a raw request passes anthropic_version in the body: vertex-2023-10-16 or 2026-10-21 (Claude docs).

Where the parameters hide

Searching for the request call isn't enough. Check each of these:

• Direct SDK calls, such as temperature=0 in messages.create, and the same arguments on Message Batches and token counting.
• Shared request builders and default options merged into every call. One line there reaches every request.
• Framework wrappers. LangChain's ChatAnthropic has temperature, top_p and top_k fields (LangChain reference). Check where you construct the model, and any library that takes one temperature setting for several providers.
• Config files and environment variables, such as a temperature: 0.2 line in YAML or a LLM_TEMPERATURE variable you defined.
• Eval harnesses and test configs, especially ones that pin temperature: 0 for repeatable runs. Recorded request fixtures can carry the parameters too.

This finds most of them in a repository. Expect noise: you want the hits that end up in a Claude request.

git grep -n -i -w -E 'temperature|top_p|top_k|topp|topk'

git grep skips untracked files, so check .env files and your deployment's settings by hand.

How to fix it

The recommended replacement is to leave all three out and guide the model with prompting (Claude deprecations page). Without them, a request samples at the defaults, including a temperature of 1.0, the same as an older request that left them out (Claude migration guide).

1. Delete the three parameters from every Claude request, including defaults merged in from shared options.
2. Don't look for a substitute setting. The migration guide says no other setting replaces a lowered temperature.
3. If one request truly depends on a non-default value, and its model still accepts one, such as claude-sonnet-4-6, you can keep that request on 2023-06-01 for now (Claude migration guide). That buys time, not a fix: claude-sonnet-4-6 retires not sooner than February 17, 2027 (Claude deprecations page), and newer models reject the value on every version.

# Before: a 400 error on claude-sonnet-5-5
client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    temperature=0,
    messages=messages,
)

# After
client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    messages=messages,
)

If you used a low temperature for consistent output

First, temperature: 0 never guaranteed identical outputs, even on earlier models (Claude migration guide). The Claude docs point to these instead:

• Say exactly what you want. Be specific about the output format and constraints, and use numbered steps when the order matters (Claude prompting best practices).
• Add examples. The same page says a few well-made examples improve accuracy and consistency, and suggests 3 to 5, wrapped in <example> tags.
• Use structured outputs when the shape matters. output_config.format with a JSON schema, or strict: true on a tool, gives schema-compliant responses (Claude structured outputs). For classification, a tool with an enum field limits the answer to your labels (Claude docs).
• If the same input must always get the same answer, store the first response and reuse it for that input (our suggestion).

How to test the change

1. Test against 2026-10-21 before you release, as the upgrade steps say (Claude migration guide). Send one real request down each path: chat, tool loops, batches and token counting.
2. Add a test that fails if a Claude request sets any of the three, for example by checking the payload your request builder produces (our suggestion). It stops them coming back through a later config change.
3. Run your evals with the parameters removed, and compare output format, length and failure rate with your current results. If outputs vary more than you can accept, add examples or structured outputs before you ship.
4. After the release, watch your logs for 400 errors from the Claude API on each code path until every path has served real traffic.

Where Since.dev fits

Since.dev tracks every model's retirement on each platform that serves it, from the publishers' own pages, along with API changes like this one. The retirement calendar lists the Claude dates.

• Scan any public GitHub repository, no sign-in needed. For a repository you scan or connect, it finds the exact file and line a tracked change hits, with the days left and what to move to.
• A coding agent can ask through the MCP server: call check_code with a model ID, or whats_changed with model.
• On Team and up, it opens a fix pull request that swaps the model. The pull request opens ready for review, and nothing merges or deploys.

Questions

Does sending temperature: 1.0 still work?

On API version 2023-06-01, yes: 1.0 is the default, and only non-default values fail. On 2026-10-21, no. Any of the three parameters returns a 400 error, even at its default, so leave them out.

Can I keep using temperature by staying on API version 2023-06-01?

Only on models that still accept non-default values, such as claude-sonnet-4-6. Claude 4.7 and later models reject them on every API version, so staying on the old version helps only until you move to a newer model.

Is there a new parameter that replaces temperature?

No. The Claude migration guide for API version 2026-10-21 says no other setting replaces it. Use clear instructions, examples and structured outputs instead.

Which platforms support API version 2026-10-21?

The Claude API, Claude Platform on AWS, both Claude Models on Google Cloud offerings and Microsoft Foundry. On Amazon Bedrock it's available for Claude 4.7 and later models only (Claude API versions).