Lovable Model Routing: Why Output Quality Has Slipped for Builders

What changed

Lovable no longer sends chat requests to a single model. It routes by task – a smaller model for routine edits, a larger one for complex refactors, presumably more for planning and tool use. From a platform perspective, that's reasonable: faster, cheaper, more scalable.

From a builder's perspective – someone who spends hours a day in the Lovable chat – output quality has noticeably slipped in three areas.

1. Task understanding

You used to be able to send a half-baked prompt ("make this consistent with the rest of the page") and the model would pull context from recent messages and the codebase. Today it's a hit-or-miss game:

• Small edits seem to land on a lighter model that no longer resolves implicit context reliably.
• Ambiguous prompts are taken literally more often than interpreted.
• Clarifying questions come less often and at the wrong moments – trivia instead of the actual missing detail.

The workflow consequence: builders have to make explicit again what the model used to infer on its own.

2. Effective context window

The nominal context window is large. The effectively used one feels smaller than it did earlier this year:

• References to files mentioned two or three turns ago get "forgotten" more often.
• In longer threads, the model proposes solutions that were already rejected in the same session.
• Cross-file consistency ("rename this everywhere") breaks down earlier than before.

Likely cause: routing doesn't necessarily keep follow-ups on the same model. Every model switch is a de-facto context loss because internal caches and tool state don't transfer one-to-one.

3. Proactive recommendations in chat

The point that hurts the most: in-chat suggestions.

• Before: "You just did X – want to also do Y, otherwise Z will break?" – concrete, codebase-aware, often exactly the right next step.
• Now: more generic hints, frequently at best-practices level, with no real connection to what's actually happening in the repo.

For builders using Lovable as a pair programmer, that was one of the core values. When recommendations become interchangeable, the tool degrades into an execution engine – a shame, because the planning layer is the more expensive lever.

Why routing still makes sense

Fair point: multi-model routing isn't a mistake, it's the state of the art. We've made that case ourselves in the Sakana Fugu article and in the Agent Harness category. Cost and latency are hard to control otherwise, and for 80% of requests a smaller model is simply enough.

The problem isn't that routing happens, but how transparently and how much context is lost along the way.

What builders can do right now

Until the platform catches up, discipline helps most:

1. Make prompts explicit. What used to be implicit context belongs in the prompt now – referenced file, intended convention, boundary to neighbouring code.
2. Append a reflection sentence. A tip from the Reddit community that reproducibly improves quality for us: end every non-trivial request with "Please review the request and the code thoroughly, and make suggestions or ask questions if needed." (in German: „Bitte überprüfe die Anfrage und den Code gründlich und gib bei Bedarf Vorschläge und stelle Fragen."). It forces the model into a review mode before it writes code – catches a large share of hallucinations and false assumptions.
3. Keep threads short. Start fresh per topic instead of running multi-hour mega-sessions. Context drift stays smaller.
4. Persist key decisions in the repo. Memory files, READMEs, short comments – anything that outlives the chat gains value.
5. Choose tools model-aware. For complex refactors, cross-check with Claude Code or another harness – see our Agent Harness comparison.

What we'd like to see from Lovable

• Model indicator in chat. Which model answered? Optional, small, but visible.
• "Stick to model" toggle. For builders who want consistency within a thread, even at a higher cost.
• Better context hand-off between routing hops. So a model switch doesn't feel like a memory reset every time.
• Sharper proactive recommendations again. Rather less often, but codebase-specific again.

Bottom line

Multi-model routing is the right architecture – but the current implementation is costing builders measurable output quality. Task understanding, effective context window, and AI recommendations were better a few months ago. Until that changes, "prompt more explicitly" is the new builder hygiene.

Sources & further field reports

• Blink Blog: Lovable's Creative Engine Update – Multi-Model Routing (May 2026) – frames multi-model routing as a platform shift.
• Facebook group "Lovable AI": Anyone noticed lovable being 'dumber' lately? – builder discussion on the perceived drop in output quality.
• socialanimal.dev: Lovable App Limitations – 15+ Components Break – documents context drift and regressions in longer sessions.
• Lovable Changelog, Opus 4.6, GPT-5.5 Early Access – primary sources for the models feeding the router.
• Reddit r/lovable: Lovable is burning through credits and failing on simple tasks – community thread with the reflection sentence workaround recommended above.

Update watch

We're actively tracking this and will ship a follow-up as soon as task understanding, context window, and in-chat recommendations feel back at the previous level. From our perspective it's only a matter of time – multi-model routing is the right bet, the tuning phase just needs a few iterations. If you have your own observations: let us know.