feat: copying or forking chat conversations #968

New Issue

GiteaMirror · 2025-11-11T14:34:33-06:00

GiteaMirror commented

2025-11-11 14:34:33 -06:00

Originally created by @Arcitec on GitHub (May 19, 2024).

Originally assigned to: @tjbck on GitHub.

Is your feature request related to a problem? Please describe.
~~Sometimes~~ Very often, I want to try different directions, without messing up the main "workbook". Currently, I cannot find any way in Open WebUI to copy or fork a conversation.

If it was possible to fork things, it would mean that we can finally try out different ideas, while having a totally separate branch for those tests, which we can refer back to anytime to manually copy interesting aspects into the main workbook.

We can then delete those branches/copies when they are no longer needed.

I've seen other Ollama frontends with the "duplicate conversation" feature, so there's clearly some interest in the feature.

Describe the solution you'd like

The hamburger "..." menu for a conversation could have a "Make a copy" menu item.
Individual messages (both prompts and responses) could also have a "Make a copy at this location", to make a copy which doesn't include anything after that message.

Describe alternatives you've considered
I've considered using the existing ability to delete parts of a conversation, and to try things in the main workbook, but here are the issues with that:

Having to delete everything to go back to a prior, "serious" state, means that you lose the ability to continue the separate experiment.
You lose all of the history/text from the experiment, and have to manually copy them to some other storage location (such as a text file).
I know that it's possible to edit prompts to create a new "internal branch" inside a workbook, which you can switch back and forth between, but this has the issue that it becomes increasingly difficult to find the message where the branch happened, especially if there's multiple branches.

It would just be so much easier to work with the LLM if we could copy a conversation, run experiments, and then delete the temporary copy.

Additional context
Matt Williams had a great video showcasing this exact feature in another frontend UI:

https://youtu.be/cdAb5CigAgQ?t=179

Originally created by @Arcitec on GitHub (May 19, 2024). Originally assigned to: @tjbck on GitHub. **Is your feature request related to a problem? Please describe.** ~~Sometimes~~ Very often, I want to try different directions, without messing up the main "workbook". Currently, I cannot find any way in Open WebUI to copy or fork a conversation. If it was possible to fork things, it would mean that we can finally try out different ideas, while having a totally separate branch for those tests, which we can refer back to anytime to manually copy interesting aspects into the main workbook. We can then delete those branches/copies when they are no longer needed. I've seen other Ollama frontends with the "duplicate conversation" feature, so there's clearly some interest in the feature. **Describe the solution you'd like** 1. The hamburger "..." menu for a conversation could have a "Make a copy" menu item. 2. Individual messages (both prompts and responses) could also have a "Make a copy at this location", to make a copy which doesn't include anything after that message. **Describe alternatives you've considered** I've considered using the existing ability to delete parts of a conversation, and to try things in the main workbook, but here are the issues with that: 1. Having to delete everything to go back to a prior, "serious" state, means that you lose the ability to continue the separate experiment. 3. You lose all of the history/text from the experiment, and have to manually copy them to some other storage location (such as a text file). 4. I know that it's possible to edit prompts to create a new "internal branch" inside a workbook, which you can switch back and forth between, but this has the issue that it becomes increasingly difficult to *find* the message where the branch happened, especially if there's multiple branches. It would just be so much easier to work with the LLM if we could copy a conversation, run experiments, and then delete the temporary copy. **Additional context** Matt Williams had a great video showcasing this exact feature in another frontend UI: https://youtu.be/cdAb5CigAgQ?t=179

GiteaMirror closed this issue

2025-11-11 14:34:33 -06:00

GiteaMirror commented

2025-11-11 14:34:34 -06:00

@Arcitec commented on GitHub (May 20, 2024):

@tjbck I sincerely appreciate that you decided to consider this idea.

Something else just hit me. Even if there's no GUI whatsoever for it, it would be a good idea to remember the relationship between branched conversations, by having a table with the following fields:

source_id: The original conversation's ID.
source_message_id: The exact message ID that started the branch. (The final/last message's ID, if not branched from a specific message.)
target_id: The new branched conversation's ID.
target_message_id: Just the message ID of the last message in the copied branch, meaning "this is where the branch was created".

Then, whenever a branch is created, record these entries.

Whenever any conversation is deleted, delete all entries from that table where either source_id or target_id is equal to the deleted conversation.

Having this recorded historically, even if there's no GUI to see the information, would be very useful for a few reasons:

It's then possible to say "if conversation_id exists in target_id column of link_table", it means that it was a branch, and makes it possible to mark the conversation with a special "this is a branch" icon. That's an example of a trivial GUI change that would immediately make it clear which one is the original and which is the branch.
It would also be possible to have two links at the top of the branched conversation, which can take the user directly to the position where the branch diverges from the original conversation, and another link which goes to the exact conversation (or exact message) which created the branch. (And yes, the user could decide to delete or re-generate messages from the branch or source, breaking those direct message links, but that's solvable by not attempting to directly link to deleted/re-generated messages anymore.)
It makes it possible to have a GUI that can show the hierarchy of branches under a specific conversation, by checking "if conversation_id exists in source_id column of link_table" to know that branches have been created, and then recursively querying each of those branched IDs to generate a tree of all children, and displaying it to the user.

None of that would be interesting at all to an initial "minimum viable product", but would be invaluable to anyone who wants to make visualizations or branch management tools in the future.

So recording that branch relationship information in a secret database table for now would be a good move. :)

@Arcitec commented on GitHub (May 20, 2024): @tjbck I sincerely appreciate that you decided to consider this idea. Something else just hit me. Even if there's no GUI whatsoever for it, it would be a good idea to remember the relationship between branched conversations, by having a table with the following fields: - `source_id`: The original conversation's ID. - `source_message_id`: The exact message ID that started the branch. (The final/last message's ID, if not branched from a specific message.) - `target_id`: The new branched conversation's ID. - `target_message_id`: Just the message ID of the last message in the copied branch, meaning "this is where the branch was created". Then, whenever a branch is created, record these entries. Whenever any conversation is deleted, delete all entries from that table where either `source_id` or `target_id` is equal to the deleted conversation. Having this recorded historically, even if there's no GUI to see the information, would be very useful for a few reasons: 1. It's then possible to say `"if conversation_id exists in target_id column of link_table"`, it means that it was a branch, and makes it possible to mark the conversation with a special "this is a branch" icon. That's an example of a trivial GUI change that would immediately make it clear which one is the original and which is the branch. 2. It would also be possible to have two links at the top of the branched conversation, which can take the user directly to the position where the branch diverges from the original conversation, and another link which goes to the exact conversation (or exact message) which created the branch. (And yes, the user could decide to delete or re-generate messages from the branch or source, breaking those direct message links, but that's solvable by not attempting to directly link to deleted/re-generated messages anymore.) 3. It makes it possible to have a GUI that can show the hierarchy of branches under a specific conversation, by checking `"if conversation_id exists in source_id column of link_table"` to know that branches have been created, and then recursively querying each of those branched IDs to generate a tree of all children, and displaying it to the user. None of that would be interesting at all to an initial "minimum viable product", but would be invaluable to anyone who wants to make visualizations or branch management tools in the future. So recording that branch relationship information in a secret database table for now would be a good move. :)

GiteaMirror commented

2025-11-11 14:34:34 -06:00

@tjbck commented on GitHub (May 31, 2024):

Added to dev, let me know if you encounter any issues!

As for the visualisation feature request, that would be a great addition indeed. It would be deemed as low priority but feel free to open up a separate issue post, PR welcome as always!

@tjbck commented on GitHub (May 31, 2024): ![image](https://github.com/open-webui/open-webui/assets/25473318/99585356-5bdc-4e32-bfa3-982614e1991c) ![image](https://github.com/open-webui/open-webui/assets/25473318/5a634f0b-1dbc-4ffc-aef6-29d584c03f26) Added to dev, let me know if you encounter any issues! As for the visualisation feature request, that would be a great addition indeed. It would be deemed as low priority but feel free to open up a separate issue post, PR welcome as always!

GiteaMirror commented

2025-11-11 14:34:34 -06:00

@sakoht commented on GitHub (Jan 22, 2025):

This seems like it will happen and become a fixture of how user flows work. But be a bit of work.

Exciting to have clone @tjbck.

I wonder if the simplest path for whoever implements it will be:

allow clone from a specific message in the history
allow the clone to remember where it came from, and have a link back

This might be the most minimal change for the next step. Though one could imagine fancier UIs, they could come later.

I may try to do this myself, but if others have already started on it would love to see a note to avoid duplication.

@sakoht commented on GitHub (Jan 22, 2025): This seems like it will happen and become a fixture of how user flows work. But be a bit of work. Exciting to have clone @tjbck. I wonder if the simplest path for whoever implements it will be: - allow clone from a specific message in the history - allow the clone to remember where it came from, and have a link back This might be the most minimal change for the next step. Though one could imagine fancier UIs, they could come later. I may try to do this myself, but if others have already started on it would love to see a note to avoid duplication.

GiteaMirror commented

2025-11-11 14:34:34 -06:00

@Pl8tinium commented on GitHub (Mar 11, 2025):

i would love to see this solved in a similar way like librechat has done it

proper dialogue branching tools can hugely benefit chat workflows, especially when you want to explore ideas and dont want previous context to mush up your new responses

@Pl8tinium commented on GitHub (Mar 11, 2025): i would love to see this solved in a similar way like librechat has done it proper dialogue branching tools can hugely benefit chat workflows, especially when you want to explore ideas and dont want previous context to mush up your new responses ![Image](https://github.com/user-attachments/assets/c89378c9-04a6-4e11-995b-daf597a71213)

GiteaMirror commented

2025-11-11 14:34:35 -06:00

@mr-jovani-van-bread commented on GitHub (May 24, 2025):

@Pl8tinium I have to agree with you, that would be a great feature. Librechat is very good with that feature.

@mr-jovani-van-bread commented on GitHub (May 24, 2025): @Pl8tinium I have to agree with you, that would be a great feature. Librechat is very good with that feature.

GiteaMirror commented

2025-11-11 14:34:35 -06:00

@sakoht commented on GitHub (May 29, 2025):

When I posted this request I didn't realize it already works! Of course something clever to show the tree would be cool, but I don't know that anyone has done this in similar applications.

@sakoht commented on GitHub (May 29, 2025): When I posted this request I didn't realize it already works! Of course something clever to show the tree would be cool, but I don't know that anyone has done this in similar applications.

GiteaMirror referenced this issue

2025-11-11 17:23:52 -06:00

[PR #968] [MERGED] fix: unnecesary double loop #7340

GiteaMirror referenced this issue

2025-11-11 17:24:04 -06:00

[PR #996] [MERGED] 0.1.107 #7348

Sign in to join this conversation.