Token scarcity calls for work design, not a universal model
Choose work routes before comparing models
The first choice is to divide work into recognizable task types, rather than designate a single model as the default. NIST asks organizations to document the objectives and use context of AI, establish risk tolerances, and define the specific tasks and methods. This provides a useful roadmap: for each task, specify the desired outcome, required context, error impact, and owner. A predictable classification or fixed text step can therefore follow a lighter route; a task with high decision impact follows a more robust route or receives human review. This is a design recommendation based on those documentation requirements, not a prescription that one model tier is always correct.
Make escalation part of the task
Token usage only becomes manageable when an exception does not silently continue through the same workflow. Therefore, define in advance which signals cause a task to escalate: missing context, an uncertain result, exceeding a cost ceiling, or an outcome that must first be assessed by a human. NIST states that knowledge limits and the intended use of system output must be documented; the same source also describes how design decisions must take socio-technical implications into account. The practical consequence is that a team selects not only the model route, but also who handles an exception and which follow-up decision is logged. This keeps the decision auditable even when the route changes.
Measure the route by its total consequences
Measuring only cost per request is too narrow. The NIST playbook passage calls for examining and documenting potential costs, including non-monetary costs, of expected or realized AI errors and system functioning, linked to the organization’s own risk tolerance. Therefore, for each task route, measure at least consumption costs, error impact, rework, and decision quality at a preselected evaluation point. Stanford research describes multi-stage language model programs as modular pipelines and focuses prompt optimization on a downstream metric; this supports the idea that a pipeline should be assessed as a whole, not merely prompt by prompt. The evidence does not show which metric or model route will prevail for your organization. Therefore, use this decision log: for each task, record the objective, owner, selected route, escalation signal, costs, error impact, rework, decision quality, and the decision after evaluation. This approach applies to designing and evaluating AI workflows based on the supplied passages; it does not provide individual legal, financial, procurement, or professional advice, and does not replace a domain-specific risk assessment.
