Short answer: for messy product descriptions, treat moderation as a versioned classification contract, not as a vendor-shaped function call. A small chat model returning a strict JSON object is the practical fallback when a dedicated moderation endpoint is absent; the useful cost comparison is the total cost per tenant, including retries, review queues, and the data needed to explain a decision.

The application should therefore own the decision boundary. It sends a normalized description to a moderation adapter, records the tenant, model route, request identifier, token or usage metadata, and schema version, then stores the result as an auditable event. That design keeps a later move to a specialist moderation service possible.…