Anthropic SDK v2.6.0 quietly fixes the thing every Bedrock user has hit

Anthropic shipped anthropic-sdk-python v2.6.0 on November 5, and the headline feature is not a model, an endpoint, or a price cut. It is error codes. The release notes list a new error code for ramp limit errors, new codes for External Key validation failures, and support for signing organization members out everywhere. That last one is an admin control. The first two are the kind of detail that tells you where Anthropic’s enterprise traffic actually lives.

Read the whole changelog and a pattern emerges. This is a maintenance release aimed squarely at teams running Claude through Amazon Bedrock and Google Vertex AI, not at people calling the first-party API from a laptop. The bug-fix section says it plainly: bedrock,vertex now raise error-code and status exception classes on platform clients. Before this, if you were on Bedrock and something failed, you got a generic exception. Now the SDK maps the platform’s status into the same typed error classes the first-party client uses.

The unglamorous work of making Bedrock feel like the real API

That mapping matters more than it sounds. A large share of enterprise Claude usage runs through Bedrock, because that is where procurement, IAM, and existing AWS commitments already live. But Bedrock is a wrapper. The request goes through AWS’s model-invocation layer, and the errors come back shaped by AWS, not by Anthropic. Builders who wrote retry logic against the Anthropic API’s typed exceptions found it did not fire the same way on Bedrock. The v2.6.0 fix closes that gap.

The companion fix is subtler. The release keeps a custom http_client and aws_profile on copies made with copy and with_options. Anyone who has built a multi-tenant service on top of the SDK knows the trap: you configure a client with a specific AWS profile or a tuned HTTP client, then call with_options to override a timeout or a header, and the copy silently drops your credentials context. The result is a request that authenticates as the wrong principal, or fails to authenticate at all. The fix is one line in a changelog and a very bad afternoon avoided in production.

Sampling parameters come off the spans

The chore that deserves the most attention is this: the client stops recording sampling parameters on OpenTelemetry spans. On its face, that is a privacy and cost decision. Sampling parameters like temperature and top-p are prompt-adjacent metadata, and shipping them into a tracing backend means your observability vendor now holds a fingerprint of how you are calling the model. For regulated customers, that is a compliance question. For everyone else, it is span bloat.

There is a second reading, and it is the one builders should care about. Anthropic is treating telemetry as a product surface with its own hygiene rules, not an afterthought bolted on by whoever wired up tracing. The release also defines the status error mapping once on the base client and tells contributors when a runtime type check belongs. These are the moves of a team that has decided the SDK’s job is to be predictable, and predictability is a feature enterprises pay for.

The documentation changes reinforce it. The client docs now describe the type, message, code, and details of API errors, and list each method’s errors without their descriptions. That last clause is the interesting one. Anthropic is separating the machine-readable error surface from the human-readable prose. Your code can switch on a code. Your on-call engineer can read the description. Keeping them apart means the codes can stay stable while the prose evolves.

What ramp limits and external keys tell us

Two of the new error codes are worth decoding. A ramp limit error is a rate-limit variant tied to a gradual capacity ramp, the kind of thing that shows up when an account is being onboarded onto higher throughput over time rather than granted it all at once. Giving that its own code means Anthropic expects builders to handle it as a distinct case, not lump it in with a generic 429 and retry with backoff. The right response to a ramp limit is different from the right response to a burst limit.

External Key validation failures point at a different architecture: customers who bring their own keys or route through a key-management layer. A dedicated code for that failure lets a platform team distinguish “your key is bad” from “our service is down,” which is the difference between paging the customer and paging yourself.

The most revealing thing about v2.6.0 is what it does not add: no new model, no new endpoint. Just the plumbing that makes the existing ones safe to build on.

The take

Tessera’s read: this is a maturity release, and it is a good sign. The AI SDK wars are not going to be won on autocomplete or streaming helpers. They will be won on the boring stuff, typed errors that survive a cloud wrapper, credential context that survives a client copy, and telemetry that does not quietly exfiltrate your inference configuration. Anthropic is competing on that ground now.

The counterpoint is that none of this is visible to a developer evaluating Claude for the first time. A new user reads the quickstart, gets a completion, and never touches a ramp-limit code. The value here accrues to teams already deep in production, and those teams are exactly the ones who notice when an SDK stops surprising them.

There is a gap worth flagging. The release notes do not say whether the Bedrock and Vertex error-code mapping covers every status the platforms can return, or only the common ones. {/* TODO: verify whether the v2.6.0 bedrock/vertex error-code mapping is exhaustive or partial — release notes do not specify; check the SDK source or ask Anthropic for comment */} Builders running unusual failure modes should test their retry paths against the new classes before assuming parity with the first-party client.

For AI builders, the practical upshot is a version bump worth taking if you run Claude on Bedrock or Vertex, and a reason to audit what your tracing stack has been collecting. The sampling-parameter change means your existing dashboards may go quiet on a few fields. That is the point.

The next thing to watch is whether the other SDKs follow. The release was cut by anthropic-sdks-releaser, the automated account Anthropic uses to publish client libraries, which suggests the same changes are queued for the TypeScript, Go, and Java clients. When they land, the error surface across Anthropic’s whole SDK family starts to look uniform, and that uniformity is what lets a platform team write one retry policy and trust it everywhere.