Models, tiers, and scoring

The Modelspage is the workspace's model registry: every model Cloud Score knows about per connected provider, with the facts routing needs. A request can only ever be routed to a model that is Enabled there. At the Select stage, Cloud Score scores the models that survived matching and policy filters on three axes, cost, latency, and quality, and the highest score wins. The rest are kept, in rank order, as failover backups.

A tier is an opinion Cloud Score starts with, not a measurement. The column tooltips say so: Operator-set prior (price band at discovery). Not a measurement. and Operator-set prior. Not a measurement.

Three things the Measured cell can show instead of a number, and none of them is zero:

• learning with the sample count and the floor in brackets: fewer than 20 completed requests, so the model is exempt from every penalty. The tooltip reads Not penalised: still learning (12 of 20 samples). Cold start is inert by design — no delta is applied until the sample floor is reached. on the Routing signals tab of Optimization settings.
• — with the tooltip No measured signal for this model yet: no completed requests in the stats window.
• — for the whole column when the backend does not serve routing signals yet; the tooltip says it is unmeasured, not zero.

Filters first. Five gates run in a fixed order before anything is scored. The Select detail in Observability records how many candidates each gate removed.

Then the weights. The score is the cost weight times how cheap the model is, plus the latency weight times its latency grade, plus the quality weight times its quality grade. The built-in default is 0.4 cost, 0.2 latency, 0.4 quality. Workspace sliders under Admin › Organization, a policy's preferred tier, and the caller's own strategy or quality hint each override the one before; see Routing strategies.

Scores are relative.Each axis is normalised within the current candidate set: the cheapest candidate counts as 1.0 on cost and the priciest as 0, and the 1–5 tiers are stretched the same way. A model's score therefore changes whenever the field changes, after a filter, a failover, or a catalog edit. If every candidate ties on an axis, that axis stops discriminating.

Then two nudges. Learned routing adjustments subtract the measured penalties from the routing signals snapshot, each 0 or below and clamped at 0.30 in total; a model with fewer than 20 samples and any unknown health state are never penalised. An open cooldown can exclude a model, but an exclusion that would empty the field is suppressed and recorded instead. Finally, affinity adds a flat +0.05 to the model that answered the previous turn of the same conversation, within the affinity window of 300 seconds by default. It is a tie-breaker, never an override.

The score picks the model; the reference model is what that pick is compared against when Cloud Score reports what routing saved. It plays no part in scoring. The helper text under Reference model on Optimization settings › Settings reads: What every request is compared against for the savings ledger. "auto" = the cheapest model of the top quality tier among the request's candidates; the client's requested model always wins when it matches.

The first that applies wins, and the source is recorded with the plan. Only enabled models are offered in the select, as gpt-4o — openai style entries, with auto first. Check a decision on the same tab shows the outcome for a pasted request as Reference followed by the model and its source, for example gpt-4o (workspace).

A routine summary of about 1,000 input tokens with 500 expected out. Three enabled models pass Match; no policy filters apply; the caller sends no strategy, so the built-in 0.4 / 0.2 / 0.4 weights are used.