Most AI-powered tools are built on a single model from a single provider. That is the path of least resistance and it works fine until it does not. Provider outages, rate limits, model deprecations, and performance regressions on specific task types are all real failure modes that a single-provider architecture handles badly: the tool either goes down or degrades with no fallback.
The deeper issue is that different tasks genuinely benefit from different models. Repository-level analysis that requires reading large codebases and reasoning across many files wants a model with strong context handling and reliable tool use. Quick lookups and lightweight queries want something faster and cheaper. Treating every request the same way because you are locked to one model means every task is handled by a model that is good at some of those tasks and suboptimal at others.
This month we shipped multi-LLM routing for /Slash, with OpenRouter as the first external provider option. The architecture now routes requests to different models based on task type, which means the assistant can use the right model for what it is actually being asked to do rather than defaulting to one provider for everything.
The implementation work was mostly about building clean adapters so provider-specific differences do not surface in the product. Different providers have different request formats, different response structures, different handling for tool calls, and different edge cases around context length. A good multi-provider architecture abstracts all of that so the product layer does not have to care which provider handled a specific request. Getting those adapters right is where most of the complexity lives.
The visible benefit is better reliability. If a provider has a degraded period, the system can route around it. The less visible benefit is that we can now benchmark model performance per task type and improve the routing logic over time based on real outcomes rather than assumptions about which model is best in general.
This is the kind of infrastructure work that does not ship as a feature but changes what the product can do. /Slash is available in early access at useslash.dev.