Vercel AI SDK Adds Safety Identifier Support for xAI

AI SDK adds a safetyIdentifier option for xAI, enabling user-level attribution of policy violations.
Vercel's AI SDK released @ai-sdk/xai 2.0.103, adding a safetyIdentifier provider option to the Responses API. When enabled, the SDK sends the configured safety_identifier to xAI with the request, letting the platform attribute content policy violations to specific end users and echoing the server-returned value in providerMetadata.xai.safetyIdentifier. This lets multi-user apps integrate xAI's compliance attribution without hand-assembling HTTP requests, and improves log and monitoring observability. The release also upgrades internal dependencies like @ai-sdk/provider-utils and @ai-sdk/openai-compatible. The source doesn't specify format constraints, so check official docs before launch.

Vercel's AI SDK has made a small but noteworthy feature addition to its xAI integration: @ai-sdk/xai has released version 2.0.103, adding a safetyIdentifier provider option to the Responses API. The change itself is only a few lines, yet it touches on a long-standing gray area in content compliance for multi-user AI applications.
A patch update that solves the attribution problem
According to the repository commit history, this change is a feat-level new capability: when calling xAI's Responses API, the SDK sends the configured safety_identifier along with the request, allowing xAI to attribute a policy violation to a specific end user; at the same time, the SDK echoes the value returned by the server at providerMetadata.xai.safetyIdentifier.
This means developers building applications with the AI SDK no longer need to bypass the SDK and hand-assemble HTTP requests to let xAI's server identify "which user this request comes from." For consumer-facing products with large user bases, this is the most direct path to integrating xAI's official compliance capabilities.
Why a safety identifier deserves to be a standalone option
Large model providers generally require developers to be responsible for end-user behavior, but the prerequisite for "responsibility" is being able to distinguish users. When a request triggers a content policy, if the server can only see a shared API key, it cannot determine which account the violation came from, and neither platform-level governance nor developer-level accountability is possible.
The design philosophy of safety_identifier is to hand attribution responsibility back to the application layer: the developer decides what identifier represents a user, and xAI is only responsible for recording and associating it. By packaging it as a provider option, the AI SDK effectively standardizes this pattern—compared with directly passing through a custom header, it is clearer and less likely to break in future versions. Judging from the wording of the commit description, xAI explicitly uses this field for policy violation attribution, not merely for record-keeping.
Provider options and the providerMetadata mechanism
In the AI SDK architecture, provider options are the standard entry point for developers to pass extra configuration for a specific model vendor. The AI SDK encapsulates vendor differences into provider implementations, so developers do not need to directly construct each vendor's different HTTP request bodies; instead, they pass vendor-specific parameters through providerOptions on a unified calling interface. The SDK is responsible for mapping these parameters to the correct request fields and returning vendor-specific non-standard data in the response via providerMetadata. This design isolates vendor differences at the provider layer, keeping upper-layer application code consistent when switching between multiple vendors. safetyIdentifier is implemented through exactly this mechanism: developers only need to declare the identifier in the provider configuration, and the SDK automatically handles request injection and response echoing, avoiding manual HTTP request assembly or reliance on undocumented header pass-through.
Synchronized version dependency updates
In addition to the main feature, this release also upgraded several internal dependencies, including @ai-sdk/provider-utils to 3.0.45 and @ai-sdk/openai-compatible to 1.0.62. xAI's provider implementation itself is built on top of the openai-compatible abstraction, so changes in the upstream compatibility layer propagate directly.
For users, a patch version number usually means a painless upgrade, but for changes involving provider options it is still advisable to verify after upgrading: confirm whether safety_identifier actually appears in the request, and whether the echoed field in providerMetadata matches expectations. This is especially important if the application already handles user identifier pass-through logic itself, to check whether it duplicates the SDK's new behavior.
The openai-compatible abstraction layer
@ai-sdk/openai-compatible is a generic provider base class provided by the AI SDK for integrating with service providers whose API shape is compatible with OpenAI. Many model platforms (including xAI) follow OpenAI's interface conventions in request and response structures, so there is no need to implement a provider from scratch; instead, they extend this compatibility layer. This means that the basic logic of the xAI provider—request construction, streaming parsing, error handling, and so on—is inherited from openai-compatible. When this upstream package changes version, the behavior of the xAI provider is affected accordingly, which is why this patch also upgrades @ai-sdk/openai-compatible to 1.0.62. Understanding this dependency relationship helps developers determine whether a problem lies in xAI-specific logic or the compatibility layer when troubleshooting missing request fields or response parsing exceptions.
Practical impact for developers
The most direct beneficiaries are teams that use the AI SDK as a unified integration layer while serving multiple model vendors. xAI's compliance capabilities previously required separate adaptation; now they are incorporated into the same provider configuration system, further reducing the cost of switching between multiple vendors.
Another layer of impact is observability. The echo on providerMetadata allows applications to cross-reference requests and responses in logs and monitoring, shortening the troubleshooting chain when the platform reports a violation. The value of this kind of metadata in diagnosing production issues is often more enduring than the feature itself.
One note: the source material does not specify the exact format constraints for this field, nor does it mention whether xAI imposes requirements on how the identifier is generated. Developers should consult the official documentation before launch to confirm the accepted value range, to avoid requests being rejected due to format mismatches.
One-line Summary
AI SDK adds a safetyIdentifier option for xAI, enabling user-level attribution of policy violations.
Paragraph Summary
Vercel's AI SDK has released @ai-sdk/xai version 2.0.103, adding a safetyIdentifier provider option to the Responses API. When enabled, the SDK sends the configured safety_identifier to xAI with the request, allowing the platform to attribute content policy violations to specific end users, and echoes the server-returned value at providerMetadata.xai.safetyIdentifier. This change lets multi-user applications integrate xAI's compliance attribution mechanism without hand-assembling HTTP requests, while also improving observability in logs and monitoring. The version also upgrades internal dependencies such as @ai-sdk/provider-utils and @ai-sdk/openai-compatible. The source material does not specify format constraints for the identifier, so consult the official documentation before launch to confirm the accepted value range.
Related articles
Tech FrontiersMuJoCo: An Analysis of DeepMind's Open-Source General-Purpose Physics Simulator
An in-depth analysis of Google DeepMind's open-source physics simulator MuJoCo: high-performance C++ kernel, MJCF modeling format, contact solving principles, MJX GPU acceleration, and robot reinforcement learning use cases.
Tech FrontiersClaude API Quick Start: The Official Quickstarts Project Collection
Anthropic's official claude-quickstarts project collection helps developers quickly build deployable apps with the Claude API. Nearly 20k stars, Python-based, great for beginners and prototyping.
Tech FrontiersAI Agents Connecting Directly to APIs: Which Calls Can Be Safely Allowed?
AI agents can call any API, but the real challenge is deciding which calls can be safely allowed. This article analyzes allowance decisions from three dimensions—intent matching, least privilege, and controllable impact—and argues that the control layer should sit outside the agent, combined with audit traceability to build a trustworthy API call governance mechanism.