The Router Is The Interface

Notes on model defaults, trust, and designing AI products that route between different models.

ChatGPT finally removed the model picker. Sort of.

Until yesterday, the old flow required people to select a model that would match the complexity of the work.

My mode of operation was essentially GPT-4o for fast, personal requests, and o3 for technical questions that require grounded reasoning and nuanced analysis.

That choice looked empowering, but in practice, it was a tax. It demanded knowledge about model families that most users did not want to acquire, and it put the burden of risk on the person asking a question.

Now the default is a native router that classifies the query and sends it to the most appropriate model for the question. Fewer levers. Less friction. Cleaner story.

That seems like progress on the user experience end, but what exactly are we looking at here?

Auto is a policy, not a neutral setting.

Defaults are product decisions. A default encodes business priorities, technical constraints, and a worldview about what the average task looks like. The new GPT-5 router is a statement about the type of product ChatGPT wants to be. The message is “trust our router and its implicit policy.”

This works the same way a camera in Auto works.

It will do the right thing in daylight. It will probably do the right thing in a room with even lighting.

But it will struggle with the edge cases, and you only notice them because they matter. Gatherings. Night streets. Backlit stages. The photos you cannot retake.

In AI, the edge cases are more nuanced, and the outcomes are more divergent. People now use LLMs for a wide range of applications. Code that ships. Contracts that bind. Analysis that informs decisions backed by money and reputation.

If the router is a solution for the average user, then the average user is at risk. Miss the route in those moments, and the product feels unreliable, even if the average case looks fine.

The hidden cost of a generic router.

The problem with routers is that they collapse choice. They also collapse context. A single policy now has to read writing, code, math, research, and casual chat. Those tasks do not share the same failure modes. They do not carry the same exact cost of being wrong.

A generic rule can be conservative in areas where it doesn’t need to be, or extremely bold in areas where it needs to show restraint.

The system’s design principle here is simple:

A fixed rule applied across heterogeneous conditions will misallocate its caution and risk because it cannot adapt to local variance in cost, uncertainty, and feedback.

This is a consequence of context-sensitivity in complex systems: when a decision procedure ignores the distribution of situations it governs, its “safe” and “risky” zones will inevitably become mismatched.

Here’s how that collision works in practice.

First, ambiguity. Short prompts hide deep work. “Refactor this function.” “Is this compliant with our policy?” “Summarize this log.” At the surface, all those look like simple requests, but the consequences are not.

Second, drift. Identical prompts get different routes across threads or retries because the surrounding context shifts slightly. New tokens. A change in the timestamp of the system prompt. Or perhaps a change in the load that balances requests to a faster model. The user sees the same text and gets a different class of model (which produces a different answer).

The workarounds seem a bit laughable. For example, OpenAI recommends asking the model to “think hard” if you want to get a more powerful reasoning model for your request. This is not a product pattern that could ever scale.

The low‑level problem: non‑idempotency.

Idempotency is a mouthful, but the idea is simple. Same state, same input, same outcome. For routing, this should be a baseline behavior; in particular, if the visible conversation has not changed, the route should not change. If the route must change, the product should show why.

The problem is that non-idempotent behavior is essentially what LLMs are. This is why all emerging workflows with LLMs, rely on strategies like “retry” and “re-roll”.

AI-native workflows differ significantly from traditional workflows because they lack a stable, deterministic foundation, and reliability is often perceived to be correlated with model size and robustness.

In practice, this means that people will ask for depth even when the task is trivial, and escalate everything because they cannot predict when escalation is necessary.

For AI providers, this is a problem. Asking “What day is Independence Day in the US?” to the most expensive and robust model is an unnecessary explosion of cost.

Why automatic routing still makes sense for the business.

I understand why we got here. Automatic routing is a clean and easy-to-model solution.

It compresses the “expert selection” story by moving the complexity to a system that can be optimized over time.

It is a clear lever on unit economics for a product with massive usage variance. Most sessions are low stakes, and the fast path should handle them, which in turn should result in millions (perhaps billions) of dollars in savings.

It also creates the backbone for a future with many models. You can add domain experts behind the same face and improve coverage without having to teach users which expert they are supposed to call. It also opens the door for more complex architectures where routing is an ongoing decision that changes as the context becomes richer.

That is real value, consistent with how platforms mature.

However, none of that changes the user experience problem. This might solve “picker‑hell” but doesn’t solve “misroute‑hell.”

The only hope is that over time, the router becomes so good and the underlying context becomes so rich that none of this would matter.

Another shake in the paradigm shift.

We are moving from model pickers to policy-based auto pickers and from explicit knobs to implicit contracts. The form factor will settle around a few patterns we already recognize from other tools.

A camera featuring automatic and dependable exposure compensation. A text editor that retains mode settings on a per-project basis. A browser with customizable privacy levels that can be pinned for each site. None of these forces a choice with every action; instead, they let you specify your intent at the appropriate level of abstraction.

The same approach applies to AI products. For each thread, app, or team, we will define a desired quality profile. The router will function within this framework, ensuring consistent decisions. It will escalate issues when the frame signals risk and log its actions to facilitate learning and improvement.

For designers, this prompts new considerations about the router's role, questioning if it should be exposed and how.

In a world of many intelligent models, we now need to consider whether the router is an integral part of the ongoing dialogue and reflect on how the system understands the task and what’s at stake.

It seems that the trend is pushing us towards hiding, but maybe we should avoid the temptation to hide everything.

This is still an emerging space, and purposely designing to avoid re-learning might create more resistance than going with the tide and accepting that a new paradigm requires new ideas and new ideas require learning new concepts.

Closing Thoughts

Automatic routing is the right direction. It simplifies the story and unlocks new architectures behind the scenes. It also replaces a visible choice with an invisible contract, but the challenge is that if the contract is brittle, the rest of the product carries the cost.

While the solution may not be immediately clear, making the router observable appears to be a wise strategy.

Routing policies should be clear and scoped, and patterns should be devised to maintain route behavior stable, transparent, and interpretable.

In practice, this means that I shouldn’t be wondering if the right model is answering my question, but rather have full visibility into what model I am talking to and why my queries were routed to that model.

By doing this, automatic routing becomes a feature that allows users to delegate and understand the trade-off between precision and speed. It builds trust. It makes the system reliable and efficient. Good interfaces accomplish this.