Skip to content

Commit cc68f36

Browse files
authored
Add proposal for forking existing sessions
1 parent 85ff569 commit cc68f36

File tree

1 file changed

+66
-0
lines changed

1 file changed

+66
-0
lines changed

docs/rfds/session-fork.mdx

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
---
2+
title: "Forking of existing sessions"
3+
---
4+
5+
Author(s): [@josevalim](https://github.com/josevalim)
6+
7+
## Elevator pitch
8+
9+
> What are you proposing to change?
10+
11+
We propose adding the ability to "fork" a new session based on an existing one.
12+
This will allow us to use the current conversation as context to generate pull
13+
request descriptions, summaries, etc. without polluting the user history.
14+
15+
## Status quo
16+
17+
> How do things work today and what problems does this cause? Why would we change things?
18+
19+
Imagine we want to summarize the current conversation to use it in a future chat. If we send a message
20+
asking for the summary, it will become part of its context, affecting future user interactions.
21+
Therefore we want to be able to fork a session, issue additional messages, and then close the fork.
22+
23+
## What we propose to do about it
24+
25+
> What are you proposing to improve the situation?
26+
27+
One possible solution is to add a session/fork command.
28+
29+
## Shiny future
30+
31+
> How will things will play out once this feature exists?
32+
33+
We will be able to implement functionality that requires using the current chat
34+
without polluting its history, ranging from summaries to potentially subagents.
35+
36+
I can also see this feature being extended in the future to support an optional
37+
message ID, so the fork happens at a specific message, allowing clients to implement
38+
functionality like editing previous messages and similar.
39+
40+
## Implementation details and plan
41+
42+
> Tell me more about your implementation. What is your detailed implementation plan?
43+
44+
<!--
45+
Use this section to add details that were not covered in the "What we propose to do about it" section and also include an implementation plan with phases.
46+
47+
Note: This section is OPTIONAL and NOT RECOMMENDED when RFDs are first opened. It can distract from the discussion of the problem.
48+
-->
49+
50+
## Frequently asked questions
51+
52+
> What questions have arisen over the course of authoring this document or during subsequent discussions?
53+
54+
<!--
55+
Keep this section up-to-date as discussion proceeds. The goal is to capture major points that came up on a PR or in a discussion forum -- and if they reoccur, to point people to the FAQ so that we can start the dialog from a more informed place.
56+
-->
57+
58+
### What alternative approaches did you consider, and why did you settle on this one?
59+
60+
None. This proposal is inspired by the abilities exposed in Claude Agent SDK. It must be validated against other agents too.
61+
62+
<!-- You...may want to adjust this. -->
63+
64+
## Revision history
65+
66+
<!-- If there have been major updates to this RFD, you can include the git revisions and a summary of the changes. -->

0 commit comments

Comments
 (0)