Look for separable work
Some workflows combine repetitive cases with difficult exceptions. A routing experiment asks whether a cheaper path can handle a defined subset while the practical API baseline handles the rest. The subset must be identifiable before the outcome is known. Avoid designing the rule around test answers you have already inspected.
Count the branches once
Split original tasks into disjoint branches. Add each branch’s inference and review costs, then add routing overhead and any retained capacity. A task that escalates may incur costs in both branches but must appear only once in final accepted completions. The calculator uses a simpler disjoint-branch scenario; replace it with explicit escalation costs if your workflow retries across branches.
Measure routing mistakes
Report tasks sent down the wrong path, failed escalations and any delay introduced before resolution. Evaluate difficult customer segments separately so aggregate savings cannot hide concentrated failures. Use a protected sample that reflects realistic branch proportions. The cheap model does not need to solve every task; the complete system must meet the agreed policy.
Prefer a reversible rollout
Start with shadow routing or a limited reviewed workflow. Assign the owner who can disable the rule, define incident thresholds and keep the baseline available. Stop if routing complexity, manual review or duplicated operations consume the expected saving. Reassess branch economics when model prices or the production mix change.
Bring to the decision review
Write down the routing inputs that are available before a task is answered, the fallback rule and the owner who can disable it. Separate eligibility rules from outcome scoring to avoid using hindsight. A good review includes both the distribution of branch traffic and the full-system acceptance count. If exceptions are retried across branches, replace the simple calculator assumption with an explicit attempt ledger.
Sources & editorial record
This is Frontier Development’s decision framework. The references below support the general technical concepts; the worked scenarios and procurement questions are our analysis.
References accessed 16 October 2026. No current price, product availability or legal clearance is asserted. Published study findings are attributed above; this guide reports no Frontier Development experiment. Read the comparison method.
Review history and research boundary
Edition 1.1 · 16 October 2026: added claim-level attribution, explicit evidence boundaries and links to the flagship synthesis. Published by Frontier Development. No named external technical reviewer is recorded. This guide provides a decision framework; it is not a Frontier Development experimental result.
Read the primary-study synthesis →Open the architecture tool
Explore a complete synthetic example before using your own inputs.