AutoRoute Picks the Right Codex Model So You Stop Burning Tokens on Button States

theme: channing-cyan

Here's the situation.

Lately I've been using Codex on a project and ran into a very real problem: a single account has several models, all with impressive-looking names, but every time I still have to choose which one to use. Especially after gpt-5.6 came out, I kept forgetting to pick and just defaulted to gpt-5.6-sol high.

Changing a button's loading state with the strongest model is a bit wasteful. It's all RMB burning away. 😄

But when I hit a cross-module state sync bug, I'd skimp on quota and force a lightweight model to retry over and over, and all the time ended up wasted on reruns.

More and more models, and the choice feels more and more like a puzzle. Sometimes I forget to choose, sometimes I choose imprecisely.

So I built AutoRoute, a routing skill for Codex. It doesn't write code for you, and by default it doesn't touch your running session either — it first analyzes the task, recommends a more suitable model and reasoning effort, and prepares the switch command; it only acts when you explicitly tell it to switch.

You can think of it as a steering wheel.

You just say what you want to do, and it helps you decide whether to handle it quickly with a small model or hand the task to a stronger model for a thorough pass.

Installation and Usage

Once installed, Codex will automatically decide when to use it based on the skill description — as long as your words carry a meaning like "which model should I use" or "help me route this", it will activate on its own, no commands to memorize. If you want to be more explicit, you can also call $autoroute, same effect.

So everything happens inside the Codex conversation; you don't need to remember any script paths or open a separate terminal. For example, just say:

Which model should I use for this task? Add a loading state to the Button component.

It will tell you the recommendation and reasoning.

Three Modes

AutoRoute has three modes, defaulting to auto. The names sound intimidating, but the differences are simple:

suggest: Only talks. You ask "which model for this task", it replies with a suggestion and reasoning, and that's it.
manual: The most conservative, directly uses your current model and reasoning effort for the recommendation, guaranteeing it won't touch any of your existing settings.
auto (default): Gives a suggestion and also prepares the command for a new session.

The key point is, even in auto, it stops at "suggestion + prepared" by default and won't secretly execute. If you don't give the word, it touches nothing.

After you give the word, there are two paths, corresponding to two explicit flags. --run is the automated version of the old approach: it directly opens a new Codex session for you with the recommended configuration; --session is a capability added in the new version — directly switch the current session. Previously, a Skill indeed couldn't touch an already-running Codex conversation and could only open a new session; now it will find the terminal where your current Codex is running, type the /model and /effort commands for you, and switch the conversation in front of you to the recommended model. Both flags require your explicit word before acting, and once specified they execute directly, without asking for confirmation midway. If --session fails to switch (for example, it can't find the terminal), it doesn't force it and falls back to the old method of handing you the new session command.

Six-Dimensional Scoring

This isn't simple keyword matching.

AutoRoute looks at a task from six angles: complexity, scope of changes, reasoning demand, risk, context size, and length of subsequent iteration. Each dimension is scored 0 to 5, then synthesized into a task level, which then separately determines the model and effort.

Model and reasoning effort are chosen separately. Some tasks aren't complex but need a few extra steps of thought; maybe the model doesn't need to change, just bumping effort up one notch is enough. Conversely, some task descriptions look short, but behind them lie production data, compatibility, and rollbacks — then both model and effort should be more cautious.

And effort now supports seven levels: none / low / medium / high / xhigh / max / ultra. Different models support different levels, and AutoRoute will automatically pick the closest supported level.

Adaptive Upgrading

It adaptively upgrades based on runtime signals. Increasing test failures, too many retries, a sudden spike in changed files, or a single task spanning several languages can all raise the score, triggering a higher effort or model tier. For example, when refactoring a sync layer, after two consecutive failures, three retries, and 14 changed files, the recommendation upgrades from an ordinary task to gpt-5.6-sol with high.

It's a lot like a reliable colleague reminding you at your side: things have already gotten more complicated than you first thought, don't keep pushing with the original config.

A Few Details I Find Quite Thoughtful

Model availability isn't taken for granted. On first run, or when the cache exceeds 15 minutes, AutoRoute does a lightweight probe. When the probe is blocked by permissions or sandboxing, it doesn't arbitrarily declare a model unavailable; instead it keeps the directories it already discovered and continues routing, marking probe_status=blocked in the output. These kinds of details aren't noticeable day-to-day, but when a provider flakes out or a test environment lacks a full model catalog, they save you from quite a few pitfalls.

Refreshes on every Codex launch. The repo includes a codex-with-autoroute wrapper script that replaces the system codex command, re-probing model availability every time Codex starts. You can also add a shell alias yourself.

Configuration is flexible too. You can set the default mode, cache path, etc. via ~/.codex/autoroute.json, and you can pass --workload to explicitly specify a workload type (simple / everyday / debugging / architecture / research / long_horizon / high_risk), making routing more precise.

A Few Real Routing Examples

I ran several types of tasks through it, and the routing results were very clear.

Add loading state to a button: AutoRoute recommends gpt-5.6-luna, reasoning effort low.
Build a settings form with validation: recommends gpt-5.6-terra, reasoning effort medium.
Debug a cross-page, intermittent React state sync issue: recommends gpt-5.6-sol, reasoning effort high.
Design a collaborative editing architecture with conflict resolution, persistence, and migration plan: recommends gpt-5.6-sol, reasoning effort high.
Multi-quarter repository modernization plan (long-horizon task): recommends gpt-5.2, reasoning effort high — it's better suited for long-horizon work; if it's not in the catalog, it falls back to another model matching the task level.

The Ugly Truth Up Front

Of course, it's not a fortune teller. The clearer the task description, the more reliable the scoring. If you just toss it a line like "fix the system", it can only make a conservative judgment based on limited clues.

Also, automatic routing doesn't necessarily mean saving money. Unavailable models, task failures, and back-and-forth retries will all pull costs back up. What you should really look at is success rate, result quality, total tokens, retry count, and time spent. The repo includes evaluation scripts so you can run comparisons yourself — don't rush to conclusions based on just one or two tasks.

Finally

I think AutoRoute is best suited not for someone who uses just one model every day with very fixed tasks. It's more for this kind of state: the project keeps growing, model choices keep increasing, tasks are sometimes small fixes and sometimes suddenly cross-module investigations. You don't want to redo the judgment from the model list every time, but you're also not willing to throw every job at the most expensive one.

Hand the model choice to rules, keep the final decision for yourself.

That's the starting point for why I built this skill.

If you're also using Codex, you're welcome to install it and give it a try. Run a few tasks you're familiar with, see if its judgments match your intuition, and then decide whether to wire it into your daily workflow.

A tool shouldn't add new burdens.

It just needs to help you think a little less in that moment when you hesitate: "Which model should I actually use this time?"

That's all. Since you've read this far, if you find this project somewhat useful, feel free to drop a star on GitHub, and you're also welcome to raise the routing problems you encounter. One person's rules always have blind spots; only by running more kinds of real tasks will AutoRoute become more and more like a tool that genuinely helps.

Thank you for reading to the end. See you next time.

Project address, https://github.com/you-want/AutoRoute