Provider routing

The same model is served upstream by several endpoints: for closed models these are service tiers of one vendor; for open-weight models they are different hosting companies. By default the route is picked for you and there is nothing to tune. provider and service_tier exist for when something specific matters: price, a ban on request retention, or full-precision weights.

Both fields are accepted by POST /v1/chat/completions, POST /v1/responses and POST /v1/messages.

Service tier

service_tier picks the class of service at the same provider — same model, same weights, different price and queue priority:

Value	What changes
"flex"	Roughly half the standard price, served best-effort: higher latency, lower availability
"priority"	Faster and more reliable than standard, roughly twice the price
omitted	Standard tier

curl https://api.mixen.ai/v1/chat/completions \
  -H "Authorization: Bearer $MIXEN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "service_tier": "flex",
    "messages": [{"role": "user", "content": "Walk through this log"}]
  }'

Not every model has tiers. OpenAI and Google models do; Claude, for instance, has none. Sending service_tier to such a model is not an error — the upstream simply serves it at the usual price. So it will not get cheaper everywhere you ask: check the prices, and read the actual charge from GET /v1/history.

Billing follows the actual charge, so savings on flex land directly in your bill: you pay for the request that ran, not for the standard tier’s list price.

Choosing a provider

provider is an object passed upstream as-is:

Field	Type	What it does
order	string[]	Preference order
only	string[]	Allow-list: these and nothing else
ignore	string[]	Deny-list
sort	string	price, latency or throughput
allow_fallbacks	bool	Allow moving to another provider on failure (default: yes)
data_collection	string	deny — do not route to providers that may store requests
zdr	bool	Zero-data-retention endpoints only
quantizations	string[]	Acceptable quantizations: fp8, fp16, bf16, …
max_price	object	Per-token price ceiling

Python

from openai import OpenAI

client = OpenAI(base_url="https://api.mixen.ai/v1", api_key=MIXEN_API_KEY)

resp = client.chat.completions.create(
    model="glm-5.3",
    messages=[{"role": "user", "content": "Process this customer record"}],
    extra_body={"provider": {"data_collection": "deny", "quantizations": ["bf16", "fp16"]}},
)

cURL

curl https://api.mixen.ai/v1/chat/completions \
  -H "Authorization: Bearer $MIXEN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "provider": {"data_collection": "deny", "quantizations": ["bf16", "fp16"]},
    "messages": [{"role": "user", "content": "Process this customer record"}]
  }'

Quantization is not the same thing as a discount

For open-weight models, the price spread between hosts is mostly about quantization: some serve full weights, others compress them to fp8 or fp4. Such a model is cheaper to run and answers differently. If your task is precision-sensitive, state quantizations explicitly instead of relying on “pick the cheapest”.

A provider name and a tier are different things

A provider’s base slug does not cover its tiers: only: ["google-vertex"] yields the standard endpoint, not the cheap one. A tier is selected either through service_tier or by the suffix in the name itself — only: ["google-vertex/flex"].

When the request fails

With allow_fallbacks: false and no available provider in your list, the request returns 404 instead of moving elsewhere — that is the intended behaviour, not a fault:

{"error": {"message": "No allowed providers are available for the selected model.", "type": "invalid_request_error"}}

Leave fallbacks on wherever getting an answer matters more than getting it from one specific provider.

What this means for your balance

Asking for an expensive tier is accounted for in the pre-flight balance check: priority is estimated at double the price, because the catalog price is the standard endpoint’s. In practice that means priority requires more free balance than catalog arithmetic suggests.

Routes have their own rates, and they differ more than one expects: on open-weight models different hosts charge up to 2.6× apart for cache reads at nearly the same input price. The full list of a model’s routes — price of each, quantization, context and observed uptime — is on its card in the catalog, where the tag for provider.only can be copied. Some routes also change the rate on a long prompt or by a UTC schedule — see price steps.