Claude API 2026-10-21: your next SDK bump drops temperature

A dependency bump that changes the protocol

Anthropic has shipped its first new Claude API version since 2023-06-01. The release notes for 21 October 2026 say: "We've released API version 2026-10-21." The same entry lists new SDK and CLI majors that send that version by default: 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 the ant CLI 2.0.0.

Most of the attention is on one change. Under the new version, temperature, top_p and top_k are no longer accepted. Sending any of them returns a 400, even at the default value, and nothing replaces them. Most teams will not opt into this on purpose. It reaches them through pip install -U anthropic, a Renovate PR, or a Dependabot bump that someone approves on a Friday afternoon. The version string is now tied to the SDK major, so upgrading the library also upgrades the protocol.

This post covers what breaks, who is affected, and the audit worth running before you merge that upgrade.

What actually returns 400 now

The migration guide is blunt about the headline change: "In 2026-10-21, a request that sends temperature, top_p, or top_k returns a 400 error, even at the parameter's default value." This applies to both Messages and Message Batch requests.

The phrase "even at the parameter's default value" matters most in practice. Plenty of codebases send temperature=1.0 explicitly because a config template or a wrapper factory always fills it in. Those calls change nothing about sampling, but they will still fail. You cannot reason "we never changed temperature, so we're fine". If the key is in the request body, it fails.

Whether you lose behaviour, and not just an error, depends on the model. Per the guide, Claude 4.7 and later already accept only the defaults, so they sample the same way as before. On older models such as Claude Sonnet 4.6, a request that lowered temperature loses that effect, and in the guide's words, "No other setting replaces it." There are two options: stop sending the parameter, or keep that request on 2023-06-01.

Two more validation changes also return 400 under the new version:

• a document block placed directly in an assistant message
• a text block with a non-empty citations array in a user message

Nested documents, such as web fetch tool results, are still accepted. If you replay conversation history that includes model output with citations, check how your code puts it back into the next turn.

The breaks that have nothing to do with the version string

The release notes add that the new SDKs "also have breaking changes that don't depend on the API version, and they are licensed under Apache 2.0 instead of the MIT License." So pinning the API version header alone is not enough to make the upgrade safe.

The quietest one is authentication. The SDKs and CLI now send the key in an Authorization header as a Bearer token instead of in X-Api-Key. The API accepts either, so if you call Anthropic directly, nothing changes. If traffic goes through an internal gateway, a cost-tracking proxy, or a rate limiter that reads X-Api-Key to identify the caller, that layer will stop seeing a key after the upgrade. The migration guide says to update any such proxy. The Foundry clients still send x-api-key, so a mixed fleet may send both headers for a while.

The other SDK-level changes in the guide:

• Text Completions is removed from the TypeScript, Go, Java and Ruby SDKs and from the CLI.
• Client-side compaction is removed from the TypeScript and Ruby tool runners in favour of server-side compaction, and the trigger threshold must be at least 50,000 tokens.
• The Go SDK moves to the module path github.com/anthropics/anthropic-sdk-go/v2, so imports change.
• On Amazon Bedrock, 2026-10-21 is available only for Claude 4.7 and later.

The Python SDK changelog lists the new version under "BREAKING CHANGES" in v2.0.0, and a v2.1.0 followed the same day. If your lockfile resolves to the newest 2.x, you are on the new protocol whether you read the changelog or not.

What doesn't change: according to AlphaSignal's report, 2023-06-01 is not deprecated, so pinned integrations keep working. AlphaSignal also reports that Anthropic plans to release API versions more often, timed ahead of model launches. Neither claim appears in the release notes or the migration guide, so treat both as reporting, not policy. Two independent write-ups, from Developers Digest and DEV Community, agree that older SDK majors keep sending 2023-06-01 with no announced end date.

temperature=0 was never a reproducibility contract

The teams most upset by this change usually used low temperature to get "deterministic" output. That covers eval suites, regression tests that diff model output against golden files, and extraction pipelines where a stray rephrasing broke a parser.

That approach was fragile before this release. Low temperature makes output less varied. It never promised identical output across calls, deployments, or model snapshots. An eval that passes only when the model gives the same answer every time is measuring luck as much as quality. Removing the knob just makes the weakness obvious.

If your evals depended on it, this is a good moment to redesign them:

• Sample more than once. Run each case several times and score the pass rate, not a single pass or fail. A prompt change that drops a case from 10/10 to 7/10 is a real signal. A single-run diff can't show you that.
• Grade against rubrics, not strings. Check whether the output contains the required facts, follows the schema, and avoids the forbidden content. Do not check whether it matches last week's text character for character.
• Move format guarantees into structure. If a parser breaks on variation, the fix is a stricter output schema and validation, not lower randomness.

Staying on 2023-06-01 for a specific Sonnet 4.6-era workload is a legitimate choice. Make it a deliberate, documented exception per workload, not the reason the whole codebase stays on an old SDK major.

The pre-upgrade audit

Before you merge the SDK bump, run these four checks. The Developers Digest and DEV Community guides recommend roughly the same steps: strip sampling parameters from shared client wrappers, check gateway header handling, upgrade platform packages together with the core SDK, and re-run evals after the switch.

1. Find every sampling parameter, including the hidden ones.

grep -rnE '\b(temperature|top_p|top_k|topP|topK)\b' \
  --include='*.py' --include='*.ts' --include='*.js' \
  --include='*.go' --include='*.java' --include='*.rb' \
  --include='*.php' --include='*.cs' \
  --include='*.yaml' --include='*.yml' --include='*.json' .

The direct call sites are easy to find. The dangerous ones are client factories, shared config defaults, prompt registries and YAML templates that inject temperature into every request. Remove them at the source, not call by call.

2. Check what your proxy reads. If anything between your code and the API authenticates, meters or routes on X-Api-Key, teach it to read Authorization: Bearer too before any service upgrades. Roll the gateway first, then the clients.

3. Pin the SDK major until evals pass. Put an upper bound on the dependency, for example anthropic<2 in Python, and tell Renovate or Dependabot to hold majors for this package. Upgrade on a branch, upgrade any platform-specific packages at the same time, and run the full eval suite with the new version before you lift the pin.

4. Decide per workload. List the calls that send a lowered temperature to a pre-4.7 model. For each one, decide whether it can accept default sampling or whether it should stay on 2023-06-01 for now. Record the decision next to the code, and on Bedrock, remember the new version is only available for 4.7 and later.

The new version is not the risky part. The risky part is that it arrives through the same automated path as a patch release. If you hold the major, clean up the wrappers and fix the gateway, the actual switch is a small change you choose to ship.