Routing strategies

The five per-request weight presets (auto, balanced, cost, intelligence, latency), how they rank against policies and workspace sliders, and what a strategy never changes.

On this page

What it is

A routing strategy is a name for a preset split of the three scoring weights, cost, latency and quality, that a caller can send with one request. At the Select stage Cloud Score scores every surviving candidate on those three axes and the highest score wins; the strategy decides how much each axis counts for this request. Five names exist: auto, balanced, cost, intelligence and latency.

Match

which enabled models can do the work

Estimate

what each would cost

Policy

blocks, allow and deny lists, budgets

Select

weights resolved, candidates scored

The strategy acts only inside the last box. Those are four of the sixteen pipeline stages, and the stages before Select have already decided which models are even eligible, so a strategy re-orders a field it did not pick. The whole sequence is in How Cloud Score routes a request.

The five strategies

The same five presets appear as chips under Routing strategy on the Playground, with one caption line under the chips that carries the selected chip's hint, and as capitalised tiles under Intelligent routing on Admin › Developer, each with a weights line and a blurb.

The caption text is also the chip's hover title. After a run on a workspace still on the older weighted scorer, the caption shows the weights instead, for example 70% cost · 10% latency · 20% quality. The tile's weights line mirrors the preset the backend applies.
Playground chip	Chip caption	Developer tile	Weights line on the tile	Blurb on the tile	Weights used (cost / latency / quality)
`Auto`	`workspace rules decide`	`Auto`	`workspace policies & defaults`	`Defer entirely to your workspace's routing policies and configured defaults.`	No override; whatever the workspace resolves to
`Balanced`	`cheapest within 3% of the best`	`Balanced`	`40% cost · 20% latency · 40% quality`	`Pin the balanced preset for this request, even where a policy prefers a tier.`	0.4 / 0.2 / 0.4, pinned
`Cost`	`cheapest within 8% of the best`	`Cost`	`70% cost · 10% latency · 20% quality`	`Prefer the cheapest capable model.`	0.7 / 0.1 / 0.2
`Intelligence`	`the best model, cheapest among ties`	`Intelligence`	`10% cost · 20% latency · 70% quality`	`Prefer the highest-quality model.`	0.1 / 0.2 / 0.7
`Latency`	`fastest within 6% of the best`	`Latency`	`10% cost · 70% latency · 20% quality`	`Prefer the fastest model.`	0.1 / 0.7 / 0.2

auto defers, balanced pins

autois not a preset. It means "send no strategy": the request inherits a policy's tier preference and the workspace sliders, and the Playground omits the field from the request entirely. balanced looks like the default split but is an explicit instruction: it pins 0.4 / 0.2 / 0.4 for this request even when a policy prefers a tier or the sliders say otherwise.

Which weights win

Six sources can supply the weights for one request. Cloud Score takes the strongest one that is present and ignores the rest. Read the rail from left (weakest) to right (strongest).

Built-in default0.4 / 0.2 / 0.4

Workspace slidersAdmin › Organization

Policy prefer_tierPolicies

Caller max_latency_mslatency preset

Caller qualitylow, balanced, high

Caller strategyauto falls through

Priority	Source	Where it is set	Weights it supplies
1 (weakest)	Built-in default	Nowhere; applies when nothing else is present	0.4 / 0.2 / 0.4
2	Workspace scoring weights	The `cost`, `latency` and `quality` sliders under `Scoring weights` on `Admin` › `Organization`; they must read `sum = 1.00 ✓` before `Save platform settings` enables	As configured. A stored row that no longer sums to 1.0 is ignored: the request routes with the default and the plan notes `scoring_weights_invalid`.
3	Policy `prefer_tier`	A matching policy on `Policies` whose action prefers a tier	`cost` 0.7 / 0.1 / 0.2 · `latency` 0.1 / 0.7 / 0.2 · `quality` 0.1 / 0.2 / 0.7
4	Caller `max_latency_ms`	A native request that sends `constraints.max_latency_ms` and no `quality`	The latency preset, 0.1 / 0.7 / 0.2 (the value also lowers the request deadline)
5	Caller `quality`	The `Quality` select under `Advanced options` on the Playground (`Auto`, `Low`, `Balanced`, `High`) or `constraints.quality` in a native request	`low` the cost preset · `balanced` 0.4 / 0.2 / 0.4 pinned · `high` the quality preset · `auto` is omitted and defers
6 (strongest)	Caller `strategy`	The `Routing` chips on the Playground, a generated `Cloud Score client` snippet, or `constraints.strategy` on `POST /v1/requests`	The preset named in the table above. `auto` is absent from the map and falls through to priorities 1 to 5.

Only an absent constraint defers

Sending balanced as a strategy or as a quality pins 0.4 / 0.2 / 0.4 over a policy and over the sliders. To let the workspace decide, leave the chip on Auto or leave the field out of the request.

What a strategy never changes

A strategy changes scoring only. It cannot add a model the workspace has not enabled, and it cannot lift a rule that removed one. Every filter below has already run by the time the weights are applied.

Still applies whatever the strategy	Set on
Enabled models only, with the required capabilities and a large enough context window (the `Match` stage)	`Models`, `Integrations`
Policy `block` actions and their block messages	`Policies`
Provider allow-lists and deny-lists (`restrict_providers_allow`, `restrict_providers_deny`)	`Policies`
A forced model (`force_model`) or a caller's `model_override`, which leaves one candidate	`Policies`; the caller
Cost caps: the lower of `set_max_cost_usd` and the caller's `max_cost_usd` (`Max cost (USD)` on the Playground)	`Policies`; the caller
Budgets and the pre-flight budget gate, which cannot be skipped by any caller field	`Budgets`; per-key budgets under `Admin` › `API keys`
AI Security scans at `Guard in` and `Guard out`	`Gateway` › `Guardrails`
Models excluded after a failed attempt (failover re-scores the survivors with the same weights)	Nothing to set; automatic

Scores are relative to who showed up

Each axis is normalised within the current candidate set: the cheapest candidate scores 1.0 on cost, the priciest 0, and the quality and latency tiers (1 to 5) are scaled the same way. Remove or add a model and every other model's score moves. If all candidates tie on an axis, that axis stops discriminating and the other two decide.

Whatever you send is echoed back: the Select trace records strategy next to the weights it actually used, so a policy or slider that took precedence is visible in the same place.

In the product

Term	Where you meet it
Strategy chips	`Playground` › `Compose`, under `Routing strategy`, with the caption line
Strategy tiles	`Admin` › `Developer`, shown while `Intelligent routing` is selected (the `Explicit model` mode replaces them with a model select)
Weights actually used	The `weights` and `strategy` fields in the `Select` trace of the request's drawer on `Traces`; on the Playground, the decision summary in `Details` › `Routing` shows the strategy string or `auto (workspace defaults)` and the `score N.NNNN` badge, but not the weights
Workspace default weights	`Admin` › `Organization` › `Scoring weights`
Tier preference from a policy	A `prefer_tier` action on `Policies`; the `Policy` trace shows the weights it contributed
Quality preset	The `Quality` select on the Playground; `constraints.quality` in a native request
Per-candidate scores	The `Score` and `Δ vs selected` columns of the `Candidates` table in the `Optimization decision` card

Three places set a strategy. All of them send one of the five names, or nothing at all for auto.

Where	What you do	What is sent
`Playground`	Click a `Routing strategy` chip, then `Send`	`constraints.strategy` on `POST /v1/requests`; omitted when the chip is `Auto`
`Admin` › `Developer`	Choose `Cloud Score client`, a language, `Intelligent routing`, then a tile such as `Cost`, then `Copy`	The snippet passes the strategy on every call, for example `client.chat.dexai(..., strategy="cost")` in Python
Your own code, native endpoint	Send `constraints.strategy` with `auto`, `balanced`, `cost`, `intelligence` or `latency`	The `select` trace echoes `strategy` and `weights`

The generated OpenAI-compatible snippet does not send a strategy

With OpenAI-compatible selected on Admin › Developer, choosing a tile only inserts the comment Note: named strategies (<strategy>, …) are native-API-only — switch to the "Cloud Score client" tab to use them. "auto" routes fully. and the snippet always sends model: "auto". Switch to Cloud Score client for a snippet that carries the strategy.

To see two strategies side by side on one prompt:

On Playground, type the prompt in Message, click Cost (caption cheapest within 8% of the best) and Send.
Note the model in the result header, or Model in Details › Usage.
Click intelligence (caption the best model, cheapest among ties) and Send again.
Compare the two runs.
Details › History lists both runs, newest first, each with the model that answered. Details › Routing shows the latest run's decision summary: the strategy string and the score badge.
Read the Optimization decision card in Details › Decision, which appears once the request detail loads.
The Candidates table's Δ vs selected column shows the money each alternative would have cost or saved against the winner.

Example

A routine summary: a prompt of about 1,000 tokens with 500 output tokens expected, and three enabled models that pass Match. No policy prefers a tier and the workspace sliders are at their default, so nothing at priorities 2 to 5 applies, the built-in 0.4 / 0.2 / 0.4 stands, and the strategy alone moves the result.

The cheapest candidate scores 1.0 on the cost axis; the fastest scores 1.0 on latency; the best tier scores 1.0 on quality.
Candidate	Estimated cost	Quality tier	Latency tier
`gpt-5-mini`	$0.001250	4	4
`claude-haiku-4-5`	$0.003500	3	5
`gpt-5`	$0.006250	5	3

Scores as the reason line prints them, to three decimals; the decision summary's score badge shows four.
Strategy sent	Weights used	Winner	What the run shows
none, or `auto`	0.4 / 0.2 / 0.4 (built-in default)	`gpt-5-mini`	0.700, with claude-haiku-4-5 on 0.420 and gpt-5 on 0.400
`balanced`	0.4 / 0.2 / 0.4, pinned	`gpt-5-mini`	0.700, the same field and the same result
`cost`	0.7 / 0.1 / 0.2	`gpt-5-mini`	The cheapest candidate again
`latency`	0.1 / 0.7 / 0.2	`claude-haiku-4-5`	0.755
`intelligence`	0.1 / 0.2 / 0.7	`gpt-5`	0.700

Same summary, three strategies on the Playground

What you do: Send the summary with the chip on auto, then on latency, then on intelligence.
What Cloud Score does: Runs the same sixteen stages each time. Match and Estimate produce the same three candidates with the same estimates; only Select scores them differently.
What you see: Model in Details › Usage reads gpt-5-mini, then claude-haiku-4-5, then gpt-5. The first run's Select reason line reads selected gpt-5-mini (score 0.700), its decision summary says auto (workspace defaults), and after 1,012 input and 486 output tokens its Cost reads $0.001225. The other two decision summaries show the strategy name; the weights they used, 10, 70 and 20 for latency and 10, 20 and 70 for intelligence, are in each request's Select trace on Logs.

The estimates above are pre-call figures from Estimate. Cost in Details › Usage is the measured list price after the call, which is why it differs from the winner's estimate.