OpenAI Moderation API Pricing: Free Endpoint, Separate Operating Costs

OpenAI states that its Moderation API endpoint is free to use. The official moderation guide also says omni-moderation-latest accepts text and image inputs, with image files up to 20 MB, while audio sits outside that model's input scope. Pricing the endpoint takes one line. Calculating the operating cost requires generation and orchestration on the application's bill, plus human review and the storage of policy evidence.

I would reject a forecast that puts $0 beside the whole moderation function. It confuses one vendor line item with the system that acts on the result.

TL;DR

• OpenAI documents the Moderation API endpoint as free to use.
• omni-moderation-latest classifies text and images; the guide lists a 20 MB image limit and excludes audio.
• Model generation and application compute remain separate costs. So do review queues and storage. Retries remain separate as well.
• OpenAI's harm categories supply a safety signal. Enterprise authorization still needs identity and data context. It also needs destination and policy context.

The endpoint price is zero

The direct OpenAI charge for a call to the moderation endpoint is $0 under the published documentation available on 11 October 2026. OpenAI's model page for omni-moderation describes moderation models as free models designed to detect harmful content. The guide explains that applications can classify standalone inputs or request moderation scores beside a generated response.

A request sent only to the moderation endpoint carries no moderation-model fee. If the application also sends a prompt to a paid generation model, the generation request follows that model's price schedule. Image ingestion and network egress are deployment costs. So are queue workers and API gateway capacity, along with logging and retained evidence.

Put both records on the monthly cost sheet. One row should show zero-dollar moderation calls and request volume. Another should show paid model usage and the infrastructure that surrounded those calls. Mixing them produces a blended figure that nobody can reconcile when traffic changes.

Workflow design changes the operating cost

OpenAI documents several moderation workflows. An application can inspect generated content or classify standalone text. It can also classify a standalone image or consume moderation results with flags and categories, plus scores and applied input types.

Input screening before generation can avoid a paid generation call when the application blocks a request. Output screening happens after generation, so the paid model work has already occurred. A review queue adds analyst time when a policy routes uncertain or high-risk cases to a person. Retries add network and orchestration activity even when the moderation call itself remains free.

The physical test is a trace on one screen and the cloud invoice on another. Follow request mod-18427 through input screening and generation. Then follow its output screening and any review event. The endpoint ledger may show $0 for two moderation calls while the adjacent generation and queue records carry the actual spend. Model routing cost optimization should preserve that distinction.

Categories and scores need a local decision

The Moderation API returns provider-defined harm signals. OpenAI's guide lists categories covering areas such as harassment and hate. It also covers self-harm and sexual content. Violence appears there too, with category flags and scores that an application can use. The API supplies classification data. The application still decides what happens next. It can allow or block the request. Account restrictions and reviewer escalation remain application decisions as well.

That decision deserves a versioned policy. A consumer discussion forum may route one result to a reviewer. A clinical support application may apply a different handling rule to the same category because its user population and escalation process differ. The moderation score alone cannot identify an employee's role or the contractual status of source code. It also cannot identify the approved model destination.

My view is that score thresholds hidden in application code are policy debt. Put the threshold and action in a record that security can test. Record the owner, exception path, and review date there too. The model guardrails article explains the broader distinction between a model-side safety signal and an externally governed enterprise decision.

Budget the system around the API

A practical cost model separates six components.

• Moderation endpoint: zero-dollar OpenAI API charge under the cited documentation, measured by call volume and input type.
• Generation: paid input and output usage for the selected generation model.
• Application runtime: workers and queues used to submit and process decisions. Network paths and storage belong here too.
• Human review: analyst time and escalation coverage. Quality checks for queued cases belong here too.
• Evidence: retained request identifiers and category results. Keep policy versions and outcomes, along with review records.
• Evaluation: labeled test cases used to measure false positives and false negatives. They also measure policy changes before release.

The line items move independently. A stricter threshold may raise review volume without changing the endpoint charge. Input moderation may reduce paid generation calls. Longer evidence retention can increase storage. A new image workflow can change payload and network costs while the moderation request remains free.

Budget owners should record assumptions beside each line. Call volume and generation model are more useful than one blended figure called content safety. So are review rate and retention period. Test cadence should also appear on the sheet.

Enterprise policy is a complementary control

OpenAI moderation evaluates content against OpenAI's categories. Enterprise policy answers a different set of questions for authenticated HTTP model traffic. Identity and role context show which user or agent sent the request. Prompt inspection checks the data classes against the approved LLM destination, while the decision record preserves the policy version applied at that moment.

The two controls can run on the same request path. OpenAI moderation contributes a provider-defined harm signal. An identity-aware policy point can use local classifications and routing rules before forwarding traffic, then retain a decision record. AI policy enforcement at the HTTP layer covers that architecture.

This policy point sees traffic deliberately routed through it between an authenticated user or agent and an LLM endpoint. It leaves local inference and direct browser sessions outside the route to other controls. Endpoint compromise and stolen credentials also remain with other controls. OpenAI also directs organizations handling known or suspected child sexual abuse material to dedicated child-safety safeguards rather than this API.

DeepInspect

DeepInspect complements OpenAI moderation on authenticated user or agent traffic deliberately routed to an HTTP LLM endpoint. It evaluates application-supplied identity and role before the request proceeds. It also evaluates request classification and model destination against versioned organizational policy. The result becomes a signed, tamper-evident per-decision record.

OpenAI remains the authority for its moderation categories and scores. It also remains the authority for model behavior and endpoint limits. Its published price remains authoritative. DeepInspect adds the enterprise authorization decision and evidence for the routed request. Book a technical deep dive at deepinspect.ai.