Anthropic has shipped a new version of the Claude API, 2026-10-21. It is the first new version since 2023. Nothing is forced: the old version, 2023-06-01, keeps working. What makes this worth ten minutes of an owner’s or COO’s time is how the new version gets switched on. It does not take a decision. It takes a routine dependency upgrade, and some of the requests your AI integrations send will then be rejected outright.
This is a read of Anthropic’s own migration guide. We have no basis to say that any particular tool or client is affected.
Why it is easy to trigger by accident
The guide opens: “This guide lists the code changes for moving from API version 2023-06-01 to 2026-10-21.” The sentence that matters for non-developers comes next: “If you use an SDK, your requests use the API version that was current when your SDK’s major version was released.” An SDK is the code library a developer, or a tool, uses to talk to Anthropic. So the API version follows the library’s major version number. For Python, the guide says: “Upgrade the anthropic package to version 2.0.0.” Move to that release, whether on purpose or because an update tool bumped it, and your requests now go out as 2026-10-21.
That applies to any integration or tool that bundles Anthropic’s SDK, not only code you wrote. If you call the API without an SDK, you choose the version yourself: “set the anthropic-version header to 2026-10-21.” The guide’s upgrade steps are to switch, “Update your code for the breaking changes,” and “Test your integration against 2026-10-21 before you release.” The last step is the one that gets skipped when the upgrade is a routine bump. The new SDKs also change how the API key is sent, which can break a proxy or gateway in between: the guide says to change “any proxy or gateway that reads or sets X-Api-Key.”
What starts failing
A “400 error” means the request is rejected. The automation step fails instead of producing a worse answer. For an unattended workflow, that means a stalled queue or a ticket that never gets classified. The guide lists the first three changes below for the Messages API, token counting, and each request in a Message Batch created with 2026-10-21. The fourth, on the admin and analytics APIs, is separate.
1. Sampling settings are gone
The guide: “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. Remove the three parameters from your requests.” The presence of the setting fails, not the value.
These are the dials that control how much an answer varies from run to run. “Temperature” is the one most people know: lower it, and answers become more consistent and repeatable. Teams often lower it for tasks like classification and data extraction, where consistency matters. The guide adds that “As of the latest major versions, the SDK and the CLI no longer have the three parameters,” so code that sets them will not carry over cleanly.
2. Documents in the assistant’s turn
“A request that places a document block directly in an assistant message returns a 400 error. Send documents in user messages instead.” If an integration pre-loads a file into the conversation as though the AI had supplied it, that pattern now fails.
3. Citations in the user’s turn
“A request that sends a text block with a non-empty citations array in a user message returns a 400 error.” Citations are how a response points back to the source passage. The guide says this applies including inside search_result blocks. Citations on Claude’s own earlier replies are still accepted.
4. Renamed fields in the admin and analytics APIs
If you have reporting or admin scripts that read Anthropic’s Admin or analytics APIs, field names changed. The guide says responses “no longer include the old names of renamed fields.” On API keys, for example, workspace_id is removed and replaced by scope, and actor.email becomes actor.email_address. A usage or audit report that reads the old names will come back empty or break.
The quiet one: consistency you stop getting
The first three fail loudly. This one does not. Once you remove temperature, the guide says, a request “samples with their defaults, including a temperature of 1.0.” For newer models that changes nothing: “Models that already accept only the defaults, such as Claude 4.7 and later models, sample as before.” For others it does: “On models that accept other values, such as Claude Sonnet 4.6, a request that lowered temperature for more consistent output loses that effect. No other setting replaces it.”
Picture a step that sorts incoming emails into categories, built on an older model with temperature turned down so the same email lands in the same bucket every time. After the upgrade, nothing errors and no alert fires. The results simply become less repeatable, and you find out when someone notices two near-identical emails routed differently. The guide’s advice: “If a request relies on a non-default value, either stop sending the parameter, or keep that request on 2023-06-01.”
We cover the model side in the retirement calendar and in how to choose between models.
The Amazon Bedrock caveat
If you reach Claude through Amazon Bedrock, the guide is specific: “On Amazon Bedrock, 2026-10-21 is available only for Claude 4.7 and later models. If you call an older model on Bedrock … (Opus 4.6 and earlier), stay on the SDK version you use today.” An older model on Bedrock plus an eager upgrade is a combination to check before anything is bumped.
What to do this month
This is the cost we described in what an API integration costs after it ships: someone has to own the upgrades, the testing and the pins. None of the steps below is large. Each needs a named owner.
- List every integration that calls Claude. Include tools that bundle Anthropic’s SDK, not just code you wrote. Note who maintains each, its SDK version and its model.
- Pin SDK major versions. Make the move to a new major version a decision someone makes on purpose, not a side effect of an automatic update. The recent LiteLLM compromise shows why unpinned updates are risky in the other direction too.
- Before upgrading, search for the three settings. Look for
temperature,top_pandtop_kin code and in workflow configurations. Also look for documents placed in assistant messages and for citations sent in user messages. - Test consistency, not just errors. Run a fixed set of real classification and extraction inputs before and after removing temperature, more than once each, and compare. Errors announce themselves. Drift does not.
- Decide per request whether to stay on 2023-06-01. Anthropic’s guide describes keeping a request that depends on a non-default setting on
2023-06-01as an option. It does not state an end date for that version. Write down which requests stay there and why. - If you are on Bedrock with older models, do not upgrade yet. Stay on the SDK version you use today until you have moved to Claude 4.7 or later.
Owning it means owning this work
We build AI on infrastructure the client owns. The tradeoff of that choice is that nobody else pins your versions or runs your regression tests for you. That work belongs on someone’s calendar, with a name next to it. If it is not on yours, a fractional CIO can own the inventory and the upgrade decisions, and AI integration done properly includes pinned versions and a test set from the start.
The 30-second version
Anthropic released API version 2026-10-21. The old version keeps working, but upgrading an SDK to a new major version switches the new one on. After that, requests that send temperature, top_p or top_k, put documents in assistant messages, or send citations in user messages are rejected, and older models lose the consistency that a lowered temperature gave. Inventory your integrations, pin SDK versions, search for those settings, test outputs for consistency, and hold off on Bedrock if you use older models.