The catalog records official provider pricing and OpenRouter pricing as separate channels, normalizes standard text-token rates to USD per one million tokens, stores a verification date and source for each channel, and rebuilds crawlable pages only after the structured data passes validation.
Which models enter the catalog?
The initial catalog targets 50 popular and commercially relevant language models across major providers and open-weight families. A record must have a stable local identity, provider, model name, lifecycle status, source, and pricing status. A model may be tracked as pending or self-hosted, but only verified API prices enter official calculator results.
Open-weight does not automatically mean free API access. When the model maker does not sell a universal hosted endpoint, the official channel is labeled “Self-hosted / Varies.” A separately available OpenRouter route can still appear in the routed channel with its own model ID and source.
How are official prices verified?
First-party prices come from provider documentation, pricing pages, model documentation, or another provider-owned source. Exact-page parsers can apply bounded updates when the expected model and fields are present. A page checksum by itself is only a change signal: it cannot prove that a model price changed.
Promotional, regional, batch, long-context, cache-write, cache-read, audio, image, tool, and priority-processing prices are treated as distinct products. They do not overwrite the standard text-token rate unless the catalog record and parser explicitly describe that treatment. Large or structurally suspicious changes enter review instead of publication.
How is OpenRouter data matched?
OpenRouter pricing is read from its public model feed and joined to the local catalog through an explicit model-ID mapping. Fuzzy name matching is not used because dated versions, preview models, reasoning modes, and provider-specific variants can share similar names while having different prices or behavior.
If the feed fails or a mapped model disappears, the previous record is preserved and can be marked stale. A stale record does not create a new price-history event. OpenRouter’s credit purchase fee remains a separate optional calculator line rather than being silently folded into every inference rate.
How does the workload calculator compute cost?
per run = fresh input cost + cached input cost + output cost
monthly cost = per run × monthly runs
Fresh input cost equals fresh input tokens divided by one million and multiplied by the channel’s input rate. Cached input uses the published cached-input rate when available; otherwise the calculator uses the standard input rate rather than inventing a discount. Output cost uses generated tokens and the output rate. For OpenRouter, users can optionally add the displayed percentage charged when credits are purchased.
The calculator is an estimate. It does not inspect actual requests, tokenizer output, retries, reasoning-token accounting, tool calls, or provider invoices. For precise budgeting, measure token usage from representative production traffic and confirm the provider’s current billing rules.
What happens during the daily update?
- Check sources.Fetch available official pages and the OpenRouter feed without allowing one blocked source to fail the whole run.
- Preserve verified state.Keep the last-known-good price when a source fails, and route suspicious changes to review.
- Append real history.Add a history event only when input, cached-input, or output differs from the preceding verified event.
- Rebuild static HTML.Generate price tables, answers, structured data, internal links, and the Sitemap from validated JSON.
- Validate before publication.Check model identity, prices, source URLs, history continuity, SEO metadata, raw HTML content, images, and local links.
Which primary sources are used?
Every catalog row retains its own source URL and verification date. Report a mismatch through the correction process.