gpt-oss-safeguard-20b: Moderation From a Policy You Write

A traditional moderation classifier bakes its policy into its weights. Change what counts as harassment on your platform and you need new labelled data, a new training run and a new deployment. gpt-oss-safeguard-20b takes the opposite approach: you hand it the policy as text alongside the content, and it reasons its way to a decision.

That makes it a different kind of tool from a general chat model and a different kind from a classic classifier. It is slower and more expensive per item than the second and far more specialised than the first. Used in the right place, it removes the retraining loop from policy changes entirely.

What OpenAI released

OpenAI released gpt-oss-safeguard on 29 October 2025 as a research preview, in two sizes: 120b and 20b. Both are fine-tuned from the gpt-oss open models and both ship under Apache 2.0. The release was developed with ROOST (Robust Open Online Safety Tools), together with Discord and SafetyKit.

The 20b model inherits its base model's shape: about 21B total parameters and 3.6B active, fitting in GPUs with 16GB of VRAM according to the Hugging Face model card. The gpt-oss-20b guide covers that base model; the safeguard variant is the same architecture pointed at one job.

The model card is explicit about scope. It is meant for safety work: input and output filtering, online content labelling and offline trust-and-safety labelling. For anything else OpenAI recommends the general gpt-oss models instead.

Policy as prompt

The input is two things: a policy and a piece of content. The output is a decision and the reasoning behind it. Because the policy arrives at inference time, you can revise a definition in the morning and have it enforced in the afternoon, and you can run two versions side by side to see which one draws the line where you want it.

OpenAI's prompting guide for the model is specific about what a good policy looks like. Structure it like a trust-and-safety handbook, in four parts:

1. Instructions — what the model must do and the exact output format.
2. Definitions — the terms the policy depends on.
3. Criteria — what violates and what does not, stated without hedging words like "generally" or "usually".
4. Examples — cases near the decision boundary, both violating and non-violating.

The guide also recommends repeating the output instructions near the top and again before the examples, stating precedence when policies conflict, and giving an escalation path for genuinely ambiguous cases.

Length matters. OpenAI's early testing suggests 400 to 600 tokens is the sweet spot, with policies up to about 10,000 tokens still producing reasonable output. For multi-category policies the guide suggests compressing each category to 300 to 600 tokens with one or two examples each way, and warns that stacking more policies into one prompt causes small but meaningful accuracy drops.

Choosing an output format

The guide describes three output shapes, and the choice is a trade between speed and auditability:

• Binary — a single 0 or 1. Fastest, but it throws away the reasoning that is the model's main advantage.
• Policy-referencing — JSON with a violation flag and a category ID. Concise, and tells you which rule fired.
• With rationale — JSON with category, rule IDs, confidence and a short justification. The most useful for review queues and audits.

Two settings interact with that choice. Reasoning effort is set to low, medium or high in the system message, with medium as the default; higher effort copes better with many policy sections and rule interactions. And the guide says not to cap output tokens tightly, because the model needs room to reason before it answers. Like its base model, it must be served with the harmony response format, which keeps the reasoning in a separate channel from the final verdict.

Where a classifier still wins

OpenAI does not pitch this as a replacement for everything. Its own guidance says a traditional classifier trained on thousands of labelled examples will often outperform gpt-oss-safeguard on that specific task, at lower latency and lower cost per item. The technical report makes the same point about some complex risk areas.

So the honest positioning is narrower. gpt-oss-safeguard is strongest when:

• the policy is new or changing faster than you can label data for it;
• the harm is nuanced and context-dependent, so a keyword or embedding model struggles;
• you need a written reason for each decision, for appeals or for regulators;
• volume is low enough, or pre-filtered enough, that per-item reasoning cost is acceptable.

If your policy is stable and you already have a large labelled set, train a classifier. If you are comparing against other open safety models, Llama Guard 4 12B takes a fixed-taxonomy approach that is worth testing against your data.

A deployment pattern that keeps latency down

Running a reasoning model on every message is expensive. OpenAI describes its own approach: small, high-recall classifiers find content that might be relevant to a domain, and only that content is sent to the reasoning model. ROOST's Osprey rules engine follows the same idea, calling gpt-oss-safeguard as a plugin only for ambiguous events and logging the rule that triggered the call, the returned category and the rationale.

In practice that gives you three tiers: cheap filters that clear the obvious majority, gpt-oss-safeguard for the grey zone, and human review for what it flags as uncertain. If you would rather not host it, the 20b model is listed on OpenRouter at $0.075 input and $0.30 output per million tokens at the time of writing, though many trust-and-safety teams will want it on their own hardware for data-handling reasons.

How to roll out a policy safely

Treat each policy as code with a test suite. Before a revision goes live:

1. Assemble a labelled set of a few hundred real items, weighted towards boundary cases.
2. Run the current and revised policy against it and diff the decisions, not just the accuracy.
3. Read every item that flipped. That is where a reworded definition changed the line.
4. Check that the rationales cite the rules you expect; a correct verdict for the wrong reason will not generalise.

Evaluating prompt changes covers the mechanics. The point is that a policy-as-prompt model makes changes cheap to deploy, which makes it easy to deploy a bad one. The test set is what stops that.