Where our numbers come from

Model prices are resolved when you load a calculator. The site first calls its own /api/model-prices endpoint, which reads the public OpenRouter catalogue and converts the per-token rates published there into the per-million-token figures the calculators use. That response is cached for 24 hours: under normal operation, the price in front of you was pulled at most a day ago.

If that request fails or does not list a model we track, the calculator falls back to the price table hard-coded in our catalogue. Those rates were verified on 2026-08-04 against each provider's own pricing page, and every model carries its own verification date — the check is tracked per model, not as a single site-wide "last updated" stamp. They are conservative snapshots, not live data.

Currency conversion is a separate feed: USD-to-BRL rates come from AwesomeAPI via /api/exchange-rate, cached for one hour, with a fixed default as a last resort. Providers publish in US dollars, so every BRL figure here is a conversion we perform — never a rate quoted by the provider.

GPU prices work differently. No single free public API aggregates on-demand GPU pricing across hyperscalers and specialist GPU clouds, so the GPU calculator has no live feed: its figures are a manually researched snapshot. We read each provider's public pricing page in July 2026 — the recorded check date is 2026-07-06 — and wrote the hourly rate down. Unlike the LLM calculators, nothing here refreshes on its own.

The snapshot covers 8 providers in two categories: hyperscalers and specialist GPU clouds. Each entry names the exact instance it refers to, because "the price of an H100" means nothing without knowing whether it is an 8-GPU node divided by eight, a single-GPU instance, or a marketplace listing. Entries flagged as approximate are those where the provider publishes no stand-alone on-demand rate, so the figure comes from a multi-GPU instance, a fractional SKU or a marketplace range.

A few numbers here are not sourced from anyone: they are our estimates, and we would rather say so than let them pass as vendor data.

The first is 400 tokens per PDF page, the constant behind the PDF summary cost calculator and the page-capacity table. It assumes average dense body text: tables, footnotes or a two-column academic layout run higher, a sparse slide far lower. The second is 500 tokens for a dense page in the context-window calculator. Both are round planning numbers, not measurements of your documents.

You can see them at work in the PDF summary cost calculator, the context window calculator and the page-capacity table.

Token counts are approximations: tokenizers differ between model families, and the same text tokenizes differently across languages — Portuguese typically consumes more tokens than English. Treat every estimate here as a planning figure with a comfortable margin, not a billing prediction.

Published list prices are only part of a real invoice: they exclude batch discounts, committed-use pricing, enterprise agreements, free tiers, storage and egress. Our calculators price the on-demand path — the one most projects start on, and the only one every provider publishes openly.

We receive no pricing feed from any provider, have no commercial relationship with the companies listed here, and are not endorsed by them. When a provider changes a price, we find out by reading their page — the same way you would. That is why we publish the links.

A wrong price is the most serious bug this site can have. If a number here does not match what a provider currently publishes, email contato@lwforge.com with the page, the model or GPU, and the value you expected — we check it against the official source and correct it, usually within a couple of days.

For how these prices become cost estimates — the formulas, the rounding and the assumptions in each calculator — see our pricing methodology.