Trust & method

Methodology: how ByteCosts builds its pricing index

ByteCosts builds its pricing index from committed, source-backed data - 4,588 priced models across 167 providers, plus GPU rental and self-host specs. The live site only displays committed data; prices are refreshed by a manual, network-free local command, so the static build never calls a provider API. Official list prices are labeled and graded separately from computed estimates, and we never invent a number: if a source is stale or ambiguous we keep the prior value and flag it.

How the data is built and refreshed

A curated master drop is the single committed input; a deterministic, network-free build re-derives the compact slices the site reads (provider summaries, official price rows, the change ledger). The site only ever displays committed data, so the "last updated" date (July 19, 2026) tracks the master timestamp, not the deploy - visiting the site, deploying it, or running CI can never change a price or call a provider API.

Live data is refreshed only by a manual, double-gated command run from a local shell, never by a visitor or CI. Research rules are strict: prefer a provider's own pricing page over its docs over third-party data, never invent a missing price, and if a source is stale or ambiguous keep the prior value and flag the row for manual verification.

Source confidence grades

Every official price row carries a confidence grade, derived at build time from the source type and the provider's status - never hand-set. The grades, straight from the codebase:

ByteCosts price-confidence grade rubric
GradeWhat it meansIn this dataset
A+Read from the provider's official pricing page207 rows
AFrom official provider docs (price stated indirectly)92 rows
BFrom a normalized trusted dataset-
CExtracted from a page by scraper / LLM10 rows
DUnverified - the source didn't confirm the price1 rows
EStale - not re-verified recently-

Estimates vs official prices

ByteCosts is explicit about which numbers are read from a source and which are computed. Read this before citing a figure:

  • Official list prices: per-model input/output rates extracted from a provider's pricing page or docs, dated, and graded A–E. These are list prices - they exclude negotiated, volume, and committed-use discounts.
  • Cost estimates: any monthly/per-user/per-request figure a calculator produces is computed from your inputs using public formulas, not quoted by a provider.
  • Prompt-cache rates: the dataset carries a real cache-read price where a provider publishes one; cache-write tiers are derived from the input rate using published multipliers (5-minute 1.25×, 1-hour 2×, read 0.1×).
  • Intelligence / coding scores: from the Artificial Analysis benchmark where measured, and shown as null where a model is unmeasured - never imputed.
  • Token normalization: every token price is normalized to USD per 1M tokens so models with different native billing units are comparable.

Every cost formula is public

There is exactly one cost engine. Token cost, prompt-cache break-even, batch discounts, retry overhead, gateway fees, and subscription-vs-API break-even are all computed by the same shared functions, so a number in one calculator can't disagree with the same number in another. The base math is simple and inspectable: cost per 1M tokens = (input tokens × input rate + output tokens × output rate) ÷ 1,000,000, then adjustments in a fixed order (caching → retry → batch → gateway → tax).

GPU rental and self-host estimates

GPU rental rates are normalized from a public cloud-GPU catalog into one per-GPU-hour figure per (provider, GPU, region), so a multi-GPU box doesn't look artificially cheap. Hardware specs (VRAM, bandwidth, FP16/FP8 throughput) come from NVIDIA datasheets, and model architectures (layers, KV heads, MoE active parameters) from each model's published config - both carry source URLs and a build-time validator rejects any unsourced number.

Self-host cost and VRAM tools compute from that committed data: weights plus KV cache against real VRAM, and cost per 1M tokens from the rental rate and serving throughput. Throughput is the one number that's often unpublished - where a sourced benchmark (MLPerf, a vendor, or a published vLLM/SGLang/TensorRT run) exists we use it and label it "measured"; otherwise the engine returns a roofline-estimated band clearly labeled "estimated," never presented as measured.

Frequently asked questions

Does ByteCosts ever call a provider API to get prices?

No. The live site only displays committed JSON, and the build is network-free. Prices are refreshed by a manual, double-gated local command that the operator runs by hand - never by a visitor, a deploy, or CI. This is what keeps ByteCosts a static site with no server runtime and no provider cost.

What does a price confidence grade mean?

Each official price row is graded A+ to E based on how it was sourced. A+ means it was read from the provider's own pricing page; A from official docs; B from a normalized trusted dataset; C from a scraper/LLM extraction; D unverified; E stale. Of 310 official rows, 299 are graded A or A+. Grades are derived at build time, never hand-set.

Are calculator results official prices?

No. List prices are official and dated. Anything a calculator computes - monthly spend, per-user cost, margin, break-even - is an estimate produced from your inputs with public formulas. Treat calculator output as a planning figure, not a quote, and validate against a provider's billing for your real workload.

ByteCosts methodology. ByteCosts. Updated July 19, 2026. https://bytecosts.com/methodology/

Sources

Machine-readable