Lovable’s agent mode is called Build mode now. The AI app builder at lovable.dev states the rename in a single parenthetical sentence, and the page carrying it still answers at the old name’s address: docs.lovable.dev/features/agent-mode.
Lovable’s agent mode is now Build mode, and its chat mode is now Plan mode. Build mode is active unless you switch to Plan mode, and it is the mode that writes code. Lovable’s documentation states both renames on 2 September 2026, and its changelog announces only one of them.
Every fact below comes from Lovable’s own documentation, glossary, changelog and two 2025 announcement posts, all read on 2 September 2026 and quoted as they were written. Where two of those pages disagree, both appear here with the date each one carries. Pages on this site that already own a question are linked instead of answered a second time. This article opened no Lovable account and switched no mode on, so it reports what the documentation says and not how either mode behaved in practice.
That naming gap is why the first page of results is a year behind. The two Lovable posts that rank for the phrase were published in June and July 2025, and both call the feature Agent Mode. The June post also names the two modes it sat beside then, Default and Chat, neither of which the product uses now. When the results were pulled on 2 September 2026, the documentation page that uses today’s names did not appear on them at all.
What Lovable’s agent mode is called now
Six names are in play, and only two of them are current. The table maps what people type against what the product says today, with the vendor page that carries each statement and the date on that page. Searches for lovable ai agent mode and for a Lovable chat agent both land on this question, and both resolve to a mode that has been renamed.
| The name people search | The name in the product today | The Lovable page that says so | Date on that page |
|---|---|---|---|
| agent mode | Build mode | Build mode documentation, first line | Read 2 September 2026 |
| chat mode | Plan mode | Changelog, entry titled Plan mode | 5 February 2026 |
| default mode | Build mode | Changelog, Agent Mode is the new default mode | 11 August 2025 |
| Legacy Mode | Withdrawn | Same 11 August 2025 changelog entry | Sunsetting date 1 September 2025 |
The first row is the one the changelog never announced; the documentation and the glossary record it in passing. Lovable’s Build mode documentation opens: “Build mode (previously Agent mode) is Lovable’s autonomous execution mode, designed to implement changes directly in your project.” The page’s own title is “Implement changes in Build mode”. Lovable’s glossary carries a parenthetical of its own at the end of its Build mode entry: “(Previously called Agent mode.)”. Read on 2 September 2026, those two pages are the only ones carrying the old name among Lovable’s feature pages and its glossary, and the changelog carries it once more, inside a dated 2025 entry.
That is the whole announcement. Lovable’s changelog, read on 2 September 2026, carries one entry naming Agent Mode in its body copy, the upgrade announcement dated 11 August 2025, and no entry anywhere on the page announcing the change of name to Build mode. The rename to Plan mode got one: the entry dated 5 February 2026 reads “Chat mode is now Plan Mode.”
The old name also survives where nobody thinks to look, in the address bar. On 2 September 2026 a request to docs.lovable.dev/features/agent-mode returned the page titled “Implement changes in Build mode” with no redirect. That is a statement about the URL path only, not about the page’s title or its body copy, and Lovable’s own changelog does the same thing: the entry dated 18 May 2026 that describes the mode switcher links the word Build straight at that old path.
So the practical answer to “is it still called agent mode” has two halves. The product stopped using the words. The search results, and the documentation’s own plumbing, still carry them.
Build mode and Plan mode, and which one you are in
Lovable’s Build mode page states the split in one line: “Plan mode is for decision-making. Build mode is for execution.” The same page lists them as a pair, with Plan mode for thinking through the problem, exploring options and deciding on an approach, and Build mode for implementing changes and verifying the outcome. Both sentences sit on the same page, read on 2 September 2026.
Build mode is the one that touches files. Lovable’s description of it is unusually direct about how much it takes on: “When you give Lovable a task, it takes ownership of execution end to end. It understands your intent, explores the codebase for context, applies changes across files, and resolves issues that appear during development.”
Lovable’s Plan mode documentation draws the opposite boundary in one sentence: “Plan mode never modifies your code.” Its own description is “Plan mode (previously Chat mode) is Lovable’s planning and reasoning mode, designed for moments when thinking, exploration, or clarity is more valuable than immediate execution.” It asks clarifying questions, and when it has an approach worth writing down it produces a plan you can inspect and edit before anything is built.
Which one you are in is a question with a documented default. “Build mode is active unless you switch to Plan mode,” says the Build mode page. To switch, the Plan mode page’s instruction is “Click Plan next to the message input”, and the changelog entry dated 18 May 2026 adds that the chat input has a dropdown for switching between the two and that a keyboard shortcut does it as well. That same entry says the behaviour of both modes is unchanged, which is worth knowing if you read something older and wondered what the new switcher changed.
The two modes are also charged on different principles, which the section on what they cost takes up further down.
What Lovable’s agent decides for itself inside one message
One message to a lovable dev agent can be hours of work with dozens of decisions inside it, and none of those decisions comes back to you for approval. That is the part people are surprised by, and Lovable documents most of it.
Lovable’s Build mode page lists what a single message can cover. It includes implementing a feature once the approach is decided, fixing bugs end to end, applying coordinated changes across frontend, backend and configuration, inspecting logs and network activity to identify problems, fetching external documentation or assets when needed, generating or editing images and videos, and verifying results before finishing. A lovable coding agent that can fetch a document and generate an image mid-task is choosing tools as well as files.
Where those choices become visible is one view. Open the Details view, which the page says takes over the space the preview normally occupies, and its Timeline tab “lists every step Lovable took, including tool calls”. If you want to know what the agent decided, that tab is the record of it.
The page is also explicit that you are not locked out while it works: “Send a follow-up, a correction, or a new idea at any time to steer the work”. Lovable takes the new instruction in at the next point in the run where it can, and the page states that nothing already finished is lost when it does. A few kinds of message, it notes, wait and start a request of their own once the current one has ended. An older mechanism for stacking messages exists on some accounts and Lovable now labels it deprecated, so two people can see different behaviour in the same situation without either account being broken.
Two published limits shape how long all of this can run. Under a heading about how long Lovable works on one message, the page states: “Lovable works on one Build mode message for up to 10 hours.” Then it describes the ending: “In the final half hour, Lovable wraps up: it finishes what is in progress instead of starting new work, and summarizes what is done and what remains, so you can ask it to continue in a new message.” That second sentence is the useful one. A long run does not get cut off mid-edit at the limit; it lands, tells you what is unfinished, and waits for the next message.
Stopping early has a documented consequence, in the page’s words: “Stopped requests are charged only for work completed up to that point, and completed changes are kept.” The changes stay, and so does the charge for making them.
Nothing in a plain request marks anything as off limits, which is why Lovable’s own page teaches you to do it by hand. Among its four examples of a good instruction, one is headed “Set guardrails for sensitive areas” and reads: “Add a new feature to @src/pages/dashboard. Do not modify @src/shared/Layout.tsx or the existing authentication logic.” The vendor is telling you, in its own example, that the sentence naming what must not move is part of the request rather than an optional extra.
Lovable’s subagents and skills, and where each one stops
Two features sit underneath Build mode and get mistaken for it. Both were added in May 2026 by the changelog’s own dates, and both have names that half a dozen other coding tools also use, so everything below is specifically Lovable’s version.
Lovable’s subagents documentation describes them as temporary, read-only subagents that Lovable can start “to research, inspect, or review focused parts of the work”, running several in parallel when that helps, and reporting findings back to the main agent. The changelog entry dated 27 May 2026 says they are available to all users.
The boundary is the half worth reading twice, and the documentation states both sides of it:
| What Lovable’s subagents may do | What the documentation says they cannot do |
|---|---|
| Search your project, inspect files, run read-only lookups | Edit, create or delete files |
| Browse the web when needed | Make any changes to your project |
| Review work against your prompt, return findings | Apply those findings, which the main agent does instead |
Lovable states it twice on the same page: “Subagents can inform the work, but they cannot change your project. All file changes still come from the main Lovable agent.” So an activity card announcing that something is being investigated in parallel means an extra reader, working alongside the one agent that still does all the writing.
You do not get a say in when they appear. “You do not need to configure subagents or choose when they run. Lovable decides when subagents are useful based on your request.” There are two kinds. Generic subagents are used when Lovable wants findings in a particular shape, such as a comparison or a summary, and their card names the task. Explore is used when the answer needs traceable evidence, such as how something works or why something behaves a certain way. One more detail explains why a subagent sometimes reports something you already told the chat: “Subagents start with fresh context. They do not automatically see the full chat, previous messages, or everything Lovable has already read.”
Lovable skills are the other half, and they are yours rather than the agent’s. Lovable’s skills documentation defines one as a short, named playbook with “a name, a description that tells Lovable when to use it, and markdown instructions that Lovable follows when the skill applies”, defined once at the workspace level and usable across every project in that workspace. You invoke it “as a / command paired with your prompt”, or let Lovable apply it automatically when the task matches. The changelog dates workspace skills to 18 May 2026 and records the three ways one arrives: created from chat, imported from a public GitHub repository holding a SKILL.md, or uploaded as a ZIP containing one.
That last detail is the bridge to a format that predates Lovable’s version of it. If your project is connected to a repository and you are deciding where standing instructions belong, what the AGENTS.md standard covers, and which tools read it is the page for the format itself.
How do you turn Lovable’s agent mode off?
Lovable’s agent mode has no off switch any more. The mode became the default in 2025 and the old way back was withdrawn on a date Lovable published. What exists today is switching to Plan mode, which the documentation says never modifies your code, and which you can leave at any point.
lovable turn off agent mode is one of the eight suggestions Google’s autocomplete returned on the head phrase when it was checked on 2 September 2026, which means people are still looking for a setting. Here is what happened to it, in order.
The 11 August 2025 changelog entry that made the mode standard also set the end date for the alternative: “Legacy mode (where you don’t use agent) will be sunsetting on September 1, 2025.” That is the vendor’s own sentence and the only published date for the withdrawal.
Before that, there was a route through the settings panel, and it is worth recording because it is what the older articles still describe. Lovable’s announcement of 23 July 2025 tells readers who wanted the old behaviour that they could enable it by going to Project Settings, then Labs, then Enable Legacy Mode. The three step names in that path are the post’s own, and the setting they lead to was gone by 1 September 2025.
So the honest answer today is a mode switch rather than an off switch. Click Plan next to the message input, or use the dropdown the 18 May 2026 changelog describes, and you get a Lovable that reasons, asks and proposes without touching a file. That is as close to off as the product goes, and for most of the situations that send somebody looking for the setting, it is the thing they wanted anyway: a conversation before an edit.
Why the Lovable results you found still say Agent Mode
The search results are stale in an unusually specific way, and it is worth knowing before you trust the next page you open. On 2 September 2026, eight organic results filled the top eleven positions for the head phrase, and the two vendor pages among them were the beta announcement of 30 June 2025 and the July 2025 post about the agent becoming standard. The lovable dev agent mode described in both is the one with the old names. The June post still says “In our current Default and Chat Mode”, which is two retired names in one clause.
Around them sat a community thread, a LinkedIn post about the same 2025 livestream, a third-party explainer on ai.gopubby.com, a short video on TikTok, and a directory listing on aiagentstore.ai. On the lovable subagents query the pattern repeated: a third-party AI-tool blog at aitoolblaze.com ranked, and Lovable’s own subagents documentation page did not appear in the first page of results returned for that query when it was pulled on 2 September 2026. The claim covers one observed result set rather than the web.
The documentation result that did rank on the head phrase was docs.lovable.dev/AGENTS, which is Lovable’s instruction file for the agent that writes its own documentation. Read on 2 September 2026, it says: “These instructions define how the Mintlify AI agent should create and update documentation across docs.lovable.dev.” Somebody searching for a product feature lands on a style guide written for the people who maintain the documentation.
There is a second, quieter reason the old name dominates. Checked on 2 September 2026, Google’s autocomplete returns eight suggestions for lovable agent mode, including lovable agent mode reddit, lovable agent mode pricing and lovable agent mode review. For lovable build mode it returns exactly one suggestion: itself. Autocomplete suggestion counts are not a measure of search volume, but the difference in what people are typing is plain, so every publisher writing for traffic keeps writing lovable agent beta and agent mode a year after the product stopped using the words.
One thing this page does not do is rate the mode. It reports what Lovable publishes about it, with dates, and it never opened an account or ran a task, so it has nothing to say about whether the mode is fast, accurate or an improvement on what came before. What the builder as a whole is, and how it holds up for the people using it, is a wider question than one mode and is answered on its own page.
What the two modes cost you
The two modes are metered on different principles, and that difference is what makes the switch between them worth understanding. Plan mode is charged per message, whatever that message contains. Build mode is charged by the work the request turns out to need, which is why a single instruction can be cheap one day and expensive the next.
Lovable is straightforward about the consequence. Its Build mode page states: “Lovable does not show an upfront credit estimate before a Build mode request runs, because cost depends on work that is discovered during execution.” To follow a running request, the page points at the More options menu below Lovable’s response, which shows what has been used while the request is still going.
Every actual number here belongs on one page and stays there. If what you want is arithmetic rather than mechanics, what a Lovable credit actually buys has the published examples, the plan grants and the top-up rates.
When the mode is not what is wrong
Three situations get blamed on the mode and are not about the mode at all. Each has a different first move.
The first is a fix that will not take. You describe the bug, Lovable reports it fixed, and the screen does the same thing it did before. Switching to Plan mode can help with the first half, since it stops edits and lets the agent reason about the cause without touching code, but it does not repair anything on its own, and the diagnosis still needs evidence from outside the chat: the repair steps for a bug the chat keeps reporting as fixed are the sequence for that, and they end somewhere other than the chat panel.
The second is a request that keeps moving things nobody asked about. That is the one that feels like the agent has too much freedom, and the fix lives mostly in the message rather than the settings, with Plan mode as the brake: it makes no code changes, so you can agree the scope there before switching back to Build. Getting the agent to leave the rest of the app alone is then a matter of how the request is written, and that has its own page.
The third is a project that has stopped producing anything at all: no new steps in the timeline, no card asking you a question, nothing arriving. A stalled run and an over-eager one look nothing alike once you have the Timeline open, and the checks that tell them apart have nothing to do with which mode you are in.
Common questions about Lovable’s agent mode
Is Lovable agent mode still called agent mode?
No. Lovable’s documentation calls it Build mode, and the Build mode page’s first line reads “Build mode (previously Agent mode)”. The glossary, read on 2 September 2026, carries its own parenthetical at the end of its Build mode entry: “(Previously called Agent mode.)”. The old name is still what people search for and still what most published articles use.
What is the difference between Build mode and Plan mode?
Build mode implements changes and verifies the outcome. Plan mode thinks through the problem, explores options and decides on an approach. Lovable’s own summary is “Plan mode is for decision-making. Build mode is for execution”, and its Plan mode page adds the hard boundary: “Plan mode never modifies your code.”
How do you turn off Lovable agent mode?
There is no off switch. Lovable made the mode standard in 2025 and its changelog dated 11 August 2025 gave 1 September 2025 as the sunsetting date for the alternative. What you can do instead is switch to Plan mode, documented as never modifying your code, by clicking Plan next to the message input.
What was Lovable legacy mode, and can you still use it?
Legacy mode was the older, non-agentic way of working, and Lovable’s changelog entry of 11 August 2025 states it was sunsetting on 1 September 2025. The route to it, published in the vendor’s post of 23 July 2025, ran through Project Settings, then Labs, then Enable Legacy Mode. Both are dated records rather than current instructions.
What are Lovable’s subagents?
Temporary, read-only helpers. Lovable’s subagents page describes them as subagents it starts “to research, inspect, or review focused parts of the work”, sometimes several at once, reporting findings back to the main agent. Its changelog dates general availability to 27 May 2026. You do not turn them on or choose when they run.
Can one of Lovable’s subagents change your project?
No. The documentation states it twice: “Subagents can inform the work, but they cannot change your project. All file changes still come from the main Lovable agent”, and, separately, “They cannot edit, create, delete files, or make any changes to your project.” A subagent card in chat means something is being read rather than written.
What is a Lovable skill, and how is it different from project knowledge?
A skill is a short, named playbook defined at the workspace level: a name, a description telling Lovable when to use it, and markdown instructions. The skills page separates the two by when each one arrives. Knowledge rides along with every request, and skills “are loaded on demand when the request matches”.
Why does Lovable show a list of tasks instead of just answering?
Because one Build mode message is a run rather than a reply. Lovable’s page says tasks appear in the chat showing the current step, the files being modified, the tools being used and progress through a multi-step implementation. Opening the Details view shows the Timeline, which lists every step, including tool calls.
One loose end, and it is the one that matters at hour three. The Build mode page describes the Timeline as a record of the steps already taken, and it describes nothing that estimates what is still to come. Everything the agent has decided is visible, and how much it has left to decide is not.
If you have a working app built with these tools and need it ready for real customers, this is what we do.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase