Home › Methodology

Methodology: how these numbers are calculated

Every formula the calculator uses, the exact approximation ratios behind the estimated token counts, where the pricing data comes from, and an honest account of where these numbers are least reliable.

Last reviewed 2026-07-28

Token counting

OpenAI models: exact

GPT-4o, GPT-4.1, GPT-4o mini, o3 and o4-mini all use OpenAI's o200k_base encoding. The calculator runs the real tokenizer via the js-tiktoken library, loaded in your browser, so these counts are byte-for-byte identical to what OpenAI's API will bill you for the same string. They are labelled Exact in the results table.

The tokenizer's rank file is roughly 2 MB, so it is loaded lazily as a separate chunk after the page renders. For the first fraction of a second you may see approximate counts for OpenAI models too; they are replaced automatically once the encoder finishes loading.

Everything else: characters-per-token approximation

Anthropic, Google, xAI, Meta and DeepSeek do not publish a tokenizer that can run entirely client-side. Anthropic offers a token-counting API endpoint, but using it would mean sending your pasted text to a server, which would defeat the main privacy property of this tool. So non-OpenAI counts are estimated by dividing character count by a per-provider ratio:

These results are labelled ~Approx. For ordinary English prose the estimate is usually within a few percent of the true count. It gets materially worse for the input types described under limitations below — code, non-Latin scripts and structured data in particular. If you need an exact figure for a non-OpenAI model, the provider's own token-counting endpoint is the only reliable source.

Why these numbers are only approximations at all is worth understanding properly; the tokenization guide explains what a tokenizer is actually doing and why the ratio varies with content.

Cost calculation

Single request

The base case is straightforward:

cost = (inputTokens  / 1,000,000) × inputPricePer1M
             + (outputTokens / 1,000,000) × outputPricePer1M

inputTokens comes from your pasted text. outputTokens comes from the "expected response length" control — short, medium, long or a custom figure. Because output is priced several times higher than input, this setting has a large effect on the result, and it is a genuine estimate on your part rather than something the tool can derive. Monthly cost is simply the per-run cost multiplied by your runs-per-month figure.

Multi-turn conversations

LLM APIs are stateless: they retain nothing between calls, so a chat application has to resend the entire conversation history with every turn. Cost therefore accumulates rather than repeating. With "model multi-turn conversation" enabled, the calculator computes each turn separately — turn i's input is every prior turn's input and output, plus the current message — and sums them into a cost per conversation.

The consequence is that cost grows with roughly the square of the turn count, not linearly. The multi-turn guide works through the arithmetic and the ways to flatten it.

Advanced chatbot mode with prompt caching

Advanced mode separates the static system prompt (the text box) from a typical user message length, and adds a cache hit rate. The system prompt is charged at full price on the first turn and at the discounted cached rate on subsequent turns, in proportion to the hit rate you set.

One deliberate simplification: the growing conversation history is not discounted, only the static prefix. Real caching schemes reliably cache a stable prefix, not a tail that changes on every turn. In practice providers can cache incrementally as a conversation grows, so this assumption makes the estimate conservative — real costs with caching enabled may come out somewhat lower than shown.

Because cache economics vary substantially by provider — and because a cache write can cost more than an uncached call — treat this mode as a sensitivity analysis rather than a forecast. The prompt caching guide covers each provider's actual discounts, minimum sizes and expiry behaviour.

Context window checks

The "fits?" column compares your input plus expected output against each model's advertised context window. In multi-turn mode it uses the peak single-request size — the final and largest turn — because that is the request that would actually fail if a conversation ran too long.

Fitting is a hard technical limit, not a cost question: exceed it and the request errors or gets truncated. It is also not the same as working well. Retrieval accuracy degrades well before the advertised limit, which the context window guide covers.

Pricing data

All prices are transcribed manually from each provider's official public pricing page, and every model in the table links to its source. Prices are for standard synchronous API access at published list rates, in US dollars per million tokens.

The figures therefore exclude: batch or asynchronous discounts (commonly around 50%), enterprise or committed-use agreements, provisioned throughput pricing, free-tier allowances, promotional credits, and regional price variation. If you are eligible for any of these, your real cost will be lower than shown.

The review date appears in the calculator's footer. Between reviews the table can be out of date, which is why every figure links to the provider's own page — and why corrections are welcome.

Known limitations

Listed roughly in order of how much they could distort your estimate.

1. Reasoning models are understated, often severely

o3 and o4-mini generate internal chain-of-thought tokens that are billed as output but never returned in the response. There is no way to count them in advance and they routinely dominate the bill. Real cost is typically 2–5× the displayed figure and can be higher on hard problems. These rows carry a warning marker; the reasoning model guide explains how to bound the uncertainty.

2. Output length is a guess, and it is the dominant term

Since output is priced 3–5× higher than input, your response length estimate usually drives the total more than the prompt does. The calculator cannot know it. If you have real usage data, use a custom token count taken from your provider's usage logs rather than the presets.

3. Approximation error grows with unusual content

The characters-per-token ratios are tuned for English prose. Expect the estimate to run low — sometimes substantially — for source code and JSON, non-Latin scripts (Chinese, Japanese, Korean, Arabic, Hindi), heavy punctuation or mathematical notation, base64 or hashes, and emoji.

4. Several real cost components are not modelled at all

The calculator prices text tokens only. It does not account for image, audio or video input, which are billed on separate schedules; tool and function call overhead, where each round trip is a full billable request; embeddings; fine-tuning training cost or the premium on inference against a fine-tuned model; or failed and retried requests, which you are charged for.

5. Gateway pricing is indicative

The gateway comparison summarises pricing models rather than tracking live per-model rates, which change constantly across hundreds of models on each platform. Use it to shortlist a platform, then check the platform's own per-model pricing. See gateways vs direct API access.

Reproducing the calculations

All of this is client-side JavaScript, so nothing is hidden. Pricing, context windows and approximation ratios live in one file (src/data/models.js), and the cost formulas in another (src/utils/costCalculator.js). You can read both with your browser's developer tools, and every scenario is encoded in the URL, so a shared link reproduces an exact calculation rather than a screenshot of one.

Corrections and changes

If a figure here is wrong, or a modelling assumption looks mistaken, get in touch — include a link to the provider's pricing page for the fastest fix. Methodology changes that materially affect results are noted on this page along with the review date.