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

Anthropic released Claude API version 2026-10-21 on October 21, 2026. Under that version, a Messages request that sends temperature, top_p, or top_k returns a 400 error on every model, even when the value is the default. The new SDK major versions, including Python SDK 2.0.0 and TypeScript SDK 1.0.0, send 2026-10-21 by default, so the decision for most teams is whether to upgrade the SDK now or keep specific requests on 2023-06-01.

For many integrations the output will not change. Anthropic says Claude 4.7 and later models already accept only the default sampling values, so they sample as before. The catch is older models that accept other values. According to the migration guide, a request to a model such as Claude Sonnet 4.6 that lowered temperature for more consistent output loses that effect, and "no other setting replaces it."

What changed in Claude API version 2026-10-21?

Version 2026-10-21 is the first new anthropic-version value since 2023-06-01, according to Anthropic's versions page. It removes three sampling parameters and tightens two message rules. Anthropic lists these breaking changes for the Messages API, token counting, and Message Batches:

• Sampling parameters: temperature, top_p, and top_k are removed. Sending any of them returns a 400 error, even at the default value.
• Document blocks: a document block placed directly in an assistant message returns a 400 error. Documents belong in user messages. A document nested inside another block, such as a web fetch tool result, is still accepted.
• Citations: a text block with a non-empty citations array in a user message returns a 400 error. Citations on assistant text blocks are still accepted.

The Admin API and Claude Enterprise Analytics API also drop the old names of renamed fields. For example, RBAC groups return role_ids instead of roles, per-user usage reports use actor.email_address instead of actor.email, and API keys no longer return workspace_id. Code that reads a key's workspace should read scope.workspace_id instead. Anthropic notes that this returns the real ID even for the Default Workspace, where the old field was null.

Which SDK versions send anthropic-version 2026-10-21?

The SDKs pick the version for you. Anthropic says a request uses the API version that was current when the SDK's major version was released. That means upgrading the SDK major changes the API version, and staying on the current major keeps 2023-06-01.

Scroll sideways to see all 2 columns.

SDK or tool	First version that sends 2026-10-21
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
ant CLI	2.0.0

The new version is available on the Claude API, Claude Platform on AWS, Microsoft Foundry, and Google Cloud. On Amazon Bedrock it is available only for Claude 4.7 and later models. Anthropic's guidance for Bedrock calls to Opus 4.6 and earlier is to stay on the current SDK version, or switch those calls to a 4.7 or later model first.

The new SDK majors carry other breaking changes that do not depend on the API version. Two matter beyond type signatures. The SDKs now send the API key as Authorization: Bearer instead of in the X-Api-Key header, and a client holds a single credential. The SDKs and the CLI also move from the MIT License to Apache 2.0. No code change is needed for the license, but teams that track dependency licenses should update their records.

What our local check of the Python SDK showed

BaristaLabs ran a small check on October 22, 2026 to see what the Python SDK actually sends. We installed anthropic 1.17.0 (the last 1.x release) and 2.1.0 (the current release) and pointed each client at a local stub server with a fake key. Nothing was sent to Anthropic, so this check shows request headers and bodies, not the API's 400 response.

Scroll sideways to see all 3 columns.

What we checked	1.17.0	2.1.0
Default anthropic-version header	2023-06-01	2026-10-21
API key header	X-Api-Key	Authorization: Bearer
temperature=0.2 as a keyword argument	TypeError	TypeError
temperature passed through extra_body	Sent	Sent
Per-request extra_headers set to 2023-06-01	Sent as set	Sent as set

Two results stood out. First, neither version accepts temperature as a named argument to messages.create() in Python, so a passing type check does not prove a codebase is clean. A request can still carry the field through extra_body, a raw HTTP call, or a gateway that adds it. Under 2.1.0, that request goes out with 2026-10-21, which Anthropic documents as a 400.

Second, the per-request header override worked. A team can upgrade to 2.x and still keep one request on 2023-06-01, which matches Anthropic's guidance for requests that depend on a non-default value. That request would still need extra_body to carry temperature, because the 2.x types no longer include it.

Where sampling settings and API keys hide

The parameter is often far from the code that calls the SDK. Search the final request path, not only application code:

• Shared model configuration files and provider adapters that add temperature to every call.
• extra_body arguments, raw HTTP clients, and scripts that call /v1/messages directly.
• Prompt templates and evaluation fixtures that store generation settings next to the prompt.
• Proxies and gateways that inject defaults, or that read X-Api-Key to route, meter, or authenticate traffic.

The gateway point is easy to miss. Anthropic says the Claude API accepts a key in either header, so direct callers need no change. A gateway that expects X-Api-Key will stop seeing the key once the client moves to 2.x. The migration guide shows how to move the key back with an auth function on the HTTP client, but changing the gateway to read Authorization is usually the cleaner fix.

The Gemini case was the reverse. Our post on Gemini 3.6 Flash ignoring three sampling settings covered a model that accepted the same fields and silently disregarded them. Claude's new version fails loudly instead, which is easier to find but stops the request.

Who does this affect?

The change matters most for three groups:

• Teams on Claude Sonnet 4.6 or other models that accept non-default values and set a low temperature for steadier output, for example in extraction or classification. After the switch, those requests either fail or, once the field is removed, sample at the default of 1.0.
• Teams that run a gateway or proxy between their apps and the Claude API, because of the header change.
• Bedrock users on Opus 4.6 or earlier, who should not move those calls to the new SDK major yet.

Teams already on Claude 4.7 or later models that never set these fields mostly need to upgrade and run their tests. Our earlier article on why temperature zero doesn't make output deterministic is a useful reminder that a low temperature never guaranteed identical output, so losing it is a smaller change than it may look.

Why it matters for small engineering teams

BaristaLabs interpretation: the risk is a dependency bump that looks routine. A Dependabot or Renovate pull request that moves anthropic from 1.x to 2.x changes the API version, the auth header, and the license at once. If CI mocks the Claude API, the tests can pass while production requests that carry temperature start returning 400. On a small team the same person often owns the gateway and the app, so this is a short fix if someone checks before merging.

Upgrade now or pin specific requests

BaristaLabs recommends upgrading on purpose rather than letting an automated bump decide:

1. Search the request path for temperature, top_p, and top_k, including extra_body, raw HTTP calls, configs, and fixtures. Also look for document blocks in assistant turns and citations on user text blocks.
2. Check gateways and proxies for X-Api-Key handling before the SDK change ships.
3. Decide per request. If output quality does not depend on a lowered temperature, remove the field and upgrade. If it does, keep that request on 2023-06-01 with a per-request header and re-test it on a model where the default applies.
4. Test against 2026-10-21 with real requests, not mocks, and release the SDK upgrade together with those fixes, as Anthropic's guide says.

For broader help planning model and API changes, see our AI consulting services.

Sources and scope

• Claude Platform release notes, Anthropic, entry dated October 21, 2026: the new API version, SDK versions, and license change.
• Claude API versions, Anthropic: version history, availability by platform, and the list of breaking changes.
• Migrating to API version 2026-10-21, Anthropic: upgrade steps, sampling defaults, Bedrock limits, and SDK changes, including the auth header.
• anthropic 2.0.0 on PyPI, uploaded October 21, 2026, and the v2.0.0 release on GitHub.

Our local check covered the Python SDK only and did not call the Claude API. Anthropic has not said how long 2023-06-01 will remain available, and these sources do not show how output quality changes when a request moves from a low temperature to the default.