AI SDK xAI 3.0.151 Update: Adds safetyIdentifier Option

AI SDK xAI provider 3.0.151 adds safetyIdentifier option for policy violation attribution to end users.
The AI SDK xAI provider releases patch 3.0.151, introducing the `safetyIdentifier` option. Developers can attach a `safety_identifier` field when calling xAI's Responses API, enabling xAI to attribute policy violations to specific end users rather than only seeing API Key-level records. The identifier is echoed via `providerMetadata.xai.safetyIdentifier` for logging, auditing, and debugging. Dependencies are also updated: `@ai-sdk/provider-utils` to 4.0.65 and `@ai-sdk/openai-compatible` to 2.0.92. Positioned as compliance and operations infrastructure, it suits multi-user apps but is less valuable for internal tools.
Title
AI SDK xAI 3.0.151 Update: Adds safetyIdentifier Option
Meta Description
The AI SDK xAI provider releases patch version 3.0.151, adding a safetyIdentifier option that carries an end-user identifier in Responses API requests, helping xAI attribute policy violations and echoing it back in providerMetadata.
Article Content
The AI SDK's xAI provider has released a patch version, 3.0.151. Though the version bump is minor, it introduces a noteworthy compliance feature: safetyIdentifier. This option lets developers attach an identifier when calling xAI's Responses API, helping xAI pinpoint the specific end user when a policy violation occurs.

New safetyIdentifier: Tying Compliance Responsibility to Specific Users
According to the release notes on GitHub, the core of this update is a feature commit (7957cfa): feat(xai): add safetyIdentifier Responses provider option. This option sends the safety_identifier field along with requests to xAI's Responses API. This allows xAI to attribute a policy violation to a specific end user, rather than only seeing generic call records.
For teams building multi-user AI applications, this solves a real problem: when a platform needs to cooperate with content safety reviews or handle abuse complaints, API Key-level logs alone make it hard to distinguish which user triggered the issue. safetyIdentifier provides a standardized way to pass this information, enabling attribution on the provider side.
Echoed in the Response for Easy Verification
Besides sending, this option also exposes the echoed value on providerMetadata.xai.safetyIdentifier. This means developers can read the identifier carried in the request directly from the metadata after receiving a response, for logging, audit verification, or debugging. Sending and echoing form a closed loop, reducing the risk of mismatches during troubleshooting.
AI SDK is an open-source TypeScript toolkit from Vercel for uniformly accessing the APIs of multiple large model providers, offering capabilities like streaming responses, tool calls, and structured output. It uses a "provider" abstraction: the core package defines a unified interface, and each model is integrated through a separate provider package, such as @ai-sdk/xai, @ai-sdk/openai, and @ai-sdk/anthropic. When switching models, developers typically only need to replace the provider instance and model identifier, leaving business code largely unchanged. @ai-sdk/openai-compatible is a general adapter layer that lets any service mimicking the interface shape of OpenAI Chat Completions or Responses API integrate in a unified way—xAI connects through this compatibility layer.
xAI's Responses API is its interface for dialogue and generation tasks, with naming and request/response structures borrowing from OpenAI's Responses API design, supporting passing call context through additional metadata fields. safety_identifier is an optional field in the request body, whose value is delivered to the provider side with the request for attribution in content safety events.
providerMetadata is a unified convention of AI SDK: different providers can attach their own specific fields to the response object without polluting the SDK's generic return structure. Callers access additional information returned by the original vendor via providerMetadata.<providerName>, such as request IDs, usage breakdowns, content filtering results, and more. The value of this design is that the SDK shields differences between vendors while preserving a channel to access raw metadata, facilitating auditing, billing, and troubleshooting. providerMetadata.xai.safetyIdentifier follows this convention, returning the identifier carried in the request back to the caller.
It's important to distinguish that echoing only proves the identifier was correctly passed and stored; it does not mean the provider has completed any policy determination. Whether attribution takes effect depends on whether xAI actually uses this field in its violation handling process.
Dependencies Synchronized
The patch notes also list dependency updates (f0dee4b): @ai-sdk/provider-utils bumped to 4.0.65, and @ai-sdk/openai-compatible bumped to 2.0.92. Such dependency synchronization alongside version progression is routine maintenance, but it's worth noting the version change of the openai-compatible package—xAI's interface is designed to align with the OpenAI-compatible ecosystem, and this dependency update may indirectly affect the behavior of the compatibility layer.
Practical Impact on Developers
From a functional standpoint, safetyIdentifier is not a capability that changes model output quality, but rather infrastructure for compliance and operations. If your application is open to end users and needs to meet traceability requirements for content safety, this option is worth including in request parameters. Conversely, for internal tools or single-user scenarios, its value is relatively limited.
Note that the attribution effect of this field depends on how xAI uses this identifier; the release notes only describe the sending and echoing mechanism and do not elaborate on specific policy enforcement details. Developers should refer to official documentation when integrating to confirm the identifier's format requirements and privacy compliance boundaries—after all, passing user identifiers to third-party services itself needs to be accounted for in privacy policies.
Summary
3.0.151 is a minor release focused on compliance capabilities: it adds the safetyIdentifier option, allowing Responses API requests to carry an end-user identifier and echo it in metadata, while also synchronizing dependency versions for provider-utils and openai-compatible. For multi-user applications requiring content safety attribution, this is a practical addition.
One-line Summary
The AI SDK xAI provider 3.0.151 adds a safetyIdentifier option, enabling policy violation attribution to end users.
Paragraph Summary
The AI SDK xAI provider releases patch version 3.0.151, with the core change being the new safetyIdentifier option. Developers can attach a safety_identifier field when calling xAI's Responses API, enabling xAI to attribute issues to specific end users during policy violations rather than only seeing API Key-level generic records. The identifier is also echoed in the response via providerMetadata.xai.safetyIdentifier, facilitating logging, audit verification, and debugging. Additionally, this update synchronizes dependency versions: @ai-sdk/provider-utils bumped to 4.0.65, and @ai-sdk/openai-compatible bumped to 2.0.92. This feature is positioned as compliance and operations infrastructure, suitable for multi-user applications open to end users, with limited value for internal tools or single-user scenarios.
Related articles
Tech FrontiersPushing the Limits of Extreme Sudoku on a 16GB GPU: Insights from Depth and Flow Matching
A researcher trained a 16.54M-parameter model on a 16GB GPU to solve extreme Sudoku, finding effective depth breaks the 60% plateau and flow matching with improved sampling pushes accuracy past 99% with ~50× lower layer-evaluation budget.
Tech FrontiersAI Agent Approval Workflows: Why Human Confirmations Always Get Mindlessly Clicked
Why do AI agent approval workflows always get mindlessly clicked? A Reddit discussion shows that separating rules from keys, low-frequency high-risk approvals, and GitHub Environments-style gates are the keys to effective approvals.
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.