How Is OpenAI API Pricing Calculated and How Do You Estimate Your Cost?

OpenAI API pricing is calculated per token, with separate rates for input (prompt) tokens and output (completion) tokens, and the rate depends on which model you call. To estimate your cost, multiply your prompt tokens by the input rate and your completion tokens by the output rate, then scale that per-request figure by your expected request volume. This applies to any usage-based API billing; it does not cover flat-rate subscription products, which are priced differently.

The two-part token model

Every API call bills two quantities:

• Input tokens — everything you send: system prompt, conversation history, retrieved context, and the user message.
• Output tokens — everything the model generates back.

These carry different unit prices, and output is typically the more expensive side. A single request's cost is:

cost = (input_tokens × input_rate) + (output_tokens × output_rate)

Rates are quoted per token (often displayed per 1M tokens for readability), so divide the displayed price by 1,000,000 before multiplying.

Why the model tier matters more than anything else

Different model tiers carry different unit prices, and the gap between a small/cheap tier and a large/frontier tier is usually larger than any optimization you can make within one model. Choosing the tier is therefore the first cost decision, not a tuning detail. A model that is several times cheaper per token can still cost more overall if it needs longer prompts or produces longer answers to reach the same result — so compare on cost-per-completed-task, not cost-per-token alone.

Step-by-step cost estimate

1. Pick the model you intend to call. Note its input rate and output rate.
2. Measure a representative request. Count the tokens in a typical prompt (including system instructions and any context you inject) and the tokens in a typical response. Token counts are not the same as word counts — use a tokenizer or the API's own usage reporting rather than estimating from characters.
3. Compute the per-request cost with the formula above.
4. Multiply by volume. Daily requests × per-request cost = daily cost; multiply by ~30 for a monthly figure.
5. Add the parts people forget. Retries, failed calls that still consumed input tokens, multi-turn conversations where history is re-sent each turn, and any background jobs.

A worked example

Suppose a support assistant sends a 1,500-token prompt (system prompt + retrieved docs + question) and receives a 300-token answer, at 1,000 requests per day:

• Input: 1,500 × 1,000 = 1,500,000 tokens/day
• Output: 300 × 1,000 = 300,000 tokens/day

Apply each rate to its own total, then add. The important observation is structural: because the prompt is five times the answer, input pricing dominates this workload, even though output is priced higher per token. In chat or RAG systems with long context, that is the common pattern — which is why prompt trimming and context management often save more than switching models.

Billing modes that change the effective rate

Beyond the base per-token rates, some usage is billed at a reduced rate:

Both reduce the effective unit price for the tokens they cover, so a realistic estimate should separate "fresh" input, cached input, and output rather than applying one blended rate. Whether these modes are available, and at what discount, depends on the model and the current pricing page — check the provider's own documentation rather than assuming a fixed percentage.

Common estimation mistakes

• Counting words instead of tokens. Token counts vary by language and content type; code and non-English text often tokenize less efficiently.
• Ignoring conversation history. In multi-turn chat, each turn re-sends prior messages, so cost grows faster than linearly with conversation length.
• Forgetting retries and evaluation runs. Testing and prompt iteration consume real tokens.
• Assuming the cheapest model is the cheapest solution. A weaker model may need more retries or longer prompts.
• Treating a listed price as permanent. Rates and model lineups change; re-check before committing to a budget.

Using a comparison tool to sanity-check

A pricing calculator or model-comparison tool lets you enter token volumes and see costs side by side across models and providers, which is faster than recomputing by hand for each candidate. Countless.dev, for example, offers a pricing calculator and model comparison alongside versus and Pareto-frontier views — useful for narrowing candidates before you commit to one. Treat any third-party figure as a starting point: confirm the final rates against the provider's official pricing page, since aggregators can lag behind changes.

The practical workflow is: shortlist two or three models, estimate cost-per-completed-task for each using your own token measurements, then verify the winning estimate against real usage after a small pilot.