They should use both, but routing should be guided by measured quality, not by price alone. Fixed budgets help contain runaway spend, while value-based routing lets teams choose cheaper models only when outcomes stay acceptable. That combination avoids both tokenmaxxing and the mirror-image mistake of starving workloads.
When value-based routing should supplement fixed budgets
Value-based routing works best when the organisation can measure outcome quality in a way that is stable enough to compare models. If the quality signal is noisy, delayed, or easy to game, routing decisions will chase the wrong target and create hidden drift. Fixed budgets still matter because they put a ceiling on spend even when routing logic is imperfect.
The practical distinction is that budgets manage exposure, while routing manages allocation. A budget says how much you are willing to spend; routing says when the cheaper option is still good enough for the task. That means routing should be treated as a control layer above cost, not a replacement for cost discipline.
For teams operating multiple model classes, this is often the least-bad compromise. Hard budgets prevent runaway usage, while measured-value routing allows lower-cost models to absorb work that does not need premium capability. The key is to make the routing threshold task-specific, because a model that is acceptable for summarisation may be unacceptable for extraction, policy analysis, or user-facing decisions.
Where value-based routing breaks down
Routing fails when “value” is defined too broadly or too vaguely. If the team only tracks average quality, latency, or cost per call, it can miss important edge cases where a cheaper model is acceptable most of the time but unsafe or unreliable on high-impact requests. It also breaks down when the routing rule optimises for the easiest metric to improve rather than the outcome that matters.
This is why price-only routing creates a false sense of efficiency. Cheap models can look attractive in dashboards even while they increase rework, escalations, and exception handling. In that situation, the organisation has shifted cost from inference to human review, which is not a savings unless the total workflow improves.
A better design is to compare models against the same acceptance standard for the task and then route only when the cheaper model stays within tolerance. That keeps the decision anchored to business value, not to model fandom or procurement pressure.
How to combine spend control with outcome control
The strongest operating model is two-layered: a fixed budget for financial guardrails and value-based routing for per-request selection. The budget prevents unbounded spend growth, while the router chooses the least expensive model that still satisfies the quality bar for the specific workload.
That approach works only if teams define what “acceptable” means before deployment. For some workloads, acceptability can be measured with automatic scoring, retrieval accuracy, or task completion rate. For others, especially user-facing or regulated workflows, acceptance may need sampled human review and escalation rules rather than fully automated routing.
It also helps to separate routine traffic from sensitive traffic. Routine requests can tolerate a more aggressive cost optimisation policy, while high-consequence requests should default to stricter model requirements and narrower routing freedom. The point is not to eliminate cheaper models, but to keep the routing logic proportional to the decision risk.
Risk and Threat Considerations
Routing policy can become a control failure if it rewards low cost over reliable output, because then the system is incentivised to choose the cheapest model even when it increases misclassification, unsafe completions, or hidden operational load. The risk is not only degraded answer quality, but also the accumulation of avoidable exceptions that teams later treat as normal.
Failure mechanism: The routing threshold drifts from outcome quality toward proxy metrics such as token spend, average latency, or volume, so the cheaper model is selected in situations where it cannot consistently meet the workload’s true acceptance standard.
Impact: Organisations can under-serve critical tasks, increase human rework, and create inconsistent service quality across requests, which makes both cost control and governance harder to defend.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Routing policy needs a defined risk appetite and cost-quality trade-off. |
| PR.DS-01 — Data-at-rest is protected | Model routing affects how sensitive prompts and outputs are handled across services. | |
| GV.OV-01 — Performance Evaluation | Outcome-based routing depends on measurable quality and continuous evaluation. | |
| Recommendation — Set routing thresholds to reflect approved risk tolerance and quality targets. Protect sensitive model inputs and outputs according to workload sensitivity. Monitor model performance against task-specific quality metrics before shifting traffic. | ||
| ISO/IEC 27001:2022 | A.5.36 — Compliance with policies, rules and standards for information security | Value-based routing needs enforced policy boundaries for acceptable model use. |
| A.8.9 — Configuration management | Routing thresholds and budget controls are configuration that must be managed carefully. | |
| Recommendation — Define routing policy limits and verify teams follow them consistently. Treat routing rules and spend guardrails as controlled configuration. | ||
Practitioner Guidance
What to prioritise: Establish the acceptance metric first, then tune routing around it. If the model choice cannot be justified against an observable quality threshold, the routing rule is too loose.
What to measure: Track cost alongside downstream correction rate, escalation rate, and outcome quality by workload class. A routing rule is only working if lower spend does not produce disproportionate rework.
Decision rule: Use fixed budgets as the upper bound, but allow value-based routing only where the task has a dependable success signal and the failure cost is understood. If either is missing, default to conservative model selection and tighter review.
Practitioner takeaway: The goal is not to choose between budgets and routing, but to make routing accountable to quality so cost reductions do not quietly turn into hidden delivery risk.
Related resources from NHI Mgmt Group
- How do organisations decide when to use model routing instead of a single fixed model for agents?
- When should organisations use adaptive or risk based MFA instead of a fixed authentication challenge?
- When should organisations use a conservative hash-based signature instead of a lattice-based signature?
- Why do organisations need configurable model routing instead of a single preferred LLM?