Methodology

Last reviewed by Jaehyun Jeon on 2026-09-27.

computetrail records the price of large language model APIs once per day and keeps the full history, so you can see how each model's cost changes over time rather than just today's number. This page describes exactly how that happens, what we leave out, and where the method is weak. We would rather publish the limitations than have you discover them.

Where the data comes from

Prices are collected from public, openly published provider pricing aggregated byOpenRouter's models API. Each day we take one snapshot and store it verbatim, exactly as returned, before any processing. We do not scrape provider websites, and we do not enter prices by hand.

The collection schedule

A collector runs on our own server on a fixed daily timer and writes one snapshot per calendar day. The site is a static build that reads those snapshots, so what you see is regenerated from the stored record rather than fetched live when you load the page. Both steps are automated and run unattended; nobody decides on a given morning whether to record.

We currently hold 119 daily snapshots, the most recent from 2026-10-25, covering 438 paid models. Snapshots are append-only and are never edited after the fact. Historical prices cannot be back-filled — a price we failed to record is simply gone — which is the entire reason this site exists.

How prices are normalized

• Source prices are given per token; we multiply by 1,000,000 and show USD per 1M tokens.
• Input (prompt) and output (completion) prices are tracked separately, plus cache read and cache write where a provider publishes them. 315 of our paid models currently publish a cache-read price.
• Context windows are recorded as published by the source.
• Figures exclude taxes, minimum commitments, committed-use and enterprise discounts, free tiers, and currency conversion. They are list prices, not your invoice.

What we exclude from our counts, and why

Some entries would distort any statistic we publish about how often prices move, so we leave them out of aggregate counts. Each exclusion has a reason:

• Alias entries (names containing latest) — an alias can be silently repointed by a provider to a different underlying model. When that happens the price appears to change even though nothing was repriced. Counting it would inflate our "prices changed" figures with events that are really model swaps.
• :batch variants — these normally mirror their parent model at a fixed ratio, so counting both double-counts a single decision. We analyse them separately when the batch relationship itself is the subject.
• Free tiers and zero-priced entries — excluded from price statistics, since a $0 listing is a distribution decision rather than a price.

Figures we derive

• Blended price — a single number for ranking, assuming three input tokens for every output token: (3 × input + output) / 4. It is a comparison aid, not a budget. Your real ratio decides your bill.
• Rank and percentile — a model's position by output price among all paid models we track, and within its own provider's line-up.
• Cache discount — 1 − (cache read ÷ fresh input), shown only when the provider publishes a cache-read price.
• Price change — computed from our own stored snapshots, comparing the first and most recent readings we hold for that model, with the dates shown.

Which pages we publish

We publish a page when there is something on it that a table row could not have told you. That rule used to be applied loosely here, and in September 2026 we applied it properly.

Until then this site also generated one page per model and one per provider —136 of them. Each was built from the same row of the same table, wrapped in sentences a script filled in: the rank, the cache discount, the blended rate, and a line saying whether the price had moved. All of it was true, and none of it needed its own address. We removed every one of those pages on 2026-09-27.

The data did not go anywhere. The front page carries the whole table — all 438 paid models — and opening a row shows exactly what those pages showed: the recorded price history, the rank within its provider and overall, the cache discount, and the blended rate. Links to the old addresses redirect to the matching row.

We are stating this plainly because it changes what you can find here through a search engine. What is left to index is the table and the writing: this page, theguides, and who runs the site. A generated page per row of a database is not writing, and we should not have been publishing it as though it were.

Known limitations

These are real, and we would rather state them than have them found:

• We sample once a day. A price that changes and changes back between two snapshots is invisible to us. Our change counts are therefore a floor, not a total.
• A change in coverage looks like a change in the market. When our source begins publishing a field or a set of entries it did not expose before, dozens of "new" listings can appear on one day. We have seen this happen and we say so rather than reporting it as a wave of product launches. Price data alone cannot separate the two.
• Open-weight models are served by many hosts. For those, the price we record may be the cheapest available host rather than the model author's own rate, so a comparison against a first-party listing may not be like-for-like.
• We measure price, not quality. Nothing here says a model is good. A cheaper model that fails your task is not cheaper.
• Aggregator lag. If our source is late or wrong about a price, we will be too, and our snapshot will faithfully record the error with the date we recorded it.

Independence and funding

computetrail is not affiliated with, sponsored by, or endorsed by any model provider. No provider pays for placement, and no provider reviews content before publication. Rankings are produced mechanically from recorded prices. The site is funded by advertising; see ourprivacy policy for what that involves and ourterms for the limits of what this data is.

Corrections

Provider pricing changes without notice and aggregator data can lag. Every figure on this site carries the date it was recorded, so you can always see how fresh it is. If you believe a number is wrong, write to wogus711929@gmail.com with the model and the date — we will check it against the stored snapshot and say publicly if we got it wrong. We correct the presentation and the analysis; we do not retroactively edit a stored snapshot, because an unaltered record is the only thing that makes the history worth anything.