Anthropic SDK v2.3.0 Released: Claude Tag Endpoints and Multiple Internal Refactors

The official Anthropic SDK has released version v2.3.0, adding Tag endpoints for Claude Enterprise organizations and making a series of fixes and improvements in Google Cloud support, client-side query parameter handling, and documentation descriptions. This version introduces no breaking changes and is more about filling in gaps in API capability boundaries and internal implementation consistency.

New Claude Tag Endpoints for Enterprise Organizations

The most notable feature of v2.3.0 is the addition of Claude Tag endpoints to the api module, specifically for Claude Enterprise organizations. The tagging mechanism is typically used to categorize and retrieve resources within an organization (such as conversations, projects, or user groups). The addition of this endpoint means enterprise customers can manage tag data directly through the SDK without having to construct HTTP requests themselves.

For teams already using Anthropic's enterprise capabilities, this is a directly actionable feature increment; for individual developers, the impact is limited for now. This move also shows that Anthropic is gradually pushing enterprise-level management capabilities down to the official SDK layer, reducing redundant integration work for customers.

Google Cloud-Related Fixes and Product Name Updates

This release includes two adjustments in the Google Cloud direction. First, user profiles requests are now sent to the organization endpoint, which is a bug fix correcting the previously incorrect request target. Second, the product name has been updated in the documentation to ensure consistency with current external naming.

These fixes are particularly important for developers accessing Claude through Google Cloud paths such as Vertex AI—requests landing on the wrong endpoint often manifest as hard-to-troubleshoot 4xx or permission errors. Fixing this directly at the SDK layer can save a round of debugging costs.

Vertex AI is a unified AI development platform on Google Cloud for building, deploying, and scaling machine learning models. Claude models are provided in managed form through Vertex AI Model Garden, and calls use Google Cloud's service accounts and IAM permission system. Therefore, the distinction of "organization endpoints" in the SDK is particularly critical: if requests on Google Cloud do not land on organization-level paths, they may bypass the expected project and billing attribution and return 403 or 404, and the error messages usually do not directly indicate endpoint concatenation issues. Anthropic SDK's support for Google Cloud is essentially an additional layer of authentication and routing logic wrapped around the standard Messages API, allowing developers to call models on Vertex with similar interfaces. Understanding this layer of difference helps determine whether the target addresses of user profiles-related requests match your own GCP project structure when upgrading.

Client Query Parameter Handling Changes

One noteworthy item in the internal refactoring: stop hardcoding query parameters in endpoint paths, and elevate query parameters carried by endpoint paths to the request layer for unified handling. Complementing this, the internals now read the beta route qualifier instead of relying on the beta=true query parameter, and parse and stream no longer send beta query parameters.

The significance of these changes lies in unifying the request construction path. Although hardcoding query parameters is simple and direct, it can easily lead to inconsistencies once endpoint behavior changes or request-layer logic needs to be reused. Consolidating parameter handling into the request layer is a common practice for long-term SDK maintainability. For upper-layer callers, the API surface remains unchanged in most cases, but if you have code that directly depends on the raw query strings sent, you should be aware of behavioral differences.

A beta route qualifier is a mechanism in the Anthropic API that identifies in the path that "this interface is in beta stage," for example paths containing ?beta=true or a specific beta version identifier. Early SDKs hardcoded such identifiers directly into endpoint strings, making them invisible to and unmodifiable by the request layer. After switching to reading the qualifier at the request layer, the SDK can uniformly decide before sending whether to append the beta identifier and which beta version to use, thereby avoiding inconsistent behavior across different call paths such as parse and stream. For teams that wrap HTTP requests themselves or perform request interception and log auditing, this means the raw URLs seen in packet captures may differ from older versions, but they are semantically equivalent, and assertion or mock rules need to be adjusted accordingly.

Multiple Documentation and Example Improvements

Documentation updates are quite dense: improved descriptions of the code execution tool and its encrypted results; rewrote explanations of work queue, skill, and external key; updated descriptions of per-user usage and cost reports; added links to SDK documentation in the docstrings for raw responses from Bedrock and Vertex; and updated the README and example requests.

Additionally, a redundant await was removed from the tool_runner async example in the documentation—a typical example code correction, as redundant await in async examples can easily mislead beginners into writing incorrect call chains.

The code execution tool is a tool-calling capability of Claude that allows the model to run code in a controlled sandbox and return results, with intermediate artifacts returned in encrypted form to ensure content is not tampered with and can be verified by the server. Work queue and skill are enterprise-level orchestration concepts: the former is used for queuing and state tracking of asynchronous tasks, while the latter is used to encapsulate reusable operations into capability units callable by the model; external key refers to credentials hosted by the customer for reference by the SDK, avoiding plaintext keys entering request bodies. Per-user usage and cost reports rely on organization and user identifiers for aggregation, facilitating cost allocation for enterprises. The degree of documentation for these concepts directly affects whether integrators can correctly configure permissions and billing standards.

Internal Engineering and CI Adjustments

There are also several maintenance changes on the engineering side: workflows now validate repositories by owner and public name; the preview build upload step has been removed from CI. These changes are not directly exposed to users but reflect the project's ongoing tightening of release processes and repository validation rules.

Upgrade Recommendations

For most users, v2.3.0 can be upgraded directly: the new endpoints are incremental capabilities, the bug fix corrects the target endpoint for Google Cloud user profiles requests, and documentation updates also help understand capabilities such as the code execution tool and usage reports. There are two scenarios that require additional verification: first, custom wrappers that depend on the specific query parameters sent by the SDK (especially beta-related parameters); second, integrations that use Google Cloud paths and are sensitive to user profiles request endpoints.

Overall, this version is a routine iteration focused on filling in enterprise capabilities and internal consistency, with no aggressive interface changes, suitable for smooth adoption after verification in a test environment.