Providers and supply tiers

A model is the unit of capability; a provider is the entity serving it. The same model is often served by several providers, differing in price, context length, supported protocols, and output precision. The model catalog lists every provider's price per model, while provider pages list every model a given provider serves.

Why one model has several prices#

Model weights are published by a vendor, but inference can be served by that vendor, by a cloud provider, by an aggregator, or by a third-party inference service. They run the same model yet differ in:

• Price, reflecting different cost structures and commercial strategies
• Context length, since some providers cap it below the model's nominal limit
• Output precision, since some providers serve quantized builds to lower cost
• Supported protocols, since not every provider offers all four text protocols
• Availability and performance, where time to first token, throughput, and success rate differ persistently

Amux lists these differences explicitly and bills at the price of the provider that served the call, with no uniform markup.

Supply tiers#

Every model-provider price carries a supply-tier label:

Official and aggregator are equivalent for routing purposes; the two labels exist only to state the source. The tier that actually participates in filtering is value: it forms a separate candidate pool and is never mixed into the same ordering pass as the other two.

Account and key settings can restrict the supply-tier scope:

With "value only", a model that has no value-tier provider returns an error rather than falling back to a more expensive one. For how scopes merge and take precedence, see routing and failover.

Quantization and precision#

Value-tier supply is often deployed quantized. Quantization does affect output quality, so model detail pages state the precision explicitly: no label means full precision, while FP8, INT8, INT4, AWQ, or GPTQ indicates the corresponding quantized build.

Where output quality is a hard requirement, set the supply-tier scope to "official quality only", or pin providers on the key.

Fields on a model detail page#

Price#

Prices are itemized, and which items appear depends on the model type (chat, image, video, and so on). Common items include input, output, cache read, cache write, and reasoning tokens. For what each billing component means, see billing overview.

An item marked base price means the provider uses the model's base pricing; provider price means that provider sets its own. Some providers offer several tiers for the same item, shown as a range and expandable on the detail page.

Some models are priced differently by time of day, or are currently on promotion; such prices carry a corresponding badge.

Performance metrics#

All three are volume-weighted averages, not percentiles, and the window can be switched between 1 day, 7 days, and 30 days.

The availability denominator excludes client errors: failures caused by a malformed request are not counted against the provider. Periods with no successful samples are left out of the calculation rather than counted as zero.

Context length#

Labelled per provider. During routing, the request's estimated context size is compared against each candidate's limit, and candidates that cannot fit it are excluded from the pool. Requests are admitted when the estimate falls short, so requests extremely close to the limit may still be rejected upstream.

Model status#

Deprecated status exists to give an early migration signal; plan the switch once it appears.

Comparing several models#

Model comparison puts several model-provider pairs side by side across price, context, performance metrics, supported endpoints, and capabilities. Adding the same model twice compares two providers' prices for it.

Related#

• Routing and failover — how the candidate pool is ordered and failures are handled
• API keys — restricting providers and supply tiers on a key
• Billing overview — itemized charges and how prices are composed