ChatGPT Token Cost

Fourteen tokens in, five hundred out

The prompt "Write a short product description for a calculator website." is about 14 tokens. Asking for 500 output tokens in response costs roughly $0.00754 in total — $0.00003 for the input and $0.00750 for the output.

The proportion is the thing to notice. The output costs 250 times what the input costs here, and that ratio is typical of short-prompt, long-response usage.

What a token is

Language models do not process characters or words. They process tokens — subword units produced by a tokeniser that splits text on statistical frequency. Common words are a single token; rarer words split into several.

Practical rules of thumb for English:

• 1 token ≈ 4 characters
• 1 token ≈ 0.75 words
• 100 tokens ≈ 75 words
• A typical page of text ≈ 500 tokens

Non-English text is considerably less efficient. Languages written in non-Latin scripts — Hindi, Tamil, Bengali, Arabic, Chinese — frequently consume two to four times as many tokens for the same content, because the tokeniser's vocabulary is built predominantly from English text. A Hindi prompt can cost several times its English equivalent to process, which matters a great deal for anyone building for an Indian audience.

Code also tokenises inefficiently — indentation, brackets and identifiers all consume tokens.

Why output costs more than input

Providers charge separately for the two, and output is typically three to five times the input rate.

The reason is computational: input tokens are processed in parallel in a single forward pass, while output tokens are generated one at a time, each requiring a full pass through the model that attends to everything generated so far. Generating is sequential and therefore far more expensive per token than reading.

The practical consequence for cost control: constraining output length is the highest-leverage optimisation available. Asking for "three bullet points" instead of "a detailed explanation" can cut cost by an order of magnitude on the same prompt.

Estimating before you build

For any application, the calculation that matters is per-request cost multiplied by expected volume:

Cost per request = (input tokens × input rate) + (output tokens × output rate)

Then multiply by requests per day and by 30. A feature costing half a cent per call is trivial at 100 calls a day and ₹13 lakh a year at a million.

Two levers reduce it substantially:

Prompt caching — where a large portion of the prompt is identical across requests (a system prompt, a document, a few-shot example set), providers offer heavily discounted rates on the cached portion. For applications with long fixed context, this is frequently the single largest saving available.

Model selection — smaller models cost a fraction of frontier ones and are entirely adequate for classification, extraction, routing and summarisation. Reserving the expensive model for the steps that genuinely need it, and routing the rest to a cheaper one, typically cuts cost far more than prompt optimisation does.

Reading the result

The token count here is an estimate from character-length heuristics, not an exact tokenisation. Actual counts differ by a few percent for English and considerably more for other scripts or code. For precise figures, use the provider's own tokeniser or the token counts returned in the API response.

Note also that pricing changes — frequently, and usually downward. Verify current rates on the provider's pricing page before committing to a projection.

Common mistakes

Estimating in words rather than tokens. Multiply words by about 1.33.

Assuming non-English text costs the same. It routinely costs two to four times more.

Ignoring the input/output rate difference. Output dominates most bills.

Forgetting conversation history. In a chat application, the whole prior exchange is resent as input on every turn, so cost grows quadratically with conversation length.

Not using caching for repeated context. It is usually the largest available saving.