The Most Expensive Model Is Not Always the Fastest Route

<p>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.</p> <p>That sounds conservative. It is often inefficient.</p> <p>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.</p> <p>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.</p> <p>The real optimization target is not the cheapest call. It is the cheapest <em>complete accepted route</em>.</p> <h2> The boundary that mattered </h2> <p>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.</p> <p>Consider four tasks that can all be described as “produce some files”:</p> <ol> <li>Implement nine approved state mappings and verify every value.</li> <li>Reconcile conflicting product rules spread across fourteen documents.</li> <li>Fix an asynchronous race after the expected behavior has been approved, but the patch mechanism remains open.</li> <li>Compile approved permission rules into a truth table with an exact-set checker.</li> </ol> <p>The output format does not tell us which model is sufficient. The uncertainty does.</p> <p>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.</p> <h2> A quality-first routing policy </h2> <p>I ended up with four broad routes:</p> <ul> <li> <strong>Direct parent or tools</strong> for one or two known deterministic actions.</li> <li> <strong>Luna</strong> for frozen rules, bounded context, mechanical execution, and exhaustive checks.</li> <li> <strong>Terra</strong> for cross-source synthesis, ordinary integration, wider context, and open debugging.</li> <li> <strong>Sol or the current parent</strong> for ambiguous planning and consequential decisions involving permissions, privacy, money, compliance, science, or production.</li> </ul> <p>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.</p> <p>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.</p> <h2> Delegation also has a cost </h2> <p>A cheap worker is not free. A useful estimate includes:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>task packet + worker execution + verification + probability of fallback × fallback cost + duplicated context </code></pre> </div> <p>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.</p> <h2> What the first regression says—and does not say </h2> <p>I packaged the policy as an open-source Codex skill called <strong>Adaptive Model Router</strong> 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.</p> <p>Two skill-guided r