AI·4 min read
Routing work across models — with a way out
Different steps need different models. And any provider can fail. How task routing and fallback keep runs moving.
Planning a feature, writing the code and summarising a long conversation are different jobs. Treating them as one “AI call” wastes money on easy tasks and quality on hard ones. So every step in MoboStudio AI asks a router for a task class instead of a model.
planner → REASONING
coder → CODING (tool use required)
quick jobs → FAST
summaries → FAST
everything else → DEFAULTFallback is part of the design
Candidates are tried in order: the task’s routes, then the default routes, then any other enabled model on a usable provider. A call that fails with a rate limit, an overload, a network error, a bad key or an unknown model moves to the next candidate. Once a model answers, the run stays on it for consistency.
Provider-neutral by construction
Adapters for Anthropic, OpenAI, OpenAI-compatible endpoints and Google Gemini speak one provider-neutral message format. Provider keys are encrypted at rest and decrypted only inside the router, per run. Nothing else in the system needs to know which company answered.
Models will keep changing. Designing for that is cheaper than rewriting for it.