[Frontend] Multiple conversations/projects in the UI

[enyst]

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:

• 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.

[mamoodi]

There is a long standing issue that might be related:
#1744

[enyst]

Also related:
#5211

[mamoodi]

Multiple sessions is currently in progress.

[neubig]

Just noting that we're still working on this and getting lots of feedback that people want this.

[vagelim]

@neubig was this completed? The issue is marked closed but I don't see multiple conversations in the release notes for the latest release

[mamoodi]

No this isn't quite complete yet. Not sure why this was closed. Must have been an automatic trigger of sorts.
Let me circle back.

[vagelim]

Just wanted to add for others looking for this feature—in the meantime I just generate a list of conversations by polling docker docker ps --format "{{.Names}}" -f name=openhands-runtime- | cut -d '-' -f 3. The container name suffix matches the conversation ID and can be accessed at http://your-deployment:3000/conversations/conversation-id.