Lovable, the AI-powered app-building platform, is removing the dropdown that lets users pick which model builds their software. In a post on the company’s engineering blog, Lovable describes replacing that choice with what it calls a control plane: a system that decides, task by task, which model should handle each step of a build and switches automatically as the work progresses.
The reasoning is that ranking models on a single leaderboard misses how unevenly they perform. Some are strong debuggers and weak designers. Others hold a coherent design vision but lose track of a long, multi-file build. Lovable says it studies where each model tends to fail, then shapes the prompts, tools and project context it feeds that model to compensate, rather than giving every model an identical interface.
That tuning extends to mid-task recovery. When a build stalls, Lovable’s system has to judge whether the fix is a different tool, more context, a plan change or an entirely different model reasoning through the problem. The company says a model swap only happens when the expected gain outweighs the cost of losing the cached history a long build accumulates, since restarting that context from scratch can make an agent perform worse, not better.
Lovable backs the approach with one internal comparison: a newer model completed builds roughly 15% quicker than the version it replaced, needed about 40% fewer turns, and scored two to three percentage points higher on the company’s own evaluation, numbers Lovable says justified promoting it. The post does not name the models involved or publish the underlying benchmark data.
The company also disclosed that it now trains its own smaller models for recurring jobs such as routing requests, summarizing agent output and writing commit messages, and says those models already carry a substantial slice of production traffic. Outside models, Lovable says, can still displace its in-house ones if they score better on the same internal tests.
This is a vendor arguing for its own architecture, and the tradeoff it does not spell out is the one that matters most to a paying customer. A control plane that reroutes work between models on its own judgment also means a developer cannot reliably reproduce a prior result: the same request run twice, days apart, may be handled by two different models with no version pinned and no disclosure of which one did the work. Lovable presents that as adaptive engineering. For a team debugging a regression or documenting how a feature was built, it is an audit trail that no longer exists.
The self-trained models compound that problem rather than separate from it. Lovable’s own evaluators decide when an outside model beats an in-house one, and those same evaluators determine how much traffic gets routed to models Lovable owns instead of models it pays a third party to call. That is a quality judgment and a margin decision made by the same team, with no outside benchmark cited to confirm the scoring is unbiased.
Lovable is not alone in treating routing as the product rather than a feature bolted onto one. Nvidia shipped an open-source router called NeMo Switchyard this week making a similar bet on task-based model selection, and Microsoft has started substituting its own models inside GitHub Copilot rather than defaulting every call to OpenAI.
Developers evaluating Lovable or a comparable agent platform should ask vendors directly whether routing decisions can be logged, pinned to a specific model, or disabled for workloads that require reproducible output.
Lovable published this account of its model-routing architecture on its engineering blog; the source file carried no listed publication date.
