Claude API temperature now returns a 400: pin or migrate

Setting temperature to the default of 1.0 is now enough to fail a request. Under Anthropic's new API version 2026-10-21, the Claude API temperature parameter is gone: a request that sends temperature, top_p or top_k returns a 400 on every model, even at the parameter's default value. The new SDK majors send that version by default, so a routine dependency bump moves you onto it. Here's how to decide between pinning 2023-06-01 and migrating, and what each costs.

What changed on 21 October 2026, in one table

This is the first new API version since 2023-06-01. The version history lists only 2023-01-01, 2023-06-01 and now 2026-10-21. The release notes for October 21, 2026 announce the version and a new major of every SDK alongside it.

Item	Detail	Who it affects
Sampling parameters	temperature, top_p, top_k return 400 on every model	Messages, token counting, Message Batches
Document blocks	A document block directly in an assistant message returns 400	Apps that replay documents as assistant turns
Citations	A user text block with a non-empty citations array returns 400, including inside search_result	RAG pipelines that echo citations back
Admin API	roles becomes role_ids; API keys lose workspace_id for scope.workspace_id	Org tooling and audit scripts
SDK defaults	Python 2.0.0, TypeScript 1.0.0, C# 13.0.0, Go 2.0.0, Java 3.0.0, PHP 1.0.0, Ruby 2.0.0 and ant CLI 2.0.0 send 2026-10-21	Anyone who upgrades a dependency
License	New SDK and CLI majors are Apache 2.0; earlier versions stay MIT	Teams that track dependency licenses

Every row above comes from the migration guide for 2026-10-21. Registry timestamps match the announcement: anthropic 2.0.0 on PyPI was uploaded at 15:51 UTC on 21 October, and @anthropic-ai/sdk 1.0.0 on npm nine minutes later. Both packages had already reached 2.3.0 and 1.3.0 by 23 October, so a loose version range picks up the new major quickly.

Why the Claude API temperature parameter now returns a 400

The 400 finishes a change Anthropic made one model at a time. Claude Opus 4.7 and Opus 4.8 already rejected non-default sampling values (May 28, 2026 entry), Claude Sonnet 5 did the same at launch (June 30), and Claude Haiku 5.5 followed (October 7). On 2023-06-01, those models still accepted the default. On 2026-10-21, the parameter itself is invalid, whatever its value.

Model group	On 2023-06-01	On 2026-10-21
Claude 4.7 and later	Default accepted, other values 400	Any value 400; sampling unchanged once removed
Models that accept other values, such as Claude Sonnet 4.6	Any valid value accepted	Any value 400; a lowered temperature loses its effect

The migration guide is explicit about the second row. Without the parameters, a request samples with a temperature of 1.0. On Sonnet 4.6, a request that lowered temperature for more consistent output loses that effect, and "no other setting replaces it." If a request depends on a non-default value, the guide offers two options: stop sending it, or keep that request on 2023-06-01.

What secondary coverage gets half right

Several blogs say temperature was dropped in August with Python SDK 1.0. That is true, but it was a different change. The August 20, 2026 release note says Python SDK 1.0 removed temperature, top_p and top_k from the Messages methods. The API still accepted them. The SDK's own v1 migration guide documents a way around it for older models:

# anthropic 1.x, which still sends anthropic-version: 2023-06-01
client.messages.create(..., model="claude-sonnet-4-6", extra_body={"temperature": 0.2})

That workaround depends on the server accepting the field, and on 2026-10-21 it doesn't. The August change was a client-side TypeError you could route around. The October change is a server-side 400 that no client trick avoids, except the version header.

The workarounds that now fail

Two public GitHub issues show why gateways and wrapper libraries are the weak point. Both predate 2026-10-21, and both workarounds fail under it.

graphiti issue #1103 (December 2025) reports that its MCP server passed temperature: None to Claude Sonnet 4.5 and got a 400. The workaround in the issue is to set temperature: 1.0 explicitly. On 2026-10-21, sending 1.0 is the error.

LiteLLM issue #26444 (April 2026) reports that LiteLLM forwarded temperature to Opus 4.7 even with drop_params=True. In the thread, a commenter reports that the eventual per-model gate drops non-default values but keeps temperature: 1, "matches what the api accepts." That was true on 2023-06-01. Any layer that sends 2026-10-21 and still forwards a default temperature will now fail. If you run a gateway, check what it does with sampling parameters before you check your own call sites.

Pin 2023-06-01 or migrate to 2026-10-21

As of 25 October 2026, the versions page gives no deprecation date for 2023-06-01, and the migration guide tells you to keep a request on it if that request needs a non-default value. Pinning is supported. It isn't free, though.

Keep the anthropic-version 2023-06-01 header

With an SDK, pinning means staying on the current major. The docs say earlier SDK versions send anthropic-version: 2023-06-01 with every request, so you need to cap the range, not just avoid upgrading:

# Python: stay on 1.x
pip install --upgrade "anthropic>=1,<2"

# TypeScript: stay below 1.0 (0.137.0 was the last 0.x release)
npm install "@anthropic-ai/sdk@<1"

If you call the API over HTTP yourself, the version is just a request header, so you can move most traffic and keep the few temperature-dependent requests on 2023-06-01. The cost: every new SDK feature ships on the major you've capped below. A pin buys time; it doesn't remove the work.

Pinning the API version also doesn't pin the model. Claude Sonnet 4.5 retires on the Claude API on November 30, 2026, and the recommended replacement, Sonnet 5.5, already lists sampling parameters among the settings that return a 400. If a pinned workload runs on Sonnet 4.5, its temperature setting has about five weeks left either way.

How to migrate to Anthropic SDK 2.0

1. Search every call site, batch builder and gateway config for temperature, top_p and top_k, and delete them. Sending the default doesn't help.
2. Move any document block in an assistant turn into a user turn, and strip citations from user text blocks. Citations in assistant messages are still accepted.
3. Update Admin API readers to role_ids, rbac_group_id, display_name, group.type and scope.workspace_id.
4. Upgrade the SDK. The new majors also send your key as Authorization: Bearer instead of X-Api-Key, so update any proxy or log filter that reads the old header. In Python, MessageParam is now a union, so calling it as a constructor raises a TypeError.
5. Test against 2026-10-21 before release, as the guide's third step says, then ship the code fixes and the SDK upgrade together.

For raw HTTP, the change is the header:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2026-10-21" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

The model-level breaking changes we covered in Claude Sonnet 5.5's five breaking changes and the Opus 5.5 migration are separate from this. Test a model switch and a version switch one at a time.

Does Bedrock support API version 2026-10-21?

Only for Claude 4.7 and later models. The migration guide warns that for older models on Amazon Bedrock, you should stay on your current SDK version, or keep sending the version you send today, until you move those calls to a 4.7-or-later model. The new SDK majors send 2026-10-21 from their Bedrock and Google Cloud clients too. In TypeScript, @anthropic-ai/bedrock-sdk v1 needs v1 of @anthropic-ai/sdk, so the two upgrade together. A mixed Bedrock estate is the clearest case for pinning.

Deterministic output from Claude without temperature

You never had it. Anthropic's glossary states that even with temperature set to 0, results are not fully deterministic, and identical inputs can produce different outputs. What lowering temperature bought was consistency. That's the property to replace.

When we build on the Anthropic API, we put consistency into the contract rather than the sampler: a fixed schema through structured outputs, validation on every response, and evals that compare outputs across runs instead of assuming they match. Structured outputs guarantee the shape, not the content, so this is the wrong substitute if your product depends on near-identical wording each time. For that workload, the honest answer today is to pin 2023-06-01 on a model that still accepts a low temperature, and to schedule the rewrite.

If you have to decide this week, list every caller of the Claude API, including gateways, batch jobs and Admin scripts, and mark which ones send a sampling parameter. That list tells you whether you're migrating or pinning. If you want a second pair of hands on it, that is the kind of work our AI engineering services team takes on.