Claude API Gets a New Version, 2026-10-21 - Sending temperature, top_p or top_k Now Returns a 400 Error, and Every SDK Has a Major Release

Anthropic published a new Claude API version, 2026-10-21, on October 21, 2026¹. At the same time it shipped new major releases of its SDKs and of the ant command-line tool, all of which send this version by default: Python SDK 2.0.0, TypeScript SDK 1.0.0, C# SDK 13.0.0, Go SDK 2.0.0, Java SDK 3.0.0, PHP SDK 1.0.0, Ruby SDK 2.0.0 and ant CLI 2.0.0.

The official version history now has three entries: 2023-01-01 (the initial release), 2023-06-01, and the new 2026-10-21. The migration guide is written for code moving from 2023-06-01²³. The new version contains breaking changes, and the SDKs and CLI carry breaking changes of their own that have nothing to do with the API version. The SDK and CLI license changes from MIT to Apache 2.0¹.

Requests that now fail with a 400 error

Three patterns in the Messages API become errors². The rules also reach token counting and the individual requests of any batch made under 2026-10-21, not just the Messages API itself.

• Including temperature, top_p or top_k gets the request rejected with status 400, and passing the default value does not help. According to the versions page, no model is exempt³
• Putting a document block at the top level of an assistant turn is now rejected with status 400. Documents should go in user turns instead. Nested documents are fine, for example one that arrives wrapped in a web fetch result Claude produced earlier
• User-turn text blocks carrying a non-empty citations array are rejected with status 400, and wrapping them in a search_result block does not change that. Citations on assistant turns still pass, as does turning citations on with "citations": {"enabled": true} for documents or search results

On the management side, renamed fields no longer come back under their old names. In the Admin API, for example, RBAC groups return role_ids instead of roles, and rate-limit entries return group.type instead of group_type. In the Claude Enterprise Analytics API, per-user reports use actor.email_address instead of actor.email. The one that needs care is workspace_id on API keys: until now a key tied to the Default Workspace came back with null. The new version drops the field and gives the real workspace ID in scope.workspace_id, so code that read null as “Default Workspace” has to compare against the Default Workspace’s actual ID instead.

What happens to code that lowered temperature

With the three sampling parameters gone, requests sample with the defaults, which means a temperature of 1.0. The migration guide says this matches a 2023-06-01 request that omits them².

How much this matters depends on the model. Models from Claude 4.7 onward only take the defaults anyway, so their output is unaffected. Older models that do take custom values are different: on Claude Sonnet 4.6, for instance, a low temperature set to make answers steadier will no longer have any effect, and the guide states that nothing replaces it. Where a request really needs a custom value, developers can either drop the parameter and accept the default, or leave just that request on 2023-06-01.

When we covered Claude Haiku 5.5, released on October 7, the rule was model-specific: on Haiku 5.5, a temperature other than 1, a top_p other than 0.99, or any top_k returned a 400 error. Now the restriction is tied to the API version, and the parameters are refused whatever their value. For what these parameters actually control, see our glossary entry What are temperature and top-p?.

What changes when you upgrade an SDK

With an SDK, the API version attached to each request is the one that was current when that SDK’s major version came out². Older SDKs attached 2023-06-01 to every request. The new major releases listed above send 2026-10-21, as do the clients they provide for Bedrock and Google Cloud. Code that makes raw HTTP calls switches by putting 2026-10-21 in its anthropic-version header.

Of the SDK changes, the authentication header is the one that can reach beyond application code. The new SDKs and CLI put the API key in Authorization: Bearer <key> rather than in X-Api-Key. Since the API itself takes the key from whichever of the two headers it finds, direct callers have nothing to change. A proxy or gateway in between that reads or sets X-Api-Key, however, must either handle Authorization or be fed the key in X-Api-Key by configuring the SDK to do so. Clients for Microsoft Foundry continue to send the key as x-api-key.

Because API keys and auth tokens now travel in the same header, a client holds a single credential. In the Python SDK, giving the constructor an API key together with an auth token raises ValueError; the previous major version would send the two in separate headers.

Other changes the migration guide lists include:

• The MessageParam type is now split into separate types for the user, assistant and system roles. The request body is unchanged, and Python code that writes messages as dicts does not need edits
• The old Text Completions endpoint is no longer supported by the CLI or by the SDKs for TypeScript, Go, Java and Ruby
• The TypeScript and Ruby tool runners no longer do client-side compaction (summarizing the conversation); server-side compaction inside the API replaces it
• TypeScript users of the Bedrock, Vertex, Foundry, AWS or Google Cloud packages should bump those to v1 at the same time; otherwise the package manager ends up installing an extra, outdated @anthropic-ai/sdk alongside the new one
• The Go SDK’s module path now ends in /v2, so import statements have to change. A CLI installed through go install with the old path will quietly stay on v1
• In PHP, composer update alone will not cross to the new major version
• The CLI drops its --api-key and --auth-token flags, since a secret passed as a flag can leak through the shell’s history or the list of running processes; environment variables or --api-key-stdin are the replacements

We covered the types of API keys when the Claude Console added personal and service account keys.

Older models on Bedrock, and the license

On Amazon Bedrock, 2026-10-21 works only with models from Claude 4.7 onward². For Bedrock calls to Opus 4.6 or earlier, the guide’s advice is to keep the current SDK release, or, where the version header is set manually, to keep sending today’s value. Those calls can only move to 2026-10-21 after first switching to a model from Claude 4.7 onward. The Claude API itself, Claude Platform on AWS, Microsoft Foundry and Google Cloud all offer the new version³.

As for licensing, the SDKs and CLI are under the Apache License 2.0 starting with these releases, while earlier releases stay under MIT². No code changes follow from this, but organizations that keep a register of their dependencies’ licenses will need to update the entries.

Where 2023-06-01 stands

The versions page advises staying on the newest version where you can, treats older versions as deprecated, and warns that new users might not be able to use them³. The official documentation we checked gives no date on which 2023-06-01 stops working. The migration guide itself offers keeping requests that rely on a non-default temperature on 2023-06-01 as one of the options².

In practice, the main point is not to let this SDK upgrade slip in with routine dependency bumps. Moving to the new major versions turns requests that set temperature into 400 errors and changes how authentication reaches any proxy built around X-Api-Key. The migration guide likewise asks developers to ship the SDK upgrade together with their code fixes and to test against 2026-10-21 before releasing. If a model migration happens around the same time as the SDK upgrade, checking separately which requests each change affects will make failures easier to trace.

Sources

1. Claude Platform release notes - Anthropic official release notes (entry for October 21, 2026)
2. Migrating to API version 2026-10-21 - Anthropic official documentation (migration guide)
3. Versions - Anthropic official documentation (list of API versions)