Token & Cost Estimator

A single Codex or API request's cost comes down to four numbers multiplied against each other: how many input tokens you sent, how many output tokens came back, which model answered, and which service tier you called it under. This estimator does that arithmetic against OpenAI's real published price bands, correctly, including the one part that's easy to get wrong by hand.

The part that's easy to get wrong

OpenAI prices requests over a published input-token threshold differently — and the important detail, easy to miss on a quick read of the pricing page, is that crossing that threshold reprices the entire request, input and output both, not just the portion of the input above the line. A naive spreadsheet that applies the higher rate only to the "extra" tokens will understate the bill on every long request that crosses it. This estimator applies the correct rule and tells you plainly when a request you priced has crossed it.

What "service tier" changes

Standard, Batch, Flex and Fast are not four unrelated price lists — Batch and Flex are priced identically to each other for text models (the difference between them is delivery guarantees, not price), Fast costs a real premium for lower latency, and Fast mode isn't even offered for every model. Picking the wrong tier for the comparison you're trying to make will make two genuinely different-priced options look artificially close, or an actual saving look smaller than it is.

Caching isn't modelled as free

Where a model publishes a cached-input rate, this estimator does not assume you're hitting the cache unless you actually tell it to — a request with zero cache hits and a request where every eligible token hit a warm cache are two different bills, and conflating them is one of the more common ways a cost estimate turns out wrong in practice. If a model or service tier doesn't publish a given price at all — a cache-write rate, for instance — this tool says so explicitly and falls back to the most conservative honest number available, rather than silently treating an unpublished price as free.

Turning a per-request estimate into a monthly one

Multiplying a single request's cost by how many times you actually expect to run it is the single most common source of budgeting surprises — not because the arithmetic is hard, but because "how many times a day" is usually a guess made once and never revisited as usage patterns change. This estimator does the daily and monthly projection for you from a runs-per-day figure you supply, specifically so that number stays visible and easy to challenge rather than buried in a spreadsheet formula nobody remembers writing.

What this tool is not

It is not the authoritative count of what a real request actually cost. The usage object the API itself returns on every response is that authority — this tool is a planning aid for before you've made the call, not a substitute for reading the real number after you have.

Where the token counts themselves come from

This estimator takes token counts as an input rather than counting them for you from a pasted prompt, and that's a deliberate scope decision, not a missing feature. Token counting is model-specific — the same text produces a different count on different model generations, and the only source that is always correct is the API's own counting endpoint, run against the exact model you intend to call. Estimating from character or word counts is a reasonable starting point for a rough plan, but it should never be the number you commit a budget to; treat whatever you type into the input-token field here as a planning figure you'll firm up before it matters.

Reading the long-context warning correctly

When a request you've priced crosses the published long-context threshold, this tool doesn't just apply the higher rate silently — it tells you explicitly that the crossing happened, because that's the single easiest thing to miss when you're iterating on a token count and watching a total change. A jump in the total that looks disproportionate to the token increase you just made is almost always this threshold, not a bug in the arithmetic; the warning exists so you don't have to work that out by hand every time.

Why runs-per-day is a separate field from the per-request numbers

Keeping the daily multiplier separate from the token counts, rather than asking for a single "monthly budget" number up front, is meant to make the two different kinds of uncertainty visible separately. You usually know your per-request shape — roughly how much context a typical call sends and how long a typical answer runs — with reasonable confidence. How many times a day you'll actually call it is a much softer number, and conflating the two hides which one you should be more careful estimating.