Strategy guide

How to reduce OpenAI API costs

The concrete levers for cutting an OpenAI bill — prompt caching, the Batch API, output caps, and model choice.

If an OpenAI bill is running higher than it should, the fixes below are the ones OpenAI itself publishes a discount or a mechanism for — not general belt-tightening advice.

Prompt caching discounts cached input tokens automatically

OpenAI applies a steep discount — roughly a 90% reduction versus the standard input rate on its current models — to input tokens that repeat, prefix-for-prefix, from a previous call, once the shared prefix clears a minimum length (around 1,000–2,000 tokens depending on the model). There's no extra parameter to opt in; the win comes from structuring the prompt so the static portion — system instructions, tool schemas, shared context — comes first and stays byte-identical across calls, with the request-specific content appended after it. A cache entry only survives for a limited window after its last use, so bursty or infrequent traffic to the same prompt shape won't benefit as much as steady, frequent traffic will.

The Batch API cuts anything non-interactive in half

A flat 50% discount applies to input and output tokens on batch requests, across most endpoints — chat completions, embeddings, moderations, image generation among them — with results typically returned within 24 hours, often faster. The trade is no streaming and no real-time response, so it fits evals, bulk classification, backfilling historical data, and any job that doesn't have a human waiting on the other end. Each batch caps at 50,000 requests or 200 MB, so very large jobs need to be split.

Reasoning tokens are invisible but billed as output

A reasoning model's internal reasoning tokens never appear in the response text, but OpenAI bills them as output tokens — the pricier side of every call. A harder prompt, or a higher reasoning-effort setting, can pull in far more reasoning than a simpler one without the visible answer looking any different, and the invoice reflects the difference either way. Setting reasoning effort deliberately, and capping max output tokens, bounds this directly instead of leaving it to whatever the model decides a given prompt warrants.

Not every request needs your most expensive model

OpenAI's smaller, cheaper model tiers cost a fraction per token of the flagship line and handle classification, extraction, short-form generation, and other bounded tasks perfectly well. Routing the easy majority of requests to a cheap tier and reserving the flagship model for genuinely hard prompts usually cuts blended spend more than any other single change, and it's a routing decision, not a quality compromise, when the task actually fits the cheaper tier.

Retries after a 429 are a quiet cost leak

An aggressive retry loop that doesn't honor OpenAI's Retry-After header can resend, and pay for, the same logical request more than once — see our guide on fixing an OpenAI 429 error for the full breakdown. Fixing retry behavior isn't a pricing lever exactly, but it removes cost that was never supposed to be there in the first place.

See the current verified OpenAI price, full history, and forecast on the OpenAI pricing calculator, and add a free watch so the next change reaches you before your invoice does.

Frequently asked questions