Public LLM API Prices · How pricing is modeled

How pricing is modeled, compared, and explained

This is a user-facing explainer, not dry internal schema docs. It clarifies why the same model can show up with different prices, and why some rows are only partially comparable.

Open Text Compare Back to Providers See coverage

How they fit together

The provider tells you who published or sold the price.

The model tells you which capability is being priced.

The endpoint or task type tells you which comparison axis applies, such as tokens, images, or video seconds.

The pricing line binds all of that to a public price, a unit, a timestamp, and evidence.

A fast way to judge whether two rows should be compared directly: Check provider type first, then endpoint and pricing basis, then open the evidence. If those layers line up, the prices are usually on the same comparison axis.

Start with five core concepts

Every pricing view on the site is built from the same few objects.

Provider

The entity that publicly sells or publishes the price you are seeing.

An official provider is the model creator's own first-party platform. A third-party platform may host, resell, or package the same model. This site labels rows as official, third-party, or unclassified so channel differences are visible instead of being mistaken for model differences.

Model

The capability being invoked, such as a specific GPT, Claude, Gemini, Imagen, or Veo variant.

The model answers 'whose capability is this?' but it does not determine the final price by itself. The same model can appear across multiple providers, endpoints, and billing bases.

Pricing line

The smallest traceable unit of public pricing after normalization.

A pricing line typically binds a provider, model, endpoint, pricing basis, billing unit, currency, price amount, public time semantics, and source evidence. Each table row is one such line.

Evidence

The source link, scrape time, and raw excerpt that support a row.

This site is designed to be inspectable, not taken on faith. Each row aims to retain the source URL, official or effective time when known, source observed time, site publish time, raw evidence excerpt, and normalized confidence so users can verify the interpretation.

Why the same model can show different prices

Channel differences: official first-party prices and third-party platform prices can legitimately differ.

Task differences: the same model may expose different endpoints for text, embeddings, images, or video.

Billing differences: input tokens, output tokens, requests, image output, and video output are different pricing bases.

Time differences: public pricing changes over time, and published rows preserve that timing context.

Packaging differences: third-party platforms may add hosting, workflow, or platform-layer costs.

Why some rows are partial or unmapped

Not every public price can be normalized cleanly. The site would rather show the limitation than pretend those rows are directly aligned.

partial usually means a price was found, but the unit, tax treatment, effective dates, or tier rules are incomplete.

unmapped means the public information could not yet be mapped into the site's common pricing basis or billing unit.

Some providers or models also remain structurally incomplete in the directory, so they may appear as unclassified or with limited metadata.

How evidence and source attribution work

The Evidence panel shows the source URL, official or effective time when known, source observed time, site publish time, and raw evidence excerpt.

Normalized confidence is a measure of interpretation quality, not an official endorsement.

If a row is only partly aligned, the reliability warnings explain what is missing, such as unmapped units or incomplete tiers.

The site helps with comparison and interpretation, but the official pricing page remains the final source of truth.