When running with UI, you can have only one conversation. It's perfectly normal to want more than one, each with a name, so that the user can go back to an older one with a click. As I think we all know, LLM and LLM-based apps have "threads" or similar, it's just such a widespread and handy feature.
Describe the UX of the solution you'd like
I'm not sure of the details here, we just need a list of named conversations, so you can switch back to another. Of course, when you switch, it would load the history of that conversation.
Do you have thoughts on the technical implementation?
In the backend, something like this is implemented, albeit in a basic way: one can run main.py with --name session_name and it loads that session.
We may need to understand and implement a bit more, for this to go smoothly:
in particular, we may want to not reload the runtime, just the controller and event stream
the runtime does have an eventstream instance IIRC; that means we'd need some way to replace it / set to another
Additional context
UI sessions have a non-descript hash as session name, which as far I recall is "forgotten" once you change the session. It should be possible to store it and restore it. The backend doesn't care (once auth passes), it will load an older session.
What problem or use case are you trying to solve?
When running with UI, you can have only one conversation. It's perfectly normal to want more than one, each with a name, so that the user can go back to an older one with a click. As I think we all know, LLM and LLM-based apps have "threads" or similar, it's just such a widespread and handy feature.
Describe the UX of the solution you'd like
I'm not sure of the details here, we just need a list of named conversations, so you can switch back to another. Of course, when you switch, it would load the history of that conversation.
Do you have thoughts on the technical implementation?
In the backend, something like this is implemented, albeit in a basic way: one can run
main.py
with--name session_name
and it loads that session.We may need to understand and implement a bit more, for this to go smoothly:
Additional context UI sessions have a non-descript hash as session name, which as far I recall is "forgotten" once you change the session. It should be possible to store it and restore it. The backend doesn't care (once auth passes), it will load an older session.