DAG of Conversations

[cboos]

I've stumbled upon Messages as Commits: Claude Code’s Git-Like DAG of Conversations, which is very enlightening.

Teasers:

Claude Code conversations are functionally identical [to git branches]. Each message object points to the previous message via parentUuid, so you can fork a conversation by creating a new message whose parentUuid points to some earlier message instead of the latest one. Conversations are reconstructed by walking parent pointers back from "leaf" messages.

In other words, a "session file" is just whatever file Claude Code is currently appending entries to. Conversations themselves are virtual, reconstructed from the DAG across all entries and files.

And I can only sympathize with the way they put it:

Okay, so far so good, but now things get a little weird. Let's say you launch Claude Code and your session ID is 123; you chat, messages are written to 123.jsonl, and then you exit Claude Code. Later, you launch a new Claude Code session, say 456—on startup, Claude Code looks at recent session files and generates a summary for the conversation stored in 123.jsonl; however, because the current active session is now 456, the summary entry gets written to 456.jsonl!

So the summary for a conversation that lives in 123.jsonl is stored in 456.jsonl. This seems unintuitive at first but ultimately works because of how Claude Code loads and merges session data, which merits its own section.

---

Several questions surface after reading that:

• Would it make sense to always consider all sessions in a project?
• Does our rendering logic currently handle a session where /resume is used?
• In a similar way, how could we support the command:

   /fork                   Create a fork of the current conversation at this point
  

Maybe we should identify messages that are fork points in a special way?

Or, when we detect fork points, show an index at the top:

• session summary / first message
  • message_23 (uuid=A) <= fork point
    • message_23.1 (parentUuid=A)
      • message_45 (uuid=B) <= fork point
        • message_45.1 (parentUuid=B)
        • message_45.2 (parentUuid=B)
    • message_65 (parentUuid=A)

I think showing the messages that are fork points in such a summary makes sense (= at which state did we fork?).

Another excerpt from that article:

In fact, you could literally shuffle all the lines in all the files and Claude Code would still reconstruct the same set of conversations and summaries

I wonder if we shouldn't revisit renderer.py once more, starting with creating this DAG from all sessions .jsonl... The chronological sort doesn't make sense if we're resuming/forking a lot during a session. OTOH, this would break the way we do pagination and the "append" only update model.

[daaain]

I think resume continues the same session file? But I haven't used forking so not sure how that behaves.

There's already a fair bit of logic matching sessions with their names from other sessions, but maybe we should more or less ignore which files the messages are from and use the internal id references to reconstruct the graphs?

I think pagination might be fine, IIRC in the end I switched to a character counting model as messages can be so different in size, so no matter how we string the messages, whenever a page gets big, start a new one. Though branching might mean we need to rerender earlier pages.

What's great is that now we can construct any query over the messages in the SQLite database, so we're not really tied to files as much.

[daaain]

Wait, actually, it might be that the character counting is only done for the TUI Markdown rendering (because it was a big performance issue there) but I'm not sure if that was also done for the HTML and other file outputs 🤔

[daaain]

It's a bit unrelated, but having just finished reading the article:

1. we should also do the manual session (re)naming as that sounds really useful, I've been using resume a bit more lately because the workflow where I try to keep scope and context small lends itself to reusing sessions that touched the same area (and I should use forking more too)

2. let people name and merge projects, this has been something I keep coming back to (and it's been a long standing issue) because trying to extract project name from the slugs or cwds is a bit random, and it just totally breaks down with git worktrees and running CC in a container for sandboxing

But in a way these do tie back to your original post that we could think of a way to overlay different ways of organising, visualising, and navigating projects, sessions, and messages. And again, because we have SQL, these different ways could be just SQL views, customised, and virtual.

[daaain]

Oh, I also just remembered that we had the timeline rendering in the HTML since ages, maybe something like that could be the way to render these graphs? Git tree visualisation also often uses timestamps for ordering commits (messages) and then draws the graph over to connect the ones belonging in a branch, but I think seeing a timeline helps to not get completely lost in the branching