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 one short classification call, free (no per-call charge; rate-limited by account tier), 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. OpenAI publishes no latency SLA or benchmark figure for the Moderation endpoint, so treat any single number you see quoted as unverified. What is structural: the request is one small classification call against a hosted model, with no retrieval and no generation, so it costs less than a generation call on the same stack, and running it asynchronously on outputs costs no user-visible time at all. Measure the synchronous path from your own region before you budget it.

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, with a separate illicit/violent flag for harm that involves weapons or violence

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:

• Scores are not comparable between categories, so a single global cutoff produces a different effective strictness in every one of them
• The high-severity categories (sexual content involving minors, the threatening variants of hate and harassment) are where a miss is least recoverable, which makes them the wrong place to relax a threshold
• The broad categories (harassment, violence, illicit) are where legitimate content clusters near the boundary: fiction, news reporting and harm-reduction writing all score above zero without being policy violations

That points to a defensible default: keep OpenAI’s thresholds on the high-severity categories (sexual content involving minors, imminent threats) and raise them on harassment, general violence and illicit 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 carries no per-call charge 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

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.