Summary: xAI’s October release notes introduced custom moderation controls: a guidelines array you can attach to any Chat Completions or Responses API request to tighten how Grok handles nsfw, violence, and profanity content. It’s per-request, not per-account, which changes how you architect guardrails for multi-tenant products. The implementation has a few sharp edges worth knowing before you ship it.
What the guidelines array actually does
Each entry has three fields: type (always "policy"), a category, and a behavior. Today the only behavior is decline. When you set it, Grok follows the guideline while writing its response — in its own words, not via a post-hoc filter. A knight story request with violence and nsfw set to decline comes back as the same response shape, just written within those constraints.
The scope rules matter more than the syntax. Categories you leave out keep the model’s default moderation behavior, so you only opt into stricter handling where your product needs it. And guidelines apply only to the request carrying them — for a full conversation, you send them on every request. In the xAI Python SDK, chat.create stores them on the chat so every sample call sends them automatically.
How to wire it up
If you’re on the OpenAI SDKs, guidelines isn’t a defined field, so you pass it through. In Python that means extra_body; the JavaScript SDK sends it alongside the other parameters. On Chat Completions it sits as a top-level field at the same level as messages.
curl https://api.x.ai/v1/responses \
-H "Authorization: Bearer $XAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "grok-4.7",
"input": "Write a short story about a knight.",
"guidelines": [
{ "type": "policy", "category": "violence", "behavior": "decline" },
{ "type": "policy", "category": "nsfw", "behavior": "decline" }
]
}'The behaviors are scoped sensibly: nsfw still answers educational and clinical questions, violence still engages with history and news without graphic detail. xAI notes it may refine the details over time, so treat the table as a high-level contract, not a spec.
The constraints to plan around
Several request shapes are rejected with a 400 before the model runs: multi-agent models like grok-4.20-multi-agent, deferred completions, and simple requests (no server-side tools, no file attachments) that set stop or n greater than 1. If your product uses those options, you’ll need a fallback path.
Validation errors are predictable: 422 for unknown category or behavior values, 400 for duplicate categories or a type that isn’t "policy". The xAI Python SDK raises ValueError client-side for unknown values before anything hits the wire. Since the API validates before running the model, a bad guidelines payload never costs you inference tokens.
Why per-request matters
Most moderation layers are workspace-wide. Per-request guidelines let one API key serve tenants with different content policies — a kids’ education app and an adult-audience product on the same infrastructure. That’s a real architectural simplification.
It also pairs naturally with the safety_identifier field xAI added in September, which attributes policy violations to individual end users rather than your API key. Stricter per-request rules plus user-level attribution gives you both prevention and accountability. This release note also shows how much rides on xAI’s changelog discipline — I covered the Grok Voice 3.0 swap in the same release notes, and reading them consistently is how you catch these changes early.
One limitation to flag: decline is currently the only behavior. If you need softer handling — rewrite instead of refuse — that’s not on offer yet. For now, this is a tightening knob, not a tuning dial.
Sources
View the original post on X