Multiple chats

Every site comes with one chat. On every paid plan, Starter, Pro and Enterprise, a site can have more chats beside it, and several of them can run at the same time, so one chat can rebuild the pricing page while another fixes the footer.

Each chat has its own conversation, its own message queue and its own mode. Its agent works in its own copy of the site, so chats never see each other's unfinished edits, and when a turn ends its changes are merged into the site.

Chats and tabs

The chat a site comes with works like any other chat: it can be renamed, cleared and closed. Every other chat is one somebody started. Chats belong to the site rather than to a person, so everyone in the workspace sees every chat and its messages.

Every open chat sits as a tab above the messages on a desktop, underlined when open and ending with the plus button, even when the site has only one chat. On a phone the chats are in a dropdown at the top of the chat panel, with the open chat's three dots menu and the plus button beside it. A tab shows the chat's title, a spinner while it runs, a padlock when it is read-only, a dot when it has news you have not opened yet, and the avatars of teammates who have that chat open. Up to three avatars show, and a count such as +2 stands for the rest. A tab's three dots menu stays hidden until you hover the tab, the open one included, and on a touch screen it is always shown.

A chat's title is New chat until a message says what the chat is for. A short title of up to 10 words is then written for it from its messages, in the language you write in, and shows on the tab a moment after that message starts running, so a message waiting in a queue names the chat once it starts. A greeting, a test message, fix this with nothing attached or a screenshot you upload with no words leaves it New chat until a later message says more, while an element you selected, a file from your project or an error you attached is enough on its own. When the title cannot be written, the chat keeps the name it has and your next message tries again. Until its title arrives, the chat the site came with shows the start of its first message. A chat somebody renamed first keeps their title.

When every chat of a site is closed, the chat panel shows No chats with Start a chat to change your site. and a New chat button, and no chat box. New chat opens the chat the site came with again, on every plan, as described in Close a chat.

The editor's address carries the chat you have open, so a link to it opens that chat. A link to a chat that has been closed since opens another open chat instead. When a chat you are not looking at finishes, you get the same sound and notification as for a finished reply, titled with the chat's name and finished, or stopped early for a run that ended part way through, reading Open the chat to see its reply. Chats that finish while your connection to the editor is down get their dot once it is back, along with one such notification. See Notification and sound settings.

When a message you sent is refused after you switched to another chat, for example because it is too long, you get a Message not sent notice with the reason, and when that chat's box is empty its text is put back there so you can fix it and send it again. A message you added to a chat's queue comes back to that chat's box the same way when the queue refuses it, with Queue not updated and the reason, or with Queue is full or You have queued enough when it would go over a queue limit. When a message you sent is refused because someone closed its chat in the meantime, the notice reads This chat is no longer available and its text goes into the box of the chat you have open, when that box is empty.

A message waiting in one chat's queue can go to another open chat with Move to chat in its row menu, and joins the end of that chat's queue. See Move to chat.

Start a chat

The plus button above the messages starts a chat. Its tooltip reads New chat.

On the Free plan the button stays enabled while the site's one chat is open, with the same tooltip. Pressing it opens an upgrade dialog titled Upgrade to start more chats. For the workspace owner it reads Multiple chats are part of the paid plans, so several chats can work on this site at the same time., and its Explore plans button opens the Plans page. Anyone else is asked to contact the workspace owner to upgrade the plan.

The button is always there, and when a chat cannot be started for another reason it is disabled with a tooltip saying why:

The tooltip says	Why
Multiple chats are not switched on yet. Try again in a little while	The workspace is on a paid plan, but multiple chats are still being switched on, for example straight after an update
This site already has the most chats your plan allows (10 open chats)	The site is at its chat limit, below. The number in brackets is the limit for that site
Wait for the first build to finish	The site's first build is still running
Send a message to build the site first	The site has not been built yet, for example because it was created empty or its first build was stopped or failed. The next message in its chat builds it
This site is locked, so no new chat can start	The site is locked for going over the plan's site limit

A new chat opens straight away, empty, reading New chat with Ask for a change to the site. under it, and starts in Build mode. Starting a chat spends nothing.

When the chat the site came with is closed, the plus button opens it again instead of starting another chat, as described in Close a chat.

Anyone in the workspace with the Editor role on the site can start a chat. A Content editor or Viewer sees Chat not included where the chat would be.

Rename a chat

Open the tab's three dots menu and choose Rename. The Rename chat dialog has one field, Chat title, and Save. A title is 1 to 80 characters. Anyone in the workspace can rename any chat, the one the site came with included, for everyone.

Clear a chat

Open the three dots menu on the chat's tab, or beside the dropdown on a phone, and choose Clear chat, shown in orange between Rename and Close chat. This menu is the only place to clear a chat. The confirmation reads Clear this chat? and This clears the messages of this chat for everyone and throws away the messages queued up to run next in it. The chat stays open, and your site, its pages, and content stay safe. You then get Chat cleared with The messages of this chat were cleared for everyone., and anyone else who has the chat open gets Chat cleared with A collaborator cleared this chat. If the chat cannot be cleared, you get Could not clear the chat with the reason.

The chat stays open and keeps its name, except that a chat whose title was written for it, rather than given by somebody, is called New chat again until a later message names it. Clearing a chat cannot be undone.

• Only the person who started the chat, or someone whose role holds the Delete projects permission, can clear it. For the chat the site came with, only someone with Delete projects can. For anyone else it is disabled with You do not have permission to clear this chat. See Members and roles.
• While the chat runs it is disabled with Wait for this chat to finish first, and while it holds no messages with This chat has no messages to clear.

Close a chat

Choose Close chat, shown in red with a trash icon, from the same menu. The confirmation reads Close this chat? and This closes the chat and clears its messages for everyone. Changes in it that are not merged are discarded. The chat disappears without a notice, and you only see a message when closing fails, Could not close the chat with the reason. Changes it already merged stay on the site, and its unmerged changes are discarded even while the preview cannot be reached. Closing a chat cannot be undone.

• Only the person who started the chat, or someone whose role holds the Delete projects permission, can close it. For the chat the site came with, only someone with Delete projects can. For anyone else the entry is disabled with You do not have permission to close this chat. See Members and roles.
• A running chat cannot be closed. The entry is disabled with Stop this chat before closing it.

Anything queued in the chat goes with it. Someone else who had it open is moved to another open chat with a Chat closed toast reading Someone closed this chat for everyone.

The chat the site came with can be closed as well. While it is closed, the plus button, or New chat when no chat is open, opens it again, empty and named New chat, on every plan. So a site on the Free plan can always start its chat again. When no chat is open, the buttons elsewhere in the editor that hand a request or an error to chat, such as Fix with AI, open it again first, as does turning on the element picker. Closing it also drops the unsent text saved in its chat box for everyone, and its unmerged changes are discarded even while the preview cannot be reached, so it opens again from the merged site.

Each chat works in its own copy

Once a site has a second chat, every chat works in its own copy of the site. A copy starts from the site as it stands, so a chat only ever sees its own changes on top of what was already merged.

The site switches to this way of working the first time a message starts while nothing else is running on it. Until then a message in the new chat waits in its queue with Waiting while this site gets ready to run several chats. and starts by itself once the switch is done. A message in the chat the site came with can wait the same way for a few seconds after the last run on the site ends, while the site switches. When that last run failed, was stopped or stopped before it finished, a message you send in that chat starts right away instead, and the site switches once nothing is running on it.

A site goes back to working without copies once it no longer needs them: when no chat other than the one it came with is open any more, or when the workspace is on the Free plan, which allows one chat per site, and no chat is running or holds unmerged changes. It switches back as soon as that is true while its preview is connected, so at the latest when somebody opens the site in the editor, and from then on the chat it came with works as on a site with one chat. Starting a chat on a paid plan switches it to copies again.

Running chats are kept informed. When another chat merges changes, or changes something outside the code such as the database schema, the site's secrets, its languages, storage or settings, the other running agents are told, so they can take it into account. When two running chats change the same file, both are told and the file shows an Also being edited in badge, described under The Changes panel.

Some things an agent does are held back while another chat runs, because they would pull the ground out from under that chat:

• A destructive database change. A statement that drops or renames something or deletes rows without a WHERE, and emptying one collection or clearing every collection, are refused while another chat is running, and the agent asks you to run it again once the other chats finish. Changes to the database schema run one chat at a time. See Databases.
• Restoring a storage backup or clearing all of storage from chat. Refused the same way while another chat is running.
• Dropping a language or changing the default language. While another chat is running, has unmerged changes or has changes that are not saved yet, the agent cannot drop a language and asks you to request it again once those chats finish and their changes are merged or discarded. A turn that removes a language or changes the default language in the site's code at such a time leaves the site's language settings as they were. Adding a language is never held back. See Multiple languages.

Packages

Once a site works with several chats, its agents add and remove npm packages with a package tool of their own rather than with install commands. Package installs and package runners such as npx are not available to them, and neither is a package's own command run straight from node_modules, or a script from package.json that runs one, installs packages or builds the site. Read-only commands such as npm ls and npm view still work, and a shadcn component is created by writing its file directly. A package an agent adds can be used in its copy straight away, and the change to package.json is merged with the rest of that turn's changes.

When two chats add different packages, both are kept, and the lock file is worked out again when the changes are merged. When two chats set the same package to different versions, the version already on the site is kept and the agent can set its own again if its task needs it.

Merging when a turn ends

When a chat's turn ends, its changes are merged into the site. That happens whether the turn finished, you pressed Stop or the run failed, so nothing it wrote is thrown away. Merges on one site happen one at a time.

The bar above the chat box follows the merge, with Waiting to merge, Merging changes and Checking the preview, and reads Changes merged for a few seconds once they are on the site, then goes away. Each merge takes a code backup, listed as Automatic in Backups. When the preview reports errors after a merge, the agent is told, so it can fix them in the same turn.

Changes from two chats to different files, or to different parts of one file, are merged with no help. A chat that is still running keeps working on the copy it started from: its agent is told which files another chat merged, and its own changes to those files are merged with them when its own turn ends.

When a chat changes a file, whether the file is executable is merged along with its contents, but making a file executable without changing it is not merged. Symbolic links are not merged: a link a chat adds, changes or removes only affects its copy, while edits to the files a link points to are merged as usual.

When two chats change the same lines

When the merge finds that another chat already merged a change to the same lines, the conflict goes back to the chat that is merging, inside the same turn. The bar reads Resolving conflicts. Its agent gets the affected files back with both versions marked, keeps what both chats meant, and stops again, and the merge runs again.

Some conflicts are settled without anything being rewritten. When both chats changed an image or another file that is not text, or one chat deleted a file the other changed, the version already on the site is kept and the agent is told. It can save its own image under a new name if it still needs it.

A change that cannot be merged as it stands, such as a file that still holds conflict markers, a .json file that is not valid, a file larger than 100 MB, or a package.json whose packages cannot be resolved, reads Fixing the changes while the agent repairs it. A .json file that already held comments or trailing commas before the chat changed it, as config files such as turbo.json or biome.json often do, only has to be valid JSON with comments, so it can keep them.

A turn in Plan mode merges once and fixes nothing afterwards, because its agent does not edit files. Conflicts and changes that cannot be merged as they stand are kept as unmerged changes, described below, and errors the preview reports after the merge are left for a later turn.

Changes not merged

When the agent cannot resolve a conflict within the turn, when the turn was stopped or failed with a conflict outstanding, or when the merge could not run at all, the changes are kept as unmerged changes. Nothing is dropped.

The chat then shows a banner above the chat box headed Needs your attention, reading Some changes from this chat could not be merged automatically. They are kept as unmerged changes., and a Changes not merged marker in the transcript. The banner lists up to four of the files, with a line such as +2 more for the rest, and labels each file that conflicts:

Label	What happened
Same lines changed	This chat and another changed the same lines
Added in both chats	Both chats added a file at the same path with different contents
Deleted in another chat	This chat changed a file that another chat deleted. The file stays deleted
Changed in another chat	This chat deleted a file that another chat changed. The other chat's version is kept
File changed in both chats	Both chats changed a file that is not text, such as an image
Package setting differs	Both chats set the same entry in package.json, such as a package's version or a script, to different values
Earlier version missing	The version this chat started from could no longer be found, for example after the site's code was replaced on GitHub

When the unmerged changes cannot be saved either, for example while GitHub refuses the save, while the site's code moves to another repository or while the preview cannot be reached, the banner is headed Changes not saved yet instead and reads The changes from this chat are only in its copy of the site for now. They are saved as unmerged changes as soon as the site can save them. It has no buttons, and the next turn of the chat merges those changes together with its own. When they still cannot be saved a day after the turn that made them, the banner goes away. The changes stay in the chat's copy and its next turn merges them, but they are lost if the preview is restarted or moved to another machine before then.

If the preview stops responding altogether, Modulify restarts it, and a restart clears every chat's copy of the site. While a chat runs, the restart waits for its turn to end. While a chat has changes that are not saved yet, it waits up to 15 minutes in case the preview recovers on its own. After that, changes that were only in a chat's copy are lost and the Changes not saved yet banner goes away.

A file larger than 100 MB is left out of the unmerged changes that are kept. The transcript shows a warning for each such file, up to 10 of them, with its path followed by is too large and was not synced and its size.

There are three ways on from there:

• Merge changes tries the merge again. When it goes through you get Changes merged with The changes from this chat are now part of the site. When files still conflict you get Changes still need attention with Some files were also changed in another chat, so they stay as unmerged changes. When a change cannot be merged as it stands, it reads Some files cannot be merged as they stand, such as a .json file that is not valid or a file larger than 100 MB, so they stay as unmerged changes. instead.
• Discard changes asks Discard unmerged changes? with The changes in this chat that are not merged are removed. Merged changes stay on the site. and cannot be undone.
• Send another message to the chat. Its agent picks the unmerged changes up again, resolves any conflict markers first, and they are merged together with that turn's changes when it ends.

Both buttons are disabled with Wait for this chat to finish first while the chat is running. Anyone in the workspace can use Merge changes. Discard changes follows the rule for closing a chat: only the person who started the chat, or someone whose role holds the Delete projects permission, can discard its changes, and in the chat the site came with only someone with Delete projects can. For anyone else it is disabled with You do not have permission to discard these changes. See Members and roles.

The Changes panel

Above the chat box, a panel headed Changes with a count lists the files the open chat has changed. Click the header to expand or collapse it. Each chat remembers whether its panel is expanded while you switch between chats. Each file carries its state, Changed, Deleted, Merged or Conflict. Merged files leave the list a few seconds after the merge, and the panel goes away once nothing is left in it.

When another running chat is changing the same file, the row carries a badge such as Also being edited in Pricing page, naming that chat, and the panel header shows a warning icon. Both changes are kept: they are merged when each turn ends, and the second one only needs help if both chats changed the same lines.

The live preview

The preview shows the merged site. While chats run, it also shows the unfinished changes of one running chat on top, so you can watch it work. The first chat to start a run while no chat is shown live takes that place, and when its run ends the next running chat takes over.

A button on the address bar above the preview names the chat being shown, for example Live: Pricing page, or reads Merged site only. Its tooltip reads Show live changes. Open it to pick another running chat, or Merged site only to show the merged site alone until no chat is running. The preview is shared, so the choice changes it for everyone who has the site open. Anyone in the workspace can change it, and an AI client can do the same with show_live_changes.

A file that holds conflict markers is never shown live, and neither are package files or .env files, so the preview keeps their merged version. The button appears only on a site that already works with several chats, while a chat is running or shown live, and never in a read-only link.

Publishing

Pressing Publish while chats are running asks Publish while chats are running? first, because Changes from running chats are not included until they are merged. Confirming opens the publish panel as usual, and a publish takes the site as it is merged when it starts.

When you ask a chat to publish, the publish waits for that turn's changes to be merged, then publishes the site as that merge left it. The agent is told Publishing starts as soon as the changes from this turn are merged., and asking again in the same turn does not start a second publish. Once the merge is done, the publish card in the transcript follows the real outcome: Published your site when it went live, Publish failed when the publish failed or was stopped, and Publish not started when nothing was published. In that last case the publish step is closed with one of these results:

Result	When
Publishing was skipped because the changes from this chat are not merged yet.	The changes could not be merged, or a restore or a transfer stopped the turn. The transcript also shows a Publishing skipped marker
A publish was already running for this site, so the changes from this chat were not published. Publish again once it finishes.	Another publish of the site was still running when the merge finished
Publishing did not start for the changes from this chat. Publish again from the publish panel.	No publish started for it, and its turn ended more than ten minutes ago

On a site that works in copies, a chat does not call a deploy hook, because the hook would publish the site without that turn's changes. Asked to call one, the agent publishes the way above instead, or points you to Trigger now on the hook in the Deploy hooks tab once the turn has ended.

See Publish a site.

Credits

Every chat spends AI credits from the workspace the same way, on the tokens its turns use. While chats run at the same time on sites that work with several chats, anywhere in the workspace, each running chat sets some credits aside so the others are less likely to run the balance dry. Runs on a site that does not work with several chats yet, and the build of a new site, set nothing aside and never make a chat wait, but what they have used is still counted when any run checks the balance, so they and the chats stop when the credits run out instead of spending the same credits twice. On the Free plan, which allows one chat per site, nothing is set aside at all, even on a site that still works in copies, and a run stops only when the credits run out.

• A chat that starts while no other such chat is running sets nothing aside to begin with.
• A chat that starts while others are running needs some credits free for itself, and the same room again for each running chat beyond what that chat has spent so far, so a new chat never takes the room a running one needs. When there are not enough, it waits in its queue with Waiting because the remaining credits are reserved by running chats. and starts by itself as they finish. Under that line the panel shows how much the running chats hold, such as 8 credits set aside by 2 running chats.
• While other chats run, a running chat's share grows with what it has spent so far.

When the balance runs low during several runs, only the chat that cannot set more aside is stopped, and the others carry on. When the credits left are only set aside for the other running chats, its reply shows an amber Credits set aside for other chats notice reading This chat stopped because the credits left are set aside for the other running chats. Send it again when they finish., with Try again, and anything queued in it carries on by itself rather than pausing. When the balance itself is used up, it stops with the Out of AI credits notice described in Stopping at zero. Either way the changes the stopped chat already made are merged as usual.

An image or a video only uses credits that its own turn and the other running chats have not used yet and that no other running chat has set aside, and is refused when what is left does not cover it. Credits a chat set aside for itself can pay for its own images and videos, which leaves it less for the rest of its turn. A block of extra emails, which shows on the Usage tab as 2,000 extra emails unlocked, is charged even while chats are running, so a site's emails never pause because chats are mid-run, and those chats may then stop sooner.

Setting credits aside is a safeguard rather than a guarantee: running chats can still go slightly past the balance between two checks, usually by one response each, and that amount is absorbed rather than billed, as described in Stopping at zero. How many credits a chat needs free to start is not shown, and a turn's cost is on its Info row once it ends. See Credits.

On the Usage tab of the Plans page, every charge names the member who sent the message, and a charge made while the site worked with several chats also names the chat it came from by its title. See Credits.

Limits

Limit	Free	Starter	Pro	Enterprise
Open chats on one site	1	10	10	10
Chats of one site running at the same time	1	4	4	4

Every site can always run one chat. There is no limit on how many chats run at the same time across the sites of a workspace: each site counts only its own. A message sent while the site already runs as many chats at once as it can waits in its chat's queue with Waiting because the most chats your plan allows are already running. and starts by itself when a chat finishes. Under it the panel counts them, such as 4 of 4 chats running on this site.

A message can also wait for a few seconds with Waiting a moment while another chat starts. when other chats in the workspace are starting at the same moment, and then starts by itself.

The queues are counted across all of a site's chats: one site holds at most 20 waiting messages and 8 from any one person, whichever chats they wait in, so moving a message to another chat changes neither count. Limits and quotas lists the chat limits of every plan.

When the plan changes

When a workspace moves to the Free plan, nothing is stopped. Chats that are running finish, and their changes are merged as usual. After that, every chat other than the one the site came with is read-only:

• Its tab shows a padlock and its chat box is disabled, with This chat is read-only on your current plan. Rename is disabled the same way, and so are Try again on a failed reply, Continue on a reply that stopped early, Approve and build on a plan and the answers to a question the agent asked.
• Anything queued in it is removed, and Move to chat lists it disabled. A message sent to it is refused with This chat is read-only, reading Your current plan allows one chat, so this message was not sent. Send it from a chat that is not read-only.
• Merge changes, Discard changes, Clear chat and Close chat stay available, so unmerged work can still be merged or dropped.
• Buttons elsewhere in the editor that hand a request or an error to chat, such as Fix with AI on a runtime error or a failed publish, Reference in chat on a console line, Reference on an open file, Ask AI on an empty database or languages panel and on a domain redirect hint, and Add it with AI under Using your storage or Using the analytics API, switch to the chat the site came with first when the chat you have open is read-only, and open it again when it was closed. Turning on the element picker does the same, so the elements you pick land in that chat.

The chat the site came with keeps working, and once no chat is running or holds unmerged changes the site goes back to working without copies, as described in Each chat works in its own copy. Moving the workspace back to a paid plan unlocks every chat.

Restores, moves and transfers

• Restoring a code backup on a site that has switched to working in copies stops every running chat first. Their unmerged changes are kept as unmerged changes, to merge or discard later. When a chat's changes cannot be saved first, for example because the preview cannot be reached, its copy of the site is kept as it is rather than thrown away, and its changes are merged onto the restored code later. Every chat's transcript is cleared along with what was queued when the restore started, each open chat gets a Site code restored marker, and the chats themselves stay. A message queued after the restore started is kept and sent once it is done. Until the site has switched, a restore works as it does on a site with one chat and clears every chat's transcript and queue. See Backups.
• Moving the site to another workspace stops running chats first and merges their changes. The chats and their history move with the site. In a workspace on the Free plan, every chat other than the one the site came with becomes read-only, as above. See Transfer a project.
• Transferring the site to another person stops running chats first. The unmerged changes of every chat are not transferred: they are saved to backup branches in the site's repository, which stay there, and the recipient gets no unmerged changes. When a chat's changes cannot be saved, for example while the preview cannot be reached or GitHub refuses the save, the transfer is refused with Some chat changes on this site could not be saved, so the handover was stopped. Ask the site's owner to open it and merge or discard the changes in its chats, then try again! and the invitation stays open. Then every chat other than the one the site came with is closed, the chat the site came with is open for the recipient and named New chat again, and every transcript is cleared as for any transfer. Moving the code into your GitHub later does not copy these backup branches there.
• Moving the site's code into your GitHub, or back, is refused while any chat is running or has unmerged changes. See Move your code to GitHub.
• Duplicating or cloning the site copies only the code already merged into the site. The copy gets none of the chats or their transcripts, and changes not yet merged in any chat stay with the original. See Sharing and cloning.

From the moment a restore starts, while a move is stopping the chats, and while the preview moves to a new environment, a message waits in its queue with Waiting while the site finishes a restore or move. A chat whose turn was just starting at that moment waits as well, and its reply reads Waiting for the site to finish a restore or move until it can go on. When that is done, each queue carries on by itself, including the queue of a chat whose run a restore or a move stopped, so nobody has to click Run queue.

Merging by hand has to wait until it is done: Merge changes shows Could not merge the changes with Changes cannot be saved to this site while it finishes a restore or move. Try again in a moment!, and merge_chat_changes and write_file from an AI client are refused with the same message.

From an AI client over MCP

The site chat tools take a chatId: main for the chat the site came with, or the chatKey of another chat from list_chats. Where it is optional, leaving it out works on main, except for the tools that edit, remove, reorder or move a queued message, which act on the chat whose queue holds it. The site chat tools that take a chatId return the one they worked on. move_queued_message moves a queued message to the end of the queue of the chat named in toChatId, refuses a closed or read-only chat, and returns the chat it moved to as chatId and the one it came from as fromChatId. create_chat, rename_chat, clear_site_chat and archive_chat start, rename, clear and close chats, and create_chat or send_message to main opens that chat again while it is closed. merge_chat_changes and discard_chat_changes merge or drop a chat's unmerged changes, and show_live_changes picks the chat the preview shows live. list_chats returns every open chat with its title, mode, running generation and unmerged changes, plus whether another chat can start and which chat is live, and send_message, get_job, cancel_job, list_messages and the queue tools all take the same chatId. Every one of these tools is also an endpoint of the public API, under the same name. clear_site_chat, archive_chat and discard_chat_changes need the sites:delete scope, which is not ticked when you create a token, and discard_chat_changes has no default chat. See MCP tools.

Next

• Site chat covers what happens inside a chat.
• Message queue covers each chat's queue.
• Preview covers the preview itself.