Price a prompt on every model.
Paste a prompt, a document, or a code file. The token counter is built in: your text is counted as you type and priced across every current first-party model at your scale, with caching and batch discounts applied. Computed in your browser from published on-demand rates; nothing you paste leaves your device.
Monthly cost comparison
Stacked input cost (after caching) and output cost for your current scenario.
Full cost breakdown (cheapest first)
| # | Model | Provider | $ / 1M in | $ / 1M out | Monthly cost |
|---|
Estimates only. Rates sync from public pricing data and may lag official changes; confirm on each provider's pricing page. "Try" links go straight to the provider: we have no affiliate or referral arrangements, and nothing on this page is paid placement.
Compare vs. self-hosting your own GPUs (for CTOs weighing API vs. dedicated hardware) ▾
Open-weight models only (you cannot self-host GPT-5, Claude, or Gemini). Excludes engineering, ops, and reliability, which managed APIs include. Rough estimate; hardware throughput varies widely by model size and batching.
Recent calculations (saved on this device only) ▾
Get on the list for a heads-up when OpenAI, Claude, or DeepSeek slash API prices. No spam, unsubscribe anytime.
Check your inbox and click the confirmation link to finish subscribing.
How it prices your workload
Token counts are estimated at roughly four characters per token, which lands within about ten to fifteen percent of the providers' own tokenizers for English text. Rates sync on load from public pricing data, and every figure states its snapshot date. The ranking is computed purely from cost: no affiliate deals, no paid placement.
Answering a question about a project rather than a prompt? The project estimator prices a workload from plain answers, no tokens required. Trying to shrink the prompt itself? The prompt optimizer strips filler and reorders it so caching can bite.
The number that decides your bill is not the one you pasted
A prompt priced on its own almost always comes out cheaper than the same prompt in production, and the gap is not small. What you paste is one message. What you send is the system prompt, the tool and function schemas, any retrieved documents, and every earlier turn of the conversation, all of it re-sent on every single call because the API is stateless and has no memory of the last one. A chat that feels like twenty short messages is twenty calls whose input grows each time, and the last one carries all nineteen that came before it.
That is why the multiplier field matters more than it looks. Set it to the number of calls you expect rather than the number of user actions, and if your workload is conversational, paste a realistic full context rather than a single question. Getting that input right moves the answer more than choosing between two adjacent models does.
Where the two discounts apply, and where they do not
Caching discounts the part of your input that repeats byte for byte from one call to the next, and only from the start of the prompt. Move one character near the top and everything after it is a cache miss, which is why the ordering of a prompt has a price and not just a style. Caching never touches output, so a workload that writes long answers cannot be cached out of its bill. Batch pricing does the opposite: it discounts the whole call, input and output alike, in exchange for giving up any expectation about when the answer arrives. It suits overnight and backfill work and is useless for anything a person is waiting on.
Both are applied here exactly as the providers publish them, and the batch discount is a switch rather than an assumption, because it costs you something real in return. Leave it off unless the work genuinely can wait, and read the two answers as what the same workload costs under two different service levels rather than as one number and a better one.
How wrong this can be
Token counts here are estimated from character length, which lands within roughly ten to fifteen percent of the providers' own tokenizers on ordinary English prose. It is less accurate on source code, on JSON and other punctuation-dense text, and on languages that do not use the Latin alphabet, where a single character can cost a whole token and the estimate can run well under the truth. The rates themselves are not estimated: every one was observed in a dated capture. So treat the ranking as reliable and the absolute figure as a good forecast rather than a quotation, and if you need the exact count, run the text through the provider's own tokenizer before you commit to a budget.
Related: Token counter · Flat rate reference · Models compared by workload · How token pricing works
Questions this tool tends to raise
Why is my real bill higher than this estimate?
Almost always because production sends more input than you pasted. The system prompt, tool schemas, retrieved context and the whole conversation history go with every call. Retries and failed calls are billed too. Price a realistic full context rather than a single message and the gap usually closes.
Which model should I pick?
This page cannot tell you, and it does not try. It ranks by cost, and cost alone is a bad way to choose a model. Use it to rule out options you cannot afford and to find out what the alternatives to your current choice actually cost, then decide on your own evaluations. We publish no quality score for any model.
Are these prices current?
They sync on load from the same nightly capture that feeds the rest of the site, and each figure carries the date it was observed. Nothing here is estimated, interpolated or projected. If a provider changed a rate after our last capture, the page shows the older date rather than a newer guess.
Does the four-characters-per-token rule hold for code?
Not well. Code, JSON and heavily punctuated text tokenize denser than prose, so the estimate tends to run under the true count. Text in scripts that do not use the Latin alphabet can run much further under. For prose in English it is close enough to budget from.
Is anything I paste sent anywhere?
No. The counting and the pricing both run in your browser. The only network request this page makes is the one that fetches the rate table when it loads, and that request carries nothing of yours.
What is the difference between this and the project estimator?
This one starts from text you already have and prices it. The estimator on the home page starts from plain questions about a workload you have not built yet, and produces a monthly figure without you needing to know a token count at all. Use the estimator to scope, and this page once you have real prompts to measure.