AI AI Prices

Methodology

This page explains how an official-first or verified fallback source becomes a stored snapshot, how a snapshot becomes history or a change event, and how the same pricing layer powers compare and calculator results.

Open glossary Data sources Open FAQ

Read this page in three steps

Methodology is the deeper layer under FAQ. It should explain the mechanics, not just define the terms.

Step 1 Source becomes snapshot

The project stores timestamped pricing snapshots first, preferring official pages and labeling verified fallback when official pages block crawlers.

Step 2 Snapshot becomes history or change

History reflects stored points. Change events require a real delta, not just another crawl or page refresh.

Step 3 Pricing becomes workload math

Compare and calculator share one consistent pricing base so browse results and cost estimates stay aligned.

1. Snapshot-first storage

The site stores pricing snapshots first, then derives history and change events from those stored points. It stays official-first when possible and does not create a price movement event from a visible page refresh alone.

2. Change events require a real delta

A change event appears only when the new stored price differs from the previous recorded value for the same model and dimension. Same-price snapshots do not produce noise.

3. Blend is a scan shortcut

`Blend = 75% input + 25% output`. It is only a ranking shortcut for mixed workloads and should be replaced by compare or calculator once the request shape is known.

4. Compare and calculator share one base

The project avoids keeping a separate rough compare formula. The same normalized pricing layer feeds both decision tools.

Core formulas

These are the main formulas behind compare and calculator.

Single request cost Normal input + output + cached input, all normalized from per-1M-token pricing.
Monthly cost Single request cost × daily requests × active days.
Budget fit Monthly budget divided by single request cost under the current request shape.
Cache savings Only applies to the cached share of input tokens, and only where cached pricing is listed.

How history windows work

`7d / 30d / 90d` summaries compare the latest point against the last stored point at or before the window boundary. If stored history is too shallow, the page says so instead of inventing a delta.

How FX display works

FX conversion changes display only, not the source snapshot itself. When conversion is unavailable, the site keeps source currency visible instead of showing false precision.

Known limitation: source availability

When an official provider path is not consistently crawlable, the site keeps that state visible through verified fallback or baseline labels instead of disguising it as an official fresh crawl.

How batch coverage is counted

Home and provider pages count models with a normalized batch pricing field currently listed. That wording is intentionally narrower than blanket provider-wide batch support.

Need simpler wording Return to FAQ

FAQ is the shorter answer layer when the question should fit in one paragraph.

Open FAQ
Need term definitions Open glossary

Glossary defines the labels used by this page and the rest of the product.

Open glossary
Need source trust details Review data sources

Data sources explains official-first, verified fallback, and manual baseline labeling at the provider level.

Review data sources