OpenAI Moderation API Review: What It Catches and Misses

The OpenAI Moderation API is the default content-moderation choice for teams already building on GPT-4o or GPT-3.5: it is fast (~20ms typical), free with API credits, and takes four lines of code to integrate. The current model, omni-moderation-latest, is built on GPT-4o and accepts both text and images. That convenience is real — and so are its limits.

This review is the honest assessment: where the OpenAI Moderation API genuinely earns its place, and the predictable gaps (obfuscated text, multi-turn context, customization) that mean it is rarely the whole answer for a serious moderation stack. For the field-by-field reference — every category, which ones accept images, and how to read the score object — see the omni-moderation API guide.

What it does well

Latency. The Moderation API is fast. At 15-25ms typical latency, it adds negligible overhead when run synchronously on user inputs. For output classification, async operation means it adds zero user-visible latency. This is the best latency profile in the category.

Category breadth. The current model (omni-moderation-2024-09-26) covers a reasonable taxonomy:

• Harassment (with/without threat)
• Hate (with/without threat)
• Self-harm (intent, instructions, ideation)
• Sexual (general, minors)
• Violence (graphic/non-graphic)
• Illicit (firearms, drugs — separate categories)

The subcategory structure is useful. “Sexual content” and “sexual content involving minors” warrant different business responses; having separate classification flags makes threshold calibration easier. The full thirteen-category breakdown also records which categories are evaluated for image input and which return zero on an image, a distinction that decides whether an all-zero response means “clean” or “not checked”.

Ease of integration. Four lines of Python. If you’re already using the openai library, there’s essentially no integration overhead:

from openai import OpenAI
client = OpenAI()

response = client.moderations.create(
    model="omni-moderation-latest",
    input=user_message
)
flagged = response.results[0].flagged
categories = response.results[0].categories
scores = response.results[0].category_scores

Image moderation. The omni-moderation model is multimodal: it can take image inputs, not just text. Per OpenAI’s documentation the image path covers a subset of categories — violence, self-harm, and sexual content are evaluated for images, while harassment, hate, and illicit are text-only. That makes it a reasonable first pass for user-uploaded images in those three high-risk categories, but it is not a full image and video moderation tool and won’t catch every visual harm class.

Multilingual reach. The 2024-09-26 omni model was a meaningful step up on non-English content versus the older text-moderation models, with OpenAI reporting broad gains across the languages it tested. It is genuinely usable for the major European languages. That said, “improved” is not “solved” — lower-resource languages still lag, which is why the multilingual caveat below matters.

Where it falls short

Coverage on obfuscated and encoded content. The OpenAI Moderation API operates on the text you send it. If that text is Base64-encoded, ROT13’d, or obfuscated with zero-width characters, the moderation model performs poorly. There’s no built-in normalization layer.

Non-English language performance. Coverage is better than most alternatives for major languages (French, Spanish, German, Portuguese), but performance on less-supported languages is significantly degraded. If you have significant traffic from users writing in Arabic, Hindi, or smaller language communities, measure performance explicitly before relying on the API.

Context-free classification. The API classifies single messages in isolation. It doesn’t have memory of prior conversation turns. A jailbreak spread across multiple turns — innocuous individually, harmful in combination — won’t be caught by per-message classification. The same blind spot applies to instructions smuggled in through retrieved documents or tool output: the taxonomy scores harm, not provenance, so catching that class needs a dedicated layer from the prompt injection detection tools evaluated separately.

Lack of customization. You cannot add custom harm categories or adjust the model’s training distribution. If your application has domain-specific risks (financial advice, medical content, legal advice) that don’t map cleanly to the standard taxonomy, you’re adding a second classification layer anyway.

Opacity on borderline cases. The score output gives you a confidence score, but no explanation. When content is flagged at 0.45 (borderline), there’s no mechanism to understand why. Manual review lacks the information to make good decisions.

Threshold calibration in practice

The default behavior uses OpenAI’s internal thresholds. The raw scores give you the ability to set your own thresholds. In practice:

• Sexual content default threshold is conservative — legitimate romantic fiction is frequently flagged
• Violence threshold is calibrated for general consumer use — news content discussing violence occasionally trips it
• The drug and firearms categories tend to produce the most useful flagging in community platform contexts

A common production calibration keeps OpenAI’s defaults for the high-severity categories (sexual content involving minors, imminent threats) and raise thresholds significantly for harassment, general violence, and drug/firearms categories to reduce false positives on legitimate content. The mechanics of doing that properly — per-category cutoffs, a three-band allow/review/block routing, and why scores are not comparable between categories — are set out in how to set omni-moderation thresholds.

The vendor lock-in question

The Moderation API is free with OpenAI usage but creates architectural dependency on OpenAI’s API. Teams that want to switch LLM providers or run air-gapped deployments need to replace this too.

If architectural independence matters, Llama Guard is the portable alternative. If you’re deeply committed to OpenAI for the foreseeable future and latency matters, the OpenAI Moderation API is hard to beat on the operations side. And if your real blocker is the lack of custom categories, the more durable fix is usually a purpose-built classifier — see fine-tuned classifiers vs moderation APIs for when that tradeoff pays off.

Comparing to the alternatives

Dimension	OpenAI Moderation API	Llama Guard 3 8B	Perspective API
Latency (p99)	~25ms	100-200ms self-hosted	~30ms
Cost	Free with OpenAI credits	Self-hosting cost	Free (limited)
Custom categories	No	Via fine-tuning	No
Context window	Single message	Single message	Single message
Multilingual	Good for major languages	English-primary	Good for toxicity
Image input	Subset of categories	No — needs the 11B Vision variant	No
Custom policy fit	Fixed 13-category taxonomy	Editable taxonomy in the prompt	Fixed 8 attributes
Best fit	LLM input/output filtering on an OpenAI stack	Portable, self-hosted LLM safety	Community comment toxicity

Read that table as a placement guide rather than a ranking: the Perspective API review and the Llama Guard benchmark review cover why each one wins its own row. None of the three scores factuality, so a stack that also needs to catch confident fabrications adds a hallucination detection tool alongside them rather than tuning a harm classifier to do a job it has no category for.

For a deeper comparison of how these tools compare on specific harm categories with numbers, aisecreviews.com publishes comparative data across the content moderation tool landscape.