The simplest way to build an AI product is to pick a provider, get an API key, and write code against it. It is also the decision that generates the most rework, because the thing you bet on changes underneath you every few weeks.
Apex routes across Anthropic, OpenAI, Google DeepMind, Perplexity, Meta, Mistral, xAI, Cohere and several specialist providers. Here is the reasoning, including the costs.
What a single-provider bet actually commits you to
It commits you to that provider's outages, which are not rare and which take your product down with them. It commits you to their deprecation schedule — when a model retires, you migrate on their calendar, not yours. It commits you to their pricing, with no leverage and no alternative. And it commits you to their capability profile: every model has tasks it handles unusually well and tasks it handles poorly, and a single-provider architecture silently accepts the weak spots.
None of these are hypothetical. Every one of them will happen inside a normal year of operating a production system.
What routing means concretely
A routing layer sits between your application and the providers. The application expresses a task — "extract these fields," "draft this reply in the customer's voice," "reason through this scope and flag risks" — and the router decides which model receives it.
The decision weighs three things.
Capability fit. Reasoning-heavy work goes to reasoning models. High-volume extraction goes to fast, inexpensive models. Long-document synthesis goes to large-context models. This is the largest source of quality gain and the one most single-provider systems leave on the table.
Cost. The price difference between the strongest and the adequate model for a given task is often more than an order of magnitude. Nobody should pay frontier prices to reformat a date.
Latency. An interactive request and a batch job have completely different tolerances. Routing lets you spend latency budget where a person is actually waiting.
The part that is genuinely hard
Routing is not free, and vendors who present it as a simple abstraction are skipping the difficult half.
Prompts are not portable. A prompt tuned for one model family often underperforms on another. Real routing requires per-model prompt variants and an evaluation harness that catches regressions when you change them.
Capabilities are uneven. Structured output, tool calling, streaming behavior and system-prompt handling all differ. The abstraction layer has to normalize these without flattening away the features that make a given model worth using.
Evaluation becomes mandatory. You cannot route on vibes. You need a per-task test set with graded outputs, run against every candidate model, refreshed when models change. This is the actual cost of routing, and it is ongoing.
Why we pay that cost anyway
Because the evaluation harness is not overhead — it is the asset. Once you have a graded test set for your real tasks, you can answer questions no single-provider shop can: which model is best for this specific job, what a change actually cost you in quality, and whether a new release is worth adopting. You find out in an afternoon rather than in production.
The second reason is compounding. When a materially better model ships, a routed system adopts it by changing a routing rule and rerunning evaluations. A single-provider system waits for its provider to catch up, or undertakes a migration project.
What this means if you are buying rather than building
Ask a vendor which models they use. If the answer is one, ask what happens during that provider's next outage, and what their migration plan is when a model they depend on retires. The quality of those two answers tells you whether you are buying a product or a wrapper.