xAI Adds a Guidelines Option to the Grok API So Developers Can Tune How It Handles Sensitive Content
You can now add `guidelines` to text API requests to further moderate how the Grok API handles specific content categories. Grok follows the guidelines as it writes its response, in its own words. Available to all API customers.
Context
It gives developers a per request switch for how strictly Grok treats categories like adult content, violence and profanity, instead of relying on one fixed policy for every app.
Grok is the model family from xAI, sold to developers through its API. Content moderation in AI APIs is usually set by the provider for all customers. xAI's documentation describes guidelines as a list sent with each request that names a category, such as nsfw, violence or profanity, and a behavior, currently only decline.
Deep dive
The Grok account said on Wednesday night that developers can now add guidelines to text API requests to further moderate how the Grok API handles specific content categories. According to the post, Grok follows the guidelines as it writes its response, in its own words, rather than cutting off output, and the feature is available to all API customers.
The image in the post shows a code sample where a request asks Grok to roast a brother for his 30th birthday while a guideline declines profanity. The resulting roast is teasing but clean.
xAI's documentation describes guidelines as a list attached to Chat Completions or Responses API requests. Each entry names a category, currently nsfw, violence or profanity, and a behavior, currently only decline. The docs say guidelines apply per request, so apps need to send them on every turn of a conversation, and they are not supported with multi agent models or deferred completions.
This is a developer control rather than a new model, but it addresses a common request from businesses that want Grok's capabilities with stricter content rules for their own users.
What to expect next
Watch whether xAI adds more categories and behaviors beyond decline, such as softening or warning, and whether developers find the in model approach more reliable than separate filters. Businesses building for younger users or regulated industries are the likely first adopters. Other model providers may offer similar per request controls if the feature proves popular. Clear documentation of edge cases will help teams trust it in production.