The Most Expensive Model Is Not Always the Fastest Route

A developer has released an open-source Codex skill called Adaptive Model Router that dynamically assigns subtasks to the most cost-effective AI model, rather than always using the strongest or cheapest option. In a 14-case routing regression, skill-guided runs scored 14/14 against the routing oracle, while unguided runs scored 5/14 and 6/14, though the developer cautions the benchmark is not an independent holdout. The project is MIT licensed and available on GitHub.

For a while, my default response to an important Codex task was simple: select the strongest model, increase reasoning effort, and let it handle everything. That sounds conservative. It is often inefficient. The strongest model may reconsider decisions that have already been approved. Mechanical edits inherit an oversized context packet. A tiny deterministic change waits behind an orchestration step that costs more than the work itself. The route becomes expensive in tokens and slow in elapsed time, even when the final diff is straightforward. The obvious reaction—send everything to the cheapest model—fails for the opposite reason. Ambiguous work is more likely to require retries. Review becomes expensive. The strong parent eventually has to reconstruct the context and redo the decision. The real optimization target is not the cheapest call. It is the cheapest complete accepted route . I initially divided tasks into “easy” and “hard.” That was too subjective to be useful. A better question is whether the decisions and correctness mechanism are frozen. Consider four tasks that can all be described as “produce some files”: The output format does not tell us which model is sufficient. The uncertainty does. The first and fourth tasks have closed sets, frozen rules, and deterministic verification. They are good candidates for inexpensive execution. The second requires cross-source reconciliation. The third still contains a debugging decision. Giving all four tasks to the same tier wastes either credits or retries. I ended up with four broad routes: This is deliberately not a model leaderboard. A lower-cost model can be the correct choice for one stage without being the correct owner of the entire task. The router preserves the parent model and effort selected by the user. It separates work into typed stages—collect evidence, decide, execute a frozen contract, or execute while a mechanism remains open—and assigns only the unresolved stage. A cheap worker is not free. A useful estimate includes: task packet + worker execution + verification + probability of fallback × fallback cost + duplicated context This is why a one-line CSS change should usually remain direct. It is also why a large frozen mapping may be worth delegating even when it spans multiple files: the task packet is amortized and the checker can validate the entire set. I packaged the policy as an open-source Codex skill called Adaptive Model Router and created a 14-case routing regression. It includes tiny edits, finite mappings, cross-source evidence, async races, long-context synthesis, and high-consequence decisions. Two skill-guided runs scored 14/14 against the routing oracle. Two unguided comparison runs scored 5/14 and 6/14. Those numbers need a strong caveat: this is a development regression. The cases informed the router. It is not an independent holdout, and it does not prove universal improvements in end-to-end quality, credits, tokens, or latency. It shows that the written policy made route selection more consistent on the boundaries represented by the test. The repository includes the prompts, schema, oracle, scorer, and raw outcomes so the claim can be inspected rather than repeated as marketing. The project is MIT licensed and distributed as a Codex plugin marketplace: codex plugin marketplace add cyc981565058-cpu/adaptive-model-router codex plugin add adaptive-model-router@adaptive-model-router Source and benchmark: https://github.com/cyc981565058-cpu/adaptive-model-router https://github.com/cyc981565058-cpu/adaptive-model-router The next useful step is not another polished benchmark tuned on the same cases. It is independent task evidence: acceptance quality, retries, raw tokens, credits or API cost, and elapsed time across different parent models and reasoning efforts. If you have a task where the router consistently selects a model that is too weak, too strong, or slower after verification is counted, that counterexample is more valuable than a generic success story. Disclosure: I maintain the linked project. This article was drafted with AI assistance, then reviewed against the public repository, raw benchmark outputs, and platform guidelines.