1. Snapshot-first storage
The site stores pricing snapshots first, then derives history and change events from those stored points. It does not create a price movement event from a visual page refresh alone.
Methodology
This page explains what the site stores, what triggers a change event, and how the calculator turns public token pricing into workload cost estimates.
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. Calculator uses one consistent formula
Compare and calculator share the same pricing math. The project avoids keeping a separate “rough compare formula” that could drift from the calculator.
Core formulas
These are the formulas behind compare and calculator.
How history windows work
`7d / 30d / 90d` summaries compare the latest point against the last stored point at or before the window boundary. If the 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 the 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 fallback or baseline labels instead of disguising it as an official fresh crawl.
What this methodology optimizes for
Traceability over cosmetic completeness, and decision speed over raw token-table density.