Anthropic's Claude API version 2026-10-21 is the first new API version since 2023-06-01, and the new major SDKs send it by default. Upgrading the SDK is the step to plan: temperature, top_p and top_k now return a 400 error, two message shapes are rejected, Admin API fields are renamed and the SDKs carry their own breaking changes.
What was released
API version 2026-10-21 was announced by Anthropic on 21 October 2026 in the Claude API release notes, with a migration guide. On the same day Anthropic released new major versions of every client SDK and the ant CLI that send anthropic-version: 2026-10-21 with each request: 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 important detail is how the version is chosen. An SDK sends the API version that was current when its major version was released, so teams on the old majors stay on 2023-06-01 until they upgrade. Teams calling the API directly opt in by changing the anthropic-version header. According to the versions page, 2026-10-21 is available on the Claude API, Claude Platform on AWS, Microsoft Foundry and Google Cloud. On Amazon Bedrock it works only with Claude 4.7 and later models.
What actually changed in the API
The breaking changes apply to the Messages API, token counting and every request in a Message Batch created with the new version:
- Sampling parameters are removed. A request that sends
temperature,top_portop_kreturns a 400 error, even at the default value. Requests then sample with the defaults, a temperature of 1.0. Claude 4.7 and later models already accepted only the defaults, so they behave as before. On older models such as Claude Sonnet 4.6, a request that lowered temperature for more consistent output loses that effect, and Anthropic states that no other setting replaces it. - Documents in assistant messages are rejected. A
documentblock placed directly in anassistantmessage returns a 400 error. Send documents inusermessages. A document nested inside another block, such as a web fetch result, is still accepted. - Citations in user messages are rejected. A
textblock with a non-emptycitationsarray in ausermessage, including inside asearch_resultblock, returns a 400 error. Citations on Claude's own earlier replies are still accepted. - Admin API and Enterprise Analytics fields are renamed. RBAC groups return
role_idsinstead ofroles, group members returnrbac_group_idinstead ofgroup_id, roles returndisplay_nameinstead ofname, rate-limit entries returngroup.typeinstead ofgroup_type, and the analytics reports useactor.email_addressanddata. - API keys lose
workspace_id. Readscopeinstead. Under the old version anullworkspace meant either the Default Workspace or an all-workspaces key. Now a key bound to a workspace, the Default Workspace included, carries its real ID inscope.workspace_id, and an all-workspaces key has a scope of typeorganization.
What changed in the SDKs and CLI
The new majors also break code in ways that have nothing to do with the API version. The SDK and CLI changes include:
MessageParamis now a union ofUserMessageParam,AssistantMessageParamandSystemMessageParam. In Python, a message written as a plain dict needs no change, but calling or subclassingMessageParamraises aTypeError.- The legacy Text Completions API is gone from the TypeScript, Go, Java and Ruby SDKs and from the CLI, so any
client.completionscall must move to the Messages API. - Client-side compaction is removed from the tool runner in the TypeScript and Ruby SDKs, in favour of server-side compaction with a trigger threshold of at least 50,000 tokens.
- The non-beta Models methods no longer take
betas. Beta headers go throughclient.beta.models. - The CLI's Go module path is now
github.com/anthropics/anthropic-cli/v2. The old path keeps installing the latest v1 release with no warning, which is easy to miss in a build script. - The SDKs and CLI are now licensed under Apache 2.0 instead of the MIT License. Earlier versions stay under MIT.
What it means for teams building on Claude
Treat the SDK upgrade as an API migration, not a dependency bump. This is CodeDTX's advice rather than Anthropic's wording, but it follows from how the version is chosen: whoever merges the next major SDK upgrade also moves every request to the new API version. Pin your current major in Dependabot or Renovate rules until the migration is planned, so an automated pull request doesn't ship it by accident.
Search for sampling parameters first. They are the change most likely to fail at runtime, because they often live in configuration files, prompt templates or shared wrappers rather than in the call itself. If an agent depends on low temperature on an older model, either move it to a Claude 4.7 or later model and re-run your evaluations, or keep that request on 2023-06-01 for now, as the migration guide allows. We covered why evaluations matter before a switch in what AI agent evals catch.
Check gateways and conversation stores. Platforms that replay stored conversations can hit the document and citation rules even if today's code never builds those shapes, because old transcripts may contain them. Test with real stored threads, not only fresh requests.
Update internal tooling that reads the Admin API. Cost dashboards, key inventories and access reviews often read workspace_id or roles. The null Default Workspace logic is the subtle one: compare scope.workspace_id with your Default Workspace's ID, which the List Workspaces endpoint returns with include_default=true.
Mind Bedrock. If some traffic still calls Claude Opus 4.6 or earlier on Bedrock, those calls must stay on the current SDK until you move them to a newer model. A shared client library may need two pinned versions for a while. Teams handling structured output on Bedrock should also re-check their validation after the upgrade, as we described for Claude structured outputs on Bedrock.
When not to switch yet. Anthropic's versions page lists no retirement date for 2023-06-01, so there is no reason to rush a release in the middle of other work. Plan it as a tracked change with a rollback path, the same way you would handle a model deprecation. Do update licence records when you move, since the dependency now changes from MIT to Apache 2.0.
Frequently asked questions
Will my Claude integration break if I do nothing?
No. An SDK keeps sending the API version that was current when its major version was released, so code on the previous major versions keeps sending 2023-06-01 and behaves as before. The breaking changes arrive only when you upgrade to the new major SDK or CLI, or set the anthropic-version header to 2026-10-21 yourself. Anthropic's versions page lists no retirement date for the older version.
How do I keep low temperature on an older Claude model?
Under API version 2026-10-21 you can't, because temperature, top_p and top_k return a 400 error on every model and Anthropic says no other setting replaces them. You can keep that particular request on 2023-06-01, either by staying on the older SDK or by sending the older header, or move it to Claude 4.7 or later and re-run your evaluations to confirm the output is consistent enough.
Which SDK versions send API version 2026-10-21?
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 the ant CLI 2.0.0 are the first versions to send it by default. Their Amazon Bedrock and Google Cloud clients send it too. These majors also include SDK changes unrelated to the API version, such as the MessageParam union and the removal of Text Completions.
Can I use API version 2026-10-21 on Amazon Bedrock?
Only with Claude 4.7 and later models. If you still call Claude Opus 4.6 or an earlier model on Bedrock, Anthropic's guidance is to stay on the SDK version you use today, or keep sending the version header you send today. Move those calls to a Claude 4.7 or later model first, then upgrade them to the new API version along with the rest of your traffic.



