Skip to main content
A model on Kyma can usually be served more than one way. This page states which one is chosen, in what order, and what each costs you — because a gateway that does not say this is asking you to trust an average.

​
The rule, in one line

What you pay is derived from the specific infrastructure that served your request — not from an average, and not from a table we maintain. usage.cost on every response is the exact amount charged for that request. There is no second number anywhere.

​
Why a model has more than one price

The same model is often available from several operators, at different service tiers, in different regions. Those are genuinely different products with genuinely different costs, and the spread between the cheapest and dearest way to serve one model can be several-fold at identical context length. So “the price of a model” is not one number. What we publish is the cheapest route we have — the best price available for that model, not an average and not a maximum. That number is a floor, and the distinction matters: if the cheapest route is busy or down and a dearer one answers, that request costs more, and usage.cost says exactly what it was. You are never charged a price you cannot see after the fact.
Published prices are recomputed daily from what serving actually costs us. Every change — up or down — is published in the changelog on the day it takes effect.

​
The order routes are tried

  1. The primary route, then its configured alternates.
  2. Within those, cheapest first. A route that costs more is tried later, not removed — it is what keeps the model answering when the cheap one is down.
  3. A route with no known rate sorts last. Unknown is not the same as cheap.
  4. Routes that would certainly fail this particular request are skipped entirely — for example a route without tool support when your request carries tools.
Requests that fail are not billed. You pay for the attempt that completed.

​
What a failover costs you

If the usual route is unavailable and a dearer one answers, that request costs more, and usage.cost says so. We used to cap the charge at the published price. It sounds generous and it was not: keeping that cap meant the router had to refuse the dearer routes, which left most multi-route models with a single supplier. A price ceiling that removes your failover is a worse deal than a request that occasionally costs more. If you would rather fail than pay above a limit, say so per request — see max_price below.

​
Guarding against a wrong number

A single request is never billed more than 3× the published price, whatever an upstream reports. It exists because a usage figure can arrive wrong — misreported upstream, or misread by us. Three times the published price sits far above any real difference between routes and far below a decimal-point error, so it clips mistakes without clipping an expensive but genuine one. A request that hits that stop is charged less than it cost to serve, and the model is investigated the same day.

​
Choosing your own limit

max_price is in design and not yet accepted by the API. It is documented here because the routing rules above are what it will build on.
The intent: a per-request ceiling you set, and when no route can serve under it the request fails with a clear error rather than being served at a price you did not agree to. Cost-sensitive batch work sets it; latency-sensitive interactive work does not. The choice is yours per request rather than ours for everyone.

​
What we do not do

  • After a refusal, no other creator answers. If a route returns HTTP 403, Kyma keeps trying the model you asked for on its other routes; if it falls back further, it only considers models from the same creator. When nothing serves, you get 403 route_refused with error.suggested_models — up to three other model ids, same creator preferred. Your request is never completed by another creator’s model under the name you asked for.
  • We never hide the price. usage.cost is the amount charged, always.