What you actually pay for

Why output costs about 5x input

This is also why reasoning tokens bill as output. The model generates them the same way it generates a visible answer, one sequential forward pass at a time, so they cost the same even when the interface never shows them to you.

Input means everything the model sees

Models are stateless. They remember nothing between calls, so every turn re-sends the whole transcript. Turn 20 pays to read turns 1 through 19 all over again. Input grows linearly with the turn number and the running total grows roughly quadratically, which is the single biggest surprise on most bills.

The two discounts worth engineering for

The same sentence costs more in your language

One sentence, the same meaning, in 20 languages. These are real counts from the tokenizer, computed when this page was rendered, not estimates.

Count tokens from your own code

This page runs on a public endpoint you can call too. It needs no API key, because it runs a local tokenizer pass and never touches a model.

curl https://dreamprompting.com/api/v1/tokenize \
  -H "Content-Type: application/json" \
  -d '{"text": "Mkulima alikagua shamba la mahindi jana asubuhi", "split": true}'

{
  "count": 15,
  "words": 7,
  "chars": 47,
  "exact": true,
  "encoding": "o200k_base",
  "heuristic_count": 12,
  "tokens": ["M", "kul", "ima", " al", "ik", "agua", ...]
}

Send a whole request instead of a string by passing an OpenAI-shaped messages array, which counts every role the way the model will read it:

-d '{"messages": [{"role": "system", "content": "..."},
                 {"role": "user", "content": "..."}]}'

One honest caveat: these are OpenAI BPE vocabularies. Llama, Gemini, Qwen and Mistral each ship their own tokenizer, so treat the count as a close estimate for those rather than an exact figure. The relative story between languages holds across all of them. Ready to spend the tokens? Get a free key or read the API docs.

What a token actually is

A token is not a word, a syllable or a character. It is an entry in a fixed lookup table that was built once, before training, by repeatedly merging the most common adjacent character pairs in a giant pile of text until the table reached its target size. That is the whole of byte pair encoding. The table is frozen forever after that, which is why tokenization is deterministic: the same bytes always produce the same tokens, on every request, for the life of the model.

The consequence people find hardest to believe is that the leading space is part of the token. English text is mostly words preceded by spaces, so the merge process learned space-prefixed forms and never bothered learning many bare ones. The word unbelievable with a leading space is one token. The exact same letters with no leading space are three: un, bel, ievable. Nothing about the meaning changed. Only the position in the sentence did.

Every count in that table came from the same tokenizer the box at the top of this page uses. Paste any of them in and watch the split. The pattern is consistent: whatever was frequent in the training corpus is cheap, whatever was rare gets rebuilt from fragments every time you send it. Shouting costs more than speaking. British spelling sometimes costs more than American, though not always: organisation and organization are both a single token, while tokeniser costs double what tokenizer does. There is no rule here, only frequency.

This also explains why the four characters per token rule is unreliable in both directions. Measured on the prose in this section, English runs about five characters per token, so the rule overestimates by roughly a quarter. Measured on Amharic it lands nowhere near: the same sentence that takes 8 tokens in English takes 55 in Amharic, at barely half a character per token.

The strings that quietly cost you the most

Prose is the case tokenizers were optimised for, and prose behaves well. Everything else in a real application payload does not. Identifiers, timestamps, currency, coordinates and pretty-printed JSON are all sequences the merge process never saw enough of to compress, so they fall apart into near-character-level fragments. These are real counts, computed with the same tokenizer:

Serialisation format is a pricing decision

The single most expensive habit in production LLM code is passing pretty-printed JSON. Take 200 rows of the same three fields, a numeric id, a name and a boolean, and serialise them three ways. Pretty-printed JSON: 5,500 tokens. Minified JSON: 3,100 tokens. CSV with a single header row: 1,432 tokens. Same data, same information, a 74 percent reduction. Every quote mark, every repeated key name and every indentation run is a token you paid for.

Source code behaves better than you would guess, because code was heavily represented in training. A one-line recursive Fibonacci function is 23 tokens for 54 characters, and runs of indentation merge into single tokens rather than one per space. The expensive part of a code prompt is almost never the code. It is the identifiers, the hashes, the file paths and the JSON blobs you wrapped around it.

The context window you are advertised and the one you can use

The context window is the total number of tokens the model can hold in one forward pass, and on almost every provider it is a shared budget rather than an input allowance. Input plus output must fit inside it together. A 128,000 token window with a 4,000 token reply leaves you 124,000 tokens of prompt, not 128,000. If you are also running a reasoning model, the hidden thinking tokens come out of the same budget before your visible answer starts, which is why a long prompt plus deep reasoning can truncate an answer that would have completed fine on a shorter prompt.

In English prose, measured rather than guessed, 128,000 tokens is roughly 106,000 words, which is a decent-sized novel. That number is language-dependent in exactly the way the table above predicts. The same content in Swahili fills the window about 1.9 times faster, and in Amharic close to 7 times faster. A window is a promise about tokens, never about meaning.

The practical discipline is to treat the window as a budget you allocate deliberately rather than a container you fill. Decide up front how many tokens go to instructions, how many to retrieved evidence, how many to conversation history and how many you are reserving for the answer. Enforce those allocations in code with a real token count, not a character estimate, because the character estimate is the thing that will silently push you over.

What actually cuts the bill, ordered by how much

Everything below is measured against one baseline scenario: a 20 turn conversation with a 1,500 token system prompt, 60 token user messages and 200 token replies, priced on the mid tier. That baseline costs $0.3018. Each lever is applied on its own so the numbers are comparable.

Two things stand out. The first is that model choice dominates everything else by a wide margin, and it is the lever teams reach for last. The second is that nothing on this list involves rewriting your prose. Trimming polite phrasing, removing please and thank you, or collapsing whitespace moves the number by a fraction of a percent. Runs of spaces already merge into single tokens, and a leading space is absorbed into the word after it. The prompt-shortening advice that circulates online is optimising the smallest term in the equation.

One caution on the combined row: applying every lever at once is how you ship a product that is 91 percent cheaper and noticeably worse. Change one thing, measure quality against a fixed evaluation set, then change the next. The order above is a good order to try them in precisely because the biggest savings sit at the top and the quality risk is easiest to detect there.

Why a long prompt feels slow and a long answer feels slower

Response time splits into two numbers that behave completely differently, and confusing them is why so much latency tuning goes nowhere. Time to first token is how long you wait before anything appears. Tokens per second is how fast text arrives once it starts. Input length drives the first. Output length drives the second. They are almost independent knobs.

That split gives you a clean diagnostic. If your application feels sluggish before anything appears, the problem is prompt size: shrink the retrieved context, cache the stable prefix, or cut history. If it appears quickly and then crawls, the problem is answer length: cap the output, ask for structured or terse responses, or move to a smaller and faster model. Streaming does not make anything faster, it only moves the first visible token earlier, which is a real user experience win and no saving whatsoever on the bill.

The multilingual penalty lands here too, and this is the part nobody budgets for. Tokens per second is a rate over tokens, not over meaning. If Swahili needs 1.9 times the tokens to say the same thing, the same sentence takes 1.9 times as long to stream at an identical tokens per second figure. Users writing in an underrepresented language wait longer for the same answer, on the same hardware, at the same advertised speed.

Estimating a monthly bill from first principles

Most cost surprises come from estimating with averages instead of building the number up from the request shape. Here is the full arithmetic for a plausible product: a retrieval-backed support assistant. Every figure is computed, not rounded from memory.

Work one conversation first. Turn 1 bills 3,045 input tokens: the 900 token system prompt, 2,100 tokens of retrieved evidence, and the 45 token question. Turn 2 bills all of that again plus the 225 tokens that turn 1 added to the transcript. By turn 4 the input has grown to 3,720 tokens. Across the four turns the conversation bills 13,530 input tokens and 720 output tokens, which on the mid tier is $0.0514. Multiply by 6,000 conversations and the monthly bill is $308.34.

Now apply the levers and watch which ones actually matter at this shape. Caching only the system prompt saves 19 percent, because the system prompt is a small fraction of the total. Caching the system prompt and the retrieved chunks together, which requires putting retrieval before the question and keeping chunk order stable, saves 63 percent and brings the bill to $113.94. Trimming replies from 180 to 110 tokens saves about 11 percent. Retrieving one chunk instead of three saves 33 percent. Running the same design on the small tier costs $82.22, and on the small tier with a cached prefix, $30.38. On the frontier tier the identical product costs $1,541.70.

The spread from top to bottom of that table is a factor of 50, on the same product, serving the same users, answering the same questions. That is the real lesson of token billing: the bill is a design output, not a market price you are handed.

Two adjustments before you trust an estimate like this. Multiply by roughly 2 if a meaningful share of your traffic is in an underrepresented language, because every input and output token count above scales with the fragmentation ratio. And add a headroom factor for the conversations that go long: averages hide the tail, and because cost grows quadratically with turn count, the 5 percent of conversations that run to 20 turns can easily be a third of the bill.

Every model family counts differently

There is no universal token. A tokenizer is trained alongside a model family, on that family corpus, at whatever vocabulary size the team chose, and it ships frozen with the weights. Two models can read the identical string and bill you for different numbers of tokens. The two vocabularies on this page make that concrete: the same twelve sentences are counted by both, and switching the toggle above moves several rows dramatically.

Hindi is the clearest case. On the older 100k vocabulary the sample sentence costs 42 tokens. On the newer 200k vocabulary the same sentence costs 15. That is a 64 percent price cut delivered by nothing but a bigger lookup table. Arabic drops from 21 to 11. Amharic falls from 74 to 55, which is a real improvement and still leaves it nearly seven times the cost of English. English itself does not move at all, because it was never the language paying the penalty.

The practical consequences are worth taking seriously if you route across providers. A prompt engineered to fit exactly inside a context window on one model can overflow on another. A cost model calibrated on one family will misprice another, in either direction. Rate limits expressed in tokens per minute are not comparable across vendors. And a prompt cache is keyed to one provider and one exact prefix, so switching models silently discards it and your costs jump back to full rate with no error to tell you why.

The safe habit is to count with the tokenizer belonging to the model you are actually calling, keep a small margin rather than packing the window to the last token, and treat any cross-family number as an estimate. The counts on this page use OpenAI BPE vocabularies. For Llama, Gemini, Qwen or Mistral they will be close but not exact. What does transfer across every family is the shape of the problem: prose is cheap, identifiers are expensive, and underrepresented languages pay a multiplier.

The multilingual penalty is not mainly a cost problem

The extra money is the easiest part of this to see and the least important. For short support messages the absolute difference is fractions of a cent. Three other effects hurt more, and none of them show up on an invoice.

There is a quality dimension underneath all three. A word chopped into six generic fragments carries less coherent meaning into the model than a word with its own dedicated entry, so heavily fragmented languages tend to get weaker results as well as more expensive ones. The tokenizer is the first layer of the model, and it was fitted to a corpus that mostly was not about you.

If you are building for these users, the mitigations are unglamorous and effective: budget context in tokens measured on real sample text in the target language rather than in English, set output caps per language instead of globally, test history-trimming rules on non-English transcripts, and prefer newer vocabularies where you have the choice. The Hindi row on this page is a 64 percent saving available for free, to anyone who checks which tokenizer they are on.

Questions people actually ask

Is the four characters per token rule useful at all?

Only for English prose, and even then it is loose. It overestimates short English sentences and it underestimates non-Latin scripts badly. Tokenize instead of estimating whenever the number matters.

Do I pay for the system prompt on every single turn?

Yes, unless it is cached. It is re-sent with every request because the model holds no state between calls. A stable system prompt is the single best caching candidate you have.

Do I pay for reasoning tokens I never see?

Yes, and they bill at the output rate, because the model generates them exactly the way it generates visible text.

Does trimming whitespace or punctuation save money?

Barely. Leading spaces are usually absorbed into the following token. Cutting conversation history, caching a stable prefix and asking for shorter replies are worth orders of magnitude more.

Can I avoid all of this?

You can move the bill rather than remove it. Running an open-weight model on your own GPU trades per-token cost for hardware you have to buy and keep busy. The VRAM calculator shows what that hardware needs to be. Or route through this gateway, which pools provider free tiers and costs nothing.

Why does a word cost more when it starts a sentence?

Because the leading space is part of the token. The tokenizer learned space-prefixed forms from ordinary prose, so the word unbelievable with a space in front is a single token while the same letters with nothing in front split into three. Capitalisation has the same effect for a different reason: Hello is one token and HELLO is two, since shouting is rarer in the training data than normal case.

Are numbers really that expensive?

Yes, and formatting makes it worse. Digits group in runs of up to three, so 255 is one token but 1000 is two. Adding separators bills every separator: 1000000 is three tokens while 1,000,000 is five, and $1,250.00 is six. An ISO date like 2026-08-03 costs six tokens, on every row of every table you paste in.

How expensive is a UUID?

A standard 36-character UUID is 18 tokens, more than a full English sentence. Short hex hashes are worse per character: a3f9c2b1 comes out at exactly one token per character. If you are passing identifiers into a prompt at scale, replacing them with short sequential labels and mapping back afterwards is one of the few genuinely large prompt-shrinking wins available.

Should I send JSON or CSV to the model?

CSV, whenever the data is tabular. Two hundred rows of three fields cost 5,500 tokens as pretty-printed JSON, 3,100 minified, and 1,432 as CSV with a single header row. That is a 74 percent reduction for identical information, because JSON repeats every key name on every record and pays for every quote and every indentation run.

Does the context window include the answer?

On virtually every provider, yes. Input and output share one budget, so a 128,000 token window with a 4,000 token reply gives you 124,000 tokens of prompt. Reasoning tokens come out of the same pool before the visible answer starts, which is how a long prompt on a reasoning model can truncate an answer that would have completed fine on a shorter one.

What happens if I go over the context window?

A well-behaved API rejects the request with a context length error and charges nothing. The dangerous case is a client library that silently truncates the middle of your transcript or drops the oldest turns and returns a confident answer built on a prompt you never sent. Count tokens before you send rather than finding out afterwards.

How many words fit in a 128k context window?

Around 106,000 words of English prose, measured on real text rather than assumed. That figure is language-dependent in the same way everything else is: the same content in Swahili fills the window about 1.9 times faster and in Amharic close to 7 times faster.

Does streaming make responses cheaper or faster?

Neither. Streaming shows you the first token sooner, which is a genuine user experience improvement, but the total generation time and the total token count are unchanged. It costs exactly the same as the identical non-streamed request.

Does a longer prompt make generation slower?

It makes the wait before the first token longer, because prefill scales with prompt length. It barely affects the speed at which text arrives after that, which is set by model size and provider load. So if your app is slow before anything appears, shrink the prompt. If it appears fast and then crawls, cap the output.

What is the single biggest cost lever?

Model choice, by a wide margin, and it is usually the one teams try last. On the 20 turn baseline used on this page, moving from the mid tier to the small tier cuts the cost by 73 percent. Batching cuts 50 percent, a 4 turn history window 31 percent, and caching the system prompt 27 percent. Rewriting your prompt to be more terse is worth a fraction of a percent.

Do different models count the same text as the same number of tokens?

No. Each family ships its own tokenizer, frozen with the weights. Even between two vocabularies from the same vendor the gap is large: the Hindi sample on this page costs 42 tokens on the older 100k vocabulary and 15 on the newer 200k one. Count with the tokenizer belonging to the model you are actually calling, and leave margin rather than packing the window exactly.

Why did my prompt cache stop working?

Almost always because the prefix stopped being byte-identical. A timestamp, a session id, a randomised greeting, a reordered set of retrieved chunks or a switched model all invalidate it, and none of them raise an error. Put everything stable first, keep it stable, and put the variable parts at the end.

Can I fix the multilingual penalty in my own code?

You cannot change the tokenizer, but you can stop your own limits from compounding it. Budget context using token counts measured on real sample text in the target language, set output caps per language rather than one global number, test your history-trimming rule on non-English transcripts, and choose the newer vocabulary where you have that option. Translating to English, calling the model, then translating back is occasionally cheaper but usually loses more in quality than it saves.

Is it worth counting tokens before every request?

For anything user-facing, yes. Tokenizing locally needs no API key and no network call, and it is the only reliable way to enforce a context budget, reject oversized uploads early, and show a real cost estimate rather than a character guess. The endpoint documented above does exactly that and is free to call.