chatchan

After releasing ThoughtDAG in August, the most significant feedback was that while editable context graphs were interesting, people didn't want to migrate their existing work to a separate application.

This prompted me to create Session Atlas. It reads local Codex and Claude Code sessions, organizes them by project, and retains conversations, tool calls, and results. The original session remains read-only, and the graph in ThoughtDAG is an editable mirror; content visible on the canvas doesn't automatically carry over to the next model request.

Now, you can select a context from a past session, launch a new CLI experiment, and then connect the results back to the original graph.

Currently, it's not bidirectionally synchronized, only supporting two local sources. But what I want to explore is: should Agent history be just a log, automatically remembered, or source material that can be reorganized and referenced by the user?

Previous HN discussion: https://news.ycombinator.com/item?id=49307700

Thanks man! Any feedback is appreciated!

Thanks for sharing, I agree with you. I also had the same struggle with bidirectional integration.

I think it makes a distinction here. Because I don't want to create "another" coding agent cli here. The core of my idea is to make context editable and flexible. It did help me when I do research to update information, condensate ideas, and prevent context pollution.

Thanks, oh I see, Cypher acts as a context selector.

ThoughtDAG addresses the same issue but uses a visual approach: it searches for nodes first, then uses connections or references to determine which content enters the request. I'd love to see how it compares to writing Cypher directly, especially after conversations start branching and merging, if you get a chance to try it.

Yes. I agree. I've added a small section to the README in the Git repository to describe how it works alongside your coding agent.

ThoughtDAG has automatic folder backups as a JSON file. So you can ask your CLI to access it and get the context in your harness tools :)

Thank you for your feedback!

There is a way to delete a highlight. On the node side panel, there is a folded highlight section; you can manage your highlights there. Also, on your canvas, top-right ... menu, you can manage your highlights as well.

Thanks! I'm not very familiar with Neo4j and Cypher yet. How do you control the context using Cypher? Do you manually write queries for each request, or do you select nodes through the interface and then automatically generate queries? I'm also curious about how the graph structure obtained from the query is ultimately transformed into an ordered model context.

Thank you for sharing! That did occur to me. ThoughtDAG now marks affected downstream answers as needing updates after an upstream node is modified, allowing users to rerun the algorithm in dependency order; alternatively, automatic refresh can be enabled only for specific nodes.

I didn't rebuild the entire tree by default, mainly because modifying earlier nodes might trigger a large number of calls and could overwrite some still valuable intermediate results. Older answers are retained as historical versions for easy comparison.

That sounds interesting. Could you share the arxiv papers? I would love to check them

I agree.

Most LLM tools (Claude Web, OpenAI, and their harness) offer re-editable questions. That is how I avoid such problems by myself.

In ThoughtDAG, you can re-edit questions by double-clicking the question. Or edit the answer by clicking the edit icon at the end of each answer text. Or.. you can just remove the connection or delete the node.

That would give you manageable context

The slime mold analogy is very accurate: research begins by exploring multiple directions, then gradually strengthens the path supported by evidence, stopping other branches from entering subsequent reasoning, but still leaving traces of exploration.

ThoughtDAG currently deliberately leaves this strengthening and pruning to the user, rather than letting the model choose automatically (I think human-in-the-loop is important). I'm curious, in your prototype, is the path strengthened manually by the user, or is it done through model scoring or other signals?

I think we need to distinguish between "what the model received" and "why the model generated this answer." ThoughtDAG currently focuses on the former: accurately displaying the context of the incoming request and allowing users to modify it.

If you're referring to the loom analogy, then it's quite similar: you choose which threads to weave into the next context; unwanted threads can be unraveled :)

Thank you for your suggestion. I've added a "How ThoughtDAG differs" section to the README. Rather than listing specific products one by one, I ultimately chose to compare them based on interaction methods because the functional boundaries of many products are still evolving.

If you have time to take another look, I'd also like to know if the differences are clear and concise enough now.

Thank you for pointing out this issue. The homepage did indeed use too many common landing page elements before actually showcasing the product. I redesigned the homepage, removing status labels, promotional slogans, and unnecessary entry points, making the interactive context graph the main focus of the page.

I read the discussion you linked. The Transformer and MLP examples you gave illustrate the learning process I hope ThoughtDAG can handle: entering a branch along a question without disrupting the main thread; understanding it before deciding which content to bring back, rather than letting the entire exploration automatically pollute the subsequent context.

If you'd like to try it, I'd love to know if it matches your original vision of the learning method, and where it might still interrupt the process. If convenient, please share a screenshot of the anonymized canvas, an anonymous export, or a short screen recording. Seeing a real learning process would be very helpful for improving ThoughtDAG.

Thank you for carefully reviewing the repo and demo; this suggestion is very insightful. Currently, the node sidebar already has a context list grouped by material, reference, and dialogue, but it's collapsed by default and doesn't directly exclude content. Your suggestion to "make the list an explanatory layer" perfectly points out the missing element.

I also agree that Weave and Condense are easier for new users to understand than simply removing connections. The diagram can continue to serve as the underlying structure, while the sidebar answers the question more intuitively: "What content will be used in this answer?"

Thank you!

Thank you for your feedback!

Just want to know. What would be the smallest useful integration for you: allowing the host tool to read the currently selected context, or bidirectional access so it can also create, branch, and prune nodes?

Yes, I have seen several adjacent approaches. Microsoft Huabu explores spatial interaction around research materials, while LLM Canvas and tldraw’s branching-chat experiments explore visual conversation trees. Many workflow canvases also use nodes and edges, but they usually represent execution pipelines. The specific interaction I am testing is more narrowly about context: an edge changes what the model receives, while removing it keeps the earlier work visible but excludes it from the next inference. I would be interested in other projects I may have missed.

I can see the Git analogy in branching, merging, and preserving provenance. But in use, I think it feels closer to a mind map or Miro than to version control. Thought does not need an explicit commit, and branches do not have to resolve into a clean merge. They can remain divergent or unfinished. The part I care about most is that the graph is operational rather than decorative: its edges determine which branches become context for the next inference.

I have not noticed a measurable slowdown in practice so far, including canvases with around a hundred nodes. A request only includes the wired ancestors of the current node, not the entire canvas, so node count alone is not a good measure of prefill cost. That said, your concern is valid for very long contexts. Editing an early ancestor may reduce prefix-cache reuse, while pruning a branch also makes the resulting prompt shorter. ThoughtDAG does not manage its own KV cache today, so this is something I need to benchmark properly rather than claim is solved. Have you encountered this mainly with local models or hosted APIs?