What your workload costs on every measured model

A bill for an AI model is three numbers added up: the tokens it reads, the tokens it writes back, and the tokens it spends thinking before it answers. This tool works out all three for 308 models at once. Pick the workload closest to yours or paste a sample of your own prompts, set how many requests a month you send, and the table below redraws, cheapest first.

The input side is measured against real bills. Models that share a tokenizer count any text the same way, and the fingerprint dataset says which ones do, so we billed 24 real documents (articles, code, JSON, CSV, HTML and encyclopedia text in nine writing systems) on one model from each of 50 tokenizer families and fitted each family's rate for every kind of text. Tested on 18 other documents billed on 12 models, the input count landed 5.8% from the bill at the median and within 10% on 80% of readings.

The thinking side is measured: between 5 October 2026 and 8 October 2026 we sent eight tasks to 44 reasoning models, three times each at their default effort and once each at low and high, and read the reasoning tokens from the bill. The table shows the median and the 90th percentile for the task closest to your workload and how many runs they come from; with three runs, the 90th percentile is the longest of the three.

Why thinking is a range

A reasoning model decides for itself how long to think, and the decision depends on the task and on the effort setting, so one request can cost ten times the next. The way to budget for that is to measure the distribution rather than guess a point. The think bench sends eight tasks (a code fix, a maths word problem, a JSON extraction, a summary, a classification, a question over a long passage, a tool-call plan and a translation) to each reasoning model at its default effort three times and at low and high once, and reads reasoning_tokens from the usage block of every answer. The table prints the median and the 90th percentile for the task type closest to your workload, with the number of runs behind them. Three runs per task will not catch the rare very long answer, so treat the 90th percentile as a planning figure, and cap reasoning in your own calls at the level you budget for.

A model whose listing accepts a reasoning setting but has not yet been through the bench is marked unmeasured, its figure is input and output only, and it is ranked after every model with a complete estimate, so a part of a bill never sits among whole ones. Where a model reasons at its default without being asked, the default row carries that; where it reasons only when asked, the default row reads zero and the low and high rows show what asking costs.

How the figures are made

How far the estimate goes

On 8 October 2026 we billed 18 documents on 12 models, one from each major tokenizer family, and compared each bill with the estimate for the same text. These documents were kept apart from the 24 the rates are fitted to. The input count landed 5.8% from the bill at the median, within 5% on 42% of readings and within 10% on 80%; nine readings in ten were within 16%. Rates read off the 50 fingerprint strings alone, on the same bills, missed by 24.9% at the median.

The prose rate is fitted to English, so other languages written in the Latin alphabet are priced as English, and they bill above the estimate: Spanish text by 7.5% at the median and up to 34.4%, and German text by 25.7% at the median and up to 44%. A pasted sample is sorted line by line, which is right for the mix and approximate at the edges: a code comment counts as prose. The bench tasks are short and self-contained; an agent loop over a long context will think more than the median here, which is one more reason to plan on the 90th percentile and cap it. Prompt caching discounts, batch pricing and volume contracts are left to the buyer's own terms; the table uses the listed price, and a listing priced by time of day at its weekly average. Every figure is dated, and the same table is available as JSON on the data API.