"Which model are we actually using?" The honest answer is that it depends on the task — and that's deliberate.
One of the more common questions we get, from both individual users and enterprise teams evaluating the platform, is some version of: "which model are we actually using?" The honest answer is that it depends on the task — and that's a deliberate design choice, not a dodge.
Different underlying models are better at different things, and this isn't a minor detail — it's one of the most consistent findings across the whole field. Some models are stronger at long-document reasoning and holding complex context across a large file. Some are faster and meaningfully cheaper for simple, high-volume lookups where speed matters more than depth. Some handle vision tasks — reading a drawing, a satellite image, a scanned form — better than others. Some are specifically stronger at code.
Locking an entire platform to a single model means accepting that model's specific weaknesses on every single task it's asked to do, forever — including the tasks it happens to be bad at. For a platform built to serve 14 different industries, each with its own mix of task types, that tradeoff compounds badly. What's optimal for a quick Finance-copilot lookup is rarely optimal for a long, document-heavy Legal-copilot clause review.
The Model Router exists to make that tradeoff go away. Before a request is handled, the router evaluates it along several dimensions: the domain it belongs to, its complexity, its sensitivity to cost, and its risk profile — how much accuracy and caution the specific task genuinely requires. Based on that evaluation, the router selects the model best suited to that specific combination, rather than defaulting to one model for everything.
This happens automatically in Auto mode, which is the default across the platform. The router's job is to make the model choice invisible when it doesn't need to be visible — you ask a question, you get an answer, and the right model was chosen behind the scenes to produce it.
Automatic routing isn't always what a user wants, and the platform doesn't force it. If you know exactly what you need — a specific model for a specific reason, whether that's a particular strength, a particular cost profile, or simply consistency across a long working session — you can select that model directly instead of leaving it on Auto. The router doesn't disappear in that case; it simply defers to your explicit choice.
The Model Router is often described as a cost-and-performance optimization, and it is that. But the deeper point is independence. Because the platform was built around routing from day one rather than a single default model, adding a new model, adjusting how tasks get routed, or shifting away from a model that's no longer the best fit doesn't require rebuilding anything. The platform adapts as the model landscape shifts — and it shifts constantly — without every user having to notice or care.
You're never stuck with one vendor's tradeoffs across every kind of work you throw at the platform. That's the whole point of the router existing in the first place.