The short answer
Whizi has no fork control, no branch control, and no way to duplicate a chat. A conversation cannot be split into two chats that both stay live, and there is no "continue from here as a new conversation". The chat options menu in the sidebar offers rename, pin, star and delete, and nothing that copies a conversation.
What Whizi does have is message versions. Editing a message you already sent replaces the tail of the conversation and files the tail it replaced as a version you can flip back to. That is a branch you can visit, not a branch you can run in parallel: exactly one version is live at any moment.
"Fork" means four different things in practice, so start from which one you wanted:
| What you wanted | What to use | What actually happens |
|---|---|---|
| A different answer from a midpoint | Edit that message and send it again | The tail is replaced, and the old tail is archived as a version |
| Both tails kept so you can compare | The version arrows on the edited turn | Both are stored, one is live, you flip between them |
| Two conversations that both stay live from the same history | Not available | There is no duplicate, copy or fork anywhere in the product |
| A side question that does not pollute the thread | A new chat | Nothing carries over except what you paste in |
| The same standing context across several chats | A project | Instructions and pinned files apply to every chat in it |
| A copy someone else can continue | Not available | A share link is a read-only view |
Why there is no fork
This is a structural answer rather than a roadmap answer. A Whizi conversation stores exactly one active branch and nothing else. Every reader of a conversation sees that one branch: the website, the mobile app, share links, and the transcript the model itself receives. Inactive versions are kept off to one side, as plain copies of the rows they would be restored as.
That invariant is what makes version switching cheap, and it is also what rules forking out. A fork needs two branches that are both live, both writable, and both visible. One active branch means the second one has nowhere to exist.
The route surface matches. Beyond the conversation list itself, the only things you can address on a conversation are its messages, its versions, and the project it belongs to. There is no endpoint behind a fork or a duplicate, so no client can offer one.
The consequence worth planning around: editing a turn discards the stored versions of every turn beneath it. Those versions belong to a conversation that no longer exists, so keeping them would let you walk into a branch whose parent is gone. If several branches in one thread matter to you, work backwards and edit the earliest message last. The mechanics of editing, and what a version switch costs and can fail with, are on regenerate and edit messages.
What a new chat carries over
Starting a new chat is the honest answer to a side question, but it is worth being precise about what a new chat starts with, because "start a new chat" is only a real answer if you know what you are giving up.
A new chat starts empty. The previous conversation is not summarized into it, attachments are not re-attached, and the model has no view of the other thread. Whatever you want carried across, you carry across: every message and every code block has a copy control, so lifting the two or three answers that matter into the new chat takes a few seconds.
Two things do carry without pasting. Project instructions and pinned files apply to every conversation inside that project, so a new chat created in a project starts with that standing context already folded into the prompt. And a chat can be moved into a project or back out of it after the fact, which is the closest thing Whizi has to reparenting a conversation. The caps and the behavior are on how to use Projects.
The other route people reach for is model switching, and it is worth saying what it is not. Switching models inside a conversation carries the whole thread to the new model rather than copying it into a second chat. There is one thread throughout, and the replies above the switch stay credited to whichever model wrote them. The patterns are on switching models mid-conversation.
The two cases a fork would have solved
Comparing two answers to the same prompt. This is the most common reason to want a fork, and Whizi answers it a different way: send the prompt to two models in parallel and read the outputs next to each other. Neither model sees the other output, which is the entire value of the comparison. That is on comparing models side by side.
Keeping part of a thread away from a model. A fork is the usual workaround for a conversation that has accumulated context you would rather not resend. Without one, the move is a new chat seeded with a short summary of what actually matters. That is not purely a workaround: a long thread makes older context compete for attention with the real question, so a clean start with three sentences of setup often reads better than forty messages of history.
If what you want is a copy for someone else rather than for yourself, sharing produces a public link to one conversation and the recipient reads a sanitized, read-only view of it. They cannot continue it, and it is not a fork in their account either. The details, including revoking a link, are on sharing a conversation.
For a copy of everything you have, Settings has an Export data action that produces your chats and messages, projects and their file metadata, media, share links, subscription and referral profile. It is an archive rather than a re-importable branch: Whizi imports ChatGPT and Claude exports, not its own.
- There is no fork, branch, or duplicate control in Whizi
- A conversation stores exactly one active branch, which is why forking has nowhere to live
- The chat options menu is rename, pin, star and delete, with no copy
- Edit and resend is the closest equivalent: it replaces the tail and archives the old one as a version
- Only one version is live at a time, so versions are visited rather than run in parallel
- Editing a turn discards the stored versions of every turn beneath it, so edit the earliest message last
- A new chat starts empty; only project instructions and pinned files carry over without pasting
- A share link is a read-only view and cannot be continued by the recipient
Frequently asked questions
How do I fork a conversation in Whizi?
You cannot. There is no fork control, no branch control, and no duplicate action on a chat. The underlying reason is that a Whizi conversation holds exactly one active branch, and the only things addressable on a conversation are its messages, its versions, and the project it sits in. The nearest equivalent is editing one of your own messages and sending it again, which replaces the tail from that point and files the replaced tail as a version.
Can I duplicate a chat so the original stays untouched?
No. The chat options menu offers rename, pin, star and delete, and there is no copy anywhere else in the product either. If the original matters, the practical protection is to stop editing it: an edit is what destroys a tail. Start a new chat, paste in the few messages that matter, and continue there, which leaves the original exactly as it was.
What is the difference between a version and a fork?
A version is one of several stored tails for the same turn, and exactly one of them is live at a time. You move between them with the arrows on the edited turn, and switching swaps the whole tail rather than one bubble. A fork would be two tails that are both live and both writable at once, and that is the part Whizi does not do. Versions are covered on regenerate and edit messages.
If I start a new chat, does the model remember the old one?
Not from the old conversation itself. A new chat starts empty and the model receives only what is in that chat. The exception is a project: instructions and pinned files apply to every conversation inside it, so a chat created in a project already carries that context. Anything else has to be pasted in, and every message carries a copy control for exactly that.
Can I branch a conversation to try a different model?
You do not need a branch for that. Switching the model inside a conversation carries the existing thread to the new model, and each reply stays credited to whichever model produced it, so one thread holds the whole comparison. If you want two answers to the same prompt rather than a handover, send it to two models in parallel instead.
Will editing an early message lose my later branches?
Yes, and this is the one surprise worth knowing in advance. Editing a turn discards the stored versions of every turn after it, because those versions hang off a conversation that no longer exists. Copy anything from a lower branch that you want to keep before you touch a message above it, and if you are reworking several turns, edit the earliest one last.