AI AI Prices

AI pricing methodology

Use this page for support queries like how AI pricing is calculated, how price changes are detected, and how compare or calculator estimates are built. Methodology explains the mechanics, not just the labels.

Open compare Open calculator Open changes

Read this page in three steps

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

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.

Best for How pricing math works

Use methodology when the question is about formulas, snapshot rules, history windows, or why a change event appears.

Do not stop here if You already know the method

Once the mechanics are clear, move back to compare or calculator to use the shared pricing layer in a real decision flow.

Trust boundary Use data sources for coverage policy

Data sources is the better page for official-first, verified fallback, and provider coverage questions.

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 the decision surface Return to compare

Compare uses the same pricing base when the shortlist is ready and you want a side-by-side outcome.

Open compare
Need workload math in action Open calculator

Calculator applies the formulas on this page to a concrete request shape, budget, cache ratio, and FX display.

Open calculator
Need shorter wording or labels Use FAQ or glossary

FAQ is better for short support answers and glossary is better for term-level definitions.

Open FAQ