The Most Expensive Model Is Not Always the Fastest Route

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.

The boundary that mattered

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”:

1. Implement nine approved state mappings and verify every value.
2. Reconcile conflicting product rules spread across fourteen documents.
3. Fix an asynchronous race after the expected behavior has been approved, but the patch mechanism remains open.
4. Compile approved permission rules into a truth table with an exact-set checker.

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.

A quality-first routing policy

I ended up with four broad routes:

• Direct parent or tools for one or two known deterministic actions.
• Luna for frozen rules, bounded context, mechanical execution, and exhaustive checks.
• Terra for cross-source synthesis, ordinary integration, wider context, and open debugging.
• Sol or the current parent for ambiguous planning and consequential decisions involving permissions, privacy, money, compliance, science, or production.

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.

Delegation also has a cost

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.

What the first regression says—and does not say

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.

Try it

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

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.