This seems like a really interesting idea and something I've basically been doing myself manually so far, with a DESIGN.md document with "one concept/decision per line, built in a tree" basically, where all decisions that needs to be remembered gets noted down for future reference.
Not a fan of ThoughtDAG being a complete separate application rather than built into the tools I use every day, like my text editor or other planning tool. But neat that you've seemingly integrated a bunch of LLM providers, including letting us use local models, sufficiently sweet :)
Some security "nitpicks": I'm fairly sure you have a critical security issue in the "execSync(`pdftoppm -png -r ${dpi} ...`)" call you do, which I don't think would have been a issue if the local web server you start listened to 127.0.0.1 or some other local IP, but instead it seems the server binds to 0.0.0.0, meaning all network interfaces. Put together, anyone who runs this application effectively gives anyone else a free shell to your computer :)
Tiny nitpicks about the AppImage specifically, seems it's missing publisher details/signing (not a huge deal, just something you might want to look into) and also it's using "--no-sandbox", don't think you need that, let it be sandboxed instead, and the remote vulnerability above might also become less of an issue :)
I'll hold off a bit to play around with it, because of the issue above, but I'm curious to see if it does provide something more than what I manage with my ASCII Markdown tree of decisions. Maybe there is potential for ThoughtDAG in the future to be better integrated with other tools, and end up mostly being the management/viewer of things, so I can continue using vim and codex as today, but they can read/write via ThoughtDAG perhaps, or some other approach.
Regardless, thanks for sharing it and good luck! :)
Irrespective of opinions about a project or its authors, disclosing a potential security issue in a public forum is markedly not responsible disclosure.
> Irrespective of opinions about a project or its authors, disclosing a potential security issue in a public forum is markedly not responsible disclosure
Lol, what you wanted me to do instead, email the author and do the entire chain for a issue I found from 30 seconds of skimming the code? We're on a open forum talking about before-alpha software people share with the community to get feedback, I'm expecting this is exactly what the author wants, that's why they're here in the first place.
Besides, personally I file myself in the category of people not being very responsible folks in general, so I guess thanks? I'd still disagree "responsible disclosure" even applies here.
Thank you for taking the time to inspect this so carefully. You were right, and I treated it as an urgent security issue.
The updated version fixed the mentioned problem. All macOS, Windows, and Linux packages have been rebuilt.
I also agree with your broader product criticism. If you are still willing to try the patched release, I would genuinely value both a security re-check and your thoughts on what the smallest useful editor integration should look like. Thank you again for catching this before more people installed it.
Thank you for taking the time to inspect this so carefully. You were right, and I treated it as an urgent security issue.
The fix removes shell execution from PDF rendering, strictly validates dpi, restricts browser origins, and forces the bundled desktop server to listen only on 127.0.0.1, regardless of the user’s environment. All macOS, Windows, and Linux packages have been rebuilt.
I could not find --no-sandbox in the source or build configuration. If you observed it in the AppImage process arguments or runtime behavior, I would really appreciate the reproduction details. You are also right that Linux publisher signing still needs work.
I also agree with your broader product criticism. The standalone app was the quickest way to test the interaction model end to end, but your DESIGN.md workflow points toward a more useful direction: ThoughtDAG as a context layer and viewer that existing editors and coding tools can read from and write to.
If you are still willing to try the patched release, I would genuinely value both a security re-check and your thoughts on what the smallest useful editor integration should look like. Thank you again for catching this before more people installed it.
That's always going to be a trade off with anything like this so I guess it's better to think of it as an alternative to compaction.
Another use case that comes to mind is that sometimes I'll include some detail early in a conversation and I mean it as incidentals information but the AI fixates on it. If I could selectively edit that out rather than start a whole new conversation it would be worth the cache miss.
Yes, that is exactly the failure mode I care about and drove me to develop ThoughtDAG!
In ThoughtDAG, removing that edge excludes the detail from the next request without deleting the original branch. Thinking of this as user-directed compaction is a useful framing.
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?
I looked at the repo and demo canvas. Nice work. Especially liked the 3 semantic zoom tiers and the weave/condense features. If you're enabling for less-technical users consider leading with weave and condense vs. edge deletion. Edge deletion is where the model is powerful but my Mom would get stuck there for instance. The idea that removing a wire changes what the model actually sees might not be obvious.
Consider when someone clicks a node, show a sidebar listing (node references)with remove buttons to reframe as 'what does this answer know about me" vs. "edit of the graph".
Love the graph for power users but listing can be the explanation layer.
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?"
There is no way to delete a highlight, I accidentally deleted the root node trying to remove a highlight, then the undo command wouldn't recall the root node .
very cool ice over all, its earned a spot in my dock for now.
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.
Sometimes I ask the agent why it gave a certain answer, when I feel it overly fixated on something. It would be cool if the ui hilighted the poisonous part of the conversation somehow.
But agents don't _know_ why they gave an answer. They can only give "reasoning" that links to something in their context, and even then, you would have to parse out their response with some heuristics to try to match against something upstream of that turn.
I could see it being done, and if you're fond of the "models all the way down" mode of thinking, you could use a smaller model to identify it, but it could just as well be a "load-bearing seam" (ha) for something else in the conversation.
I’ve struggled with this line of thought. In a strict sense, it’s true; an AI model doesn’t actually know why it fired the way it did. But I don’t know how practically useful that observation is because, using that strict definition of “know”, humans also do not know why they do what they do.
If I asked you why you posted this comment, I suspect you’d be able to articulate a good reason why from your memories. But the firing of your subconscious and the entirety of your lived experience that molded the state in your brain that lead to you pressing that reply button and writing those exact words are inaccessible to you.
It reminds me of the timeline exercise in SRE work. I always start with a timeline and plunk pagers, metrics, slack messages, etc onto that timeline first. Then I go to individual people to get their understanding of the incident and get that into the timeline. People’s understanding of the incident and why they did what they did rarely matches the timeline.
When I ask an LLM to review its reasoning over prior conversation turns, it has access to its tool call results, web searches, and reasoning traces that aren't visible to me in the UI.
There's definitely value in the "meta-cognition" that an LLM can do even if it is blind to the underlying weights and layers of the model itself.
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.
Sometimes it’s just an awkward turn of phrase on my part that creates a wrinkle in the conversation. Sometimes agents identify that, and we can work together and direct that, but correction itself eventually loses competition to the original error.
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.
The basic idea here looks interesting and is easy to understand but what I'm not understanding is why it's a standalone app. Is this supposed to replace e.g. Claude desktop? Or can it plug in to other systems like Claude Code, Codex, Pi?
I don't think I'd want to use it as a standalone app but I would certainly be interested in it as a plugin.
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?
What would make this useful to me is integrating it into the tools I use. That's Pi, but I would say if you set it up for Claude Code or Codex that would get you more initial users.
Nice work! Recently I prototyped a harness for structured agentic research work and I arrived at something very similar.
I found it especially useful for balancing research breadth vs research width when exploring new topics.
A graph structure makes it easier for me to identify potential blind spots in the research process and allows me to be more confident that no promising alternative solutions were left out while at the same time not getting too stuck in rabbit holes of subquestions.
When I built my prototype I had this image of a physarum slime mold [0] in my head that branches off into all directions first, then reinforces potential paths while starving off all other branches.
In the end that path that survives is the result.
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?
Really nice project, i like some of the functionalities you have though of. When thinking of new concepts i sometimes use similar tool which i created https://github.com/Srakai/bushchat, its browser based (in my opinion more convenience). I kind of switched to .md file knowledge base now so i don't use it very often anymore.
For me the most interesting idea around branching is tree rebuilding itself up when source node is modified. For example, if you are drafting a new project and one assumption changes, all subsequent nodes that based on that knowledge get rebuilt.
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.
Nice. seems like this converges on something i built called https://Tangents.chat, specifically the "Context complier", which can be seen here (https://tangents.chat/demo) (click Context in the top right after entering the demo).
This concept is interesting, and I could see the value. But, I downloaded it to try it, and the interface is janky. The concept is interesting but the UI/UX is bad and confusing. For example, I can't pan the canvas. And the conversation on the right-hand side doesn't show all the previous messages that are getting included in the context window.
I 'v been work on similar project last months, I guess the new attention direction will be on Co-memory contexts instead of making the models have more context memory but hallucinating more
I've been working on something similar to this using Neo4j so you can control the context with a Cypher query because I really like Cypher. But this visualization is excellent.
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.
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.
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.
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.
Not directly today. ThoughtDAG currently runs as a standalone local app.
If you mean letting a Replit agent read selected graph context and write its results back as nodes, that would require an API or plugin boundary that I have not built yet. Would an embedded panel be useful, or would a simple read/write API be enough?
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 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.
Analogy: Textual version of Material Design from Google.
Standardization in important information rich environment is good. Standardization for art is not good. We should not mix these two distinct scenarios. Or maybe I am old.
> Analogy: Textual version of Material Design from Google.
What? The post I linked to is talking about the layout and appearance of the page, in addition to a few textual elements.
> Standardization in important information rich environment is good.
Why is this good in general? And specifically, how is standardizing on e.g. a meaningless status indicator (that doesn't really indicate the status of anything) "good"?
Besides, this is not standardization, it's statistical models (LLMs) converging on a design for arbitrary and likely inscrutable reasons, without understanding the meaning or purpose behind design.
Hi HN, I built ThoughtDAG around one rule: wires are the context.
Each question and answer is a node. When you ask from a node, only its wired upstream nodes are included in the model request. Delete an edge, regenerate, and that branch leaves the model's actual context, not just the visualization.
The interface is intentionally human-controlled. I'm testing whether explicit context control is useful for long-running research, or whether most people would rather delegate memory selection to retrieval.
It is MIT licensed, local-first, supports Ollama and OpenAI-compatible endpoints, and includes PDF clipping with page provenance.
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.
It would be wonderful if you included a section like "ThoughtDAG vs X" in the README, where you then compare ThoughtDAG against these other approaches/tools, and explain with some clear concise words how it's different than those. For extra bonus-points, also explicitly list where ThoughtDAG falls short (today?) and compare to them in that manner too :)
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.
I think I gave up at some point because it does not integrate with my agent workflow. I also try to keep my second brain free of AI generated text.
But it was a nice experiment. The biggest barrier is for me that it happens in a different space than the agents I run and it does not scratch an urgent itch. I think a bidirectional integration is crucial.
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.
This seems like a really interesting idea and something I've basically been doing myself manually so far, with a DESIGN.md document with "one concept/decision per line, built in a tree" basically, where all decisions that needs to be remembered gets noted down for future reference.
Not a fan of ThoughtDAG being a complete separate application rather than built into the tools I use every day, like my text editor or other planning tool. But neat that you've seemingly integrated a bunch of LLM providers, including letting us use local models, sufficiently sweet :)
Some security "nitpicks": I'm fairly sure you have a critical security issue in the "execSync(`pdftoppm -png -r ${dpi} ...`)" call you do, which I don't think would have been a issue if the local web server you start listened to 127.0.0.1 or some other local IP, but instead it seems the server binds to 0.0.0.0, meaning all network interfaces. Put together, anyone who runs this application effectively gives anyone else a free shell to your computer :)
Tiny nitpicks about the AppImage specifically, seems it's missing publisher details/signing (not a huge deal, just something you might want to look into) and also it's using "--no-sandbox", don't think you need that, let it be sandboxed instead, and the remote vulnerability above might also become less of an issue :)
I'll hold off a bit to play around with it, because of the issue above, but I'm curious to see if it does provide something more than what I manage with my ASCII Markdown tree of decisions. Maybe there is potential for ThoughtDAG in the future to be better integrated with other tools, and end up mostly being the management/viewer of things, so I can continue using vim and codex as today, but they can read/write via ThoughtDAG perhaps, or some other approach.
Regardless, thanks for sharing it and good luck! :)
Irrespective of opinions about a project or its authors, disclosing a potential security issue in a public forum is markedly not responsible disclosure.
> Irrespective of opinions about a project or its authors, disclosing a potential security issue in a public forum is markedly not responsible disclosure
Lol, what you wanted me to do instead, email the author and do the entire chain for a issue I found from 30 seconds of skimming the code? We're on a open forum talking about before-alpha software people share with the community to get feedback, I'm expecting this is exactly what the author wants, that's why they're here in the first place.
Besides, personally I file myself in the category of people not being very responsible folks in general, so I guess thanks? I'd still disagree "responsible disclosure" even applies here.
Thank you for taking the time to inspect this so carefully. You were right, and I treated it as an urgent security issue. The updated version fixed the mentioned problem. All macOS, Windows, and Linux packages have been rebuilt.
I also agree with your broader product criticism. If you are still willing to try the patched release, I would genuinely value both a security re-check and your thoughts on what the smallest useful editor integration should look like. Thank you again for catching this before more people installed it.
Thank you for taking the time to inspect this so carefully. You were right, and I treated it as an urgent security issue.
The fix removes shell execution from PDF rendering, strictly validates dpi, restricts browser origins, and forces the bundled desktop server to listen only on 127.0.0.1, regardless of the user’s environment. All macOS, Windows, and Linux packages have been rebuilt.
I could not find --no-sandbox in the source or build configuration. If you observed it in the AppImage process arguments or runtime behavior, I would really appreciate the reproduction details. You are also right that Linux publisher signing still needs work.
I also agree with your broader product criticism. The standalone app was the quickest way to test the interaction model end to end, but your DESIGN.md workflow points toward a more useful direction: ThoughtDAG as a context layer and viewer that existing editors and coding tools can read from and write to. If you are still willing to try the patched release, I would genuinely value both a security re-check and your thoughts on what the smallest useful editor integration should look like. Thank you again for catching this before more people installed it.
What about cache? When you change the context the prefill stage will be much slower?
That's always going to be a trade off with anything like this so I guess it's better to think of it as an alternative to compaction.
Another use case that comes to mind is that sometimes I'll include some detail early in a conversation and I mean it as incidentals information but the AI fixates on it. If I could selectively edit that out rather than start a whole new conversation it would be worth the cache miss.
Yes, that is exactly the failure mode I care about and drove me to develop ThoughtDAG!
In ThoughtDAG, removing that edge excludes the detail from the next request without deleting the original branch. Thinking of this as user-directed compaction is a useful framing.
I think many providers store the cache such that you can reuse any prefix, so it might not be as bad as you naively expect.
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?
[dead]
I looked at the repo and demo canvas. Nice work. Especially liked the 3 semantic zoom tiers and the weave/condense features. If you're enabling for less-technical users consider leading with weave and condense vs. edge deletion. Edge deletion is where the model is powerful but my Mom would get stuck there for instance. The idea that removing a wire changes what the model actually sees might not be obvious.
Consider when someone clicks a node, show a sidebar listing (node references)with remove buttons to reframe as 'what does this answer know about me" vs. "edit of the graph".
Love the graph for power users but listing can be the explanation layer.
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?"
There is no way to delete a highlight, I accidentally deleted the root node trying to remove a highlight, then the undo command wouldn't recall the root node .
very cool ice over all, its earned a spot in my dock for now.
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.
Sometimes I ask the agent why it gave a certain answer, when I feel it overly fixated on something. It would be cool if the ui hilighted the poisonous part of the conversation somehow.
But agents don't _know_ why they gave an answer. They can only give "reasoning" that links to something in their context, and even then, you would have to parse out their response with some heuristics to try to match against something upstream of that turn.
I could see it being done, and if you're fond of the "models all the way down" mode of thinking, you could use a smaller model to identify it, but it could just as well be a "load-bearing seam" (ha) for something else in the conversation.
I’ve struggled with this line of thought. In a strict sense, it’s true; an AI model doesn’t actually know why it fired the way it did. But I don’t know how practically useful that observation is because, using that strict definition of “know”, humans also do not know why they do what they do.
If I asked you why you posted this comment, I suspect you’d be able to articulate a good reason why from your memories. But the firing of your subconscious and the entirety of your lived experience that molded the state in your brain that lead to you pressing that reply button and writing those exact words are inaccessible to you.
It reminds me of the timeline exercise in SRE work. I always start with a timeline and plunk pagers, metrics, slack messages, etc onto that timeline first. Then I go to individual people to get their understanding of the incident and get that into the timeline. People’s understanding of the incident and why they did what they did rarely matches the timeline.
When I ask an LLM to review its reasoning over prior conversation turns, it has access to its tool call results, web searches, and reasoning traces that aren't visible to me in the UI.
There's definitely value in the "meta-cognition" that an LLM can do even if it is blind to the underlying weights and layers of the model itself.
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.
Sometimes it’s just an awkward turn of phrase on my part that creates a wrinkle in the conversation. Sometimes agents identify that, and we can work together and direct that, but correction itself eventually loses competition to the original error.
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 basic idea here looks interesting and is easy to understand but what I'm not understanding is why it's a standalone app. Is this supposed to replace e.g. Claude desktop? Or can it plug in to other systems like Claude Code, Codex, Pi?
I don't think I'd want to use it as a standalone app but I would certainly be interested in it as a plugin.
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?
What would make this useful to me is integrating it into the tools I use. That's Pi, but I would say if you set it up for Claude Code or Codex that would get you more initial users.
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 :)
[flagged]
Nice work! Recently I prototyped a harness for structured agentic research work and I arrived at something very similar.
I found it especially useful for balancing research breadth vs research width when exploring new topics. A graph structure makes it easier for me to identify potential blind spots in the research process and allows me to be more confident that no promising alternative solutions were left out while at the same time not getting too stuck in rabbit holes of subquestions.
When I built my prototype I had this image of a physarum slime mold [0] in my head that branches off into all directions first, then reinforces potential paths while starving off all other branches. In the end that path that survives is the result.
[0] https://carolinalombardi.com/physarum-polycephalum
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?
Really nice project, i like some of the functionalities you have though of. When thinking of new concepts i sometimes use similar tool which i created https://github.com/Srakai/bushchat, its browser based (in my opinion more convenience). I kind of switched to .md file knowledge base now so i don't use it very often anymore.
For me the most interesting idea around branching is tree rebuilding itself up when source node is modified. For example, if you are drafting a new project and one assumption changes, all subsequent nodes that based on that knowledge get rebuilt.
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.
Nice. seems like this converges on something i built called https://Tangents.chat, specifically the "Context complier", which can be seen here (https://tangents.chat/demo) (click Context in the top right after entering the demo).
Looking forward to looking more at ThoughtDAG.
Visual: https://i.ibb.co/NRHSFrg/tangents-context-complier.png
This concept is interesting, and I could see the value. But, I downloaded it to try it, and the interface is janky. The concept is interesting but the UI/UX is bad and confusing. For example, I can't pan the canvas. And the conversation on the right-hand side doesn't show all the previous messages that are getting included in the context window.
[dead]
I 'v been work on similar project last months, I guess the new attention direction will be on Co-memory contexts instead of making the models have more context memory but hallucinating more
I've been working on something similar to this using Neo4j so you can control the context with a Cypher query because I really like Cypher. But this visualization is excellent.
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.
I model the chat as a series of prompt and response nodes like
(prompt)-[:NEXT]->(response)
and can choose a given context by using a path query
MATCH p = (:prompt{id:<>})-[:NEXT*]->(:response{id:<>}) RETURN p
and extract the text from the nodes and format it as the API requires.
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.
Have we all been vibing around the same idea? There are already arxiv papers in the same vein. Very excited to watch this space
That sounds interesting. Could you share the arxiv papers? I would love to check them
nice. i was going to develop something like this for my own learning pattern
https://news.ycombinator.com/item?id=49263169
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.
Looks cool, I'll give it a try
Thanks man! Any feedback is appreciated!
This looks like git, doesn't it?
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.
Can this integrate with replit?
Not directly today. ThoughtDAG currently runs as a standalone local app.
If you mean letting a Replit agent read selected graph context and write its results back as nodes, that would require an API or plugin boundary that I have not built yet. Would an embedded panel be useful, or would a simple read/write API be enough?
is this a loom
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 :)
See also this post (“Every Fucking Website, Slop edition”):
https://news.ycombinator.com/item?id=49302737
Had the exact same thought. It’s like reading a foreign language – and I’m going to be honest – not load bearing at all.
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.
Please don’t write your posts using LLMs.
Analogy: Textual version of Material Design from Google.
Standardization in important information rich environment is good. Standardization for art is not good. We should not mix these two distinct scenarios. Or maybe I am old.
> Analogy: Textual version of Material Design from Google.
What? The post I linked to is talking about the layout and appearance of the page, in addition to a few textual elements.
> Standardization in important information rich environment is good.
Why is this good in general? And specifically, how is standardizing on e.g. a meaningless status indicator (that doesn't really indicate the status of anything) "good"?
Besides, this is not standardization, it's statistical models (LLMs) converging on a design for arbitrary and likely inscrutable reasons, without understanding the meaning or purpose behind design.
Hi HN, I built ThoughtDAG around one rule: wires are the context.
Each question and answer is a node. When you ask from a node, only its wired upstream nodes are included in the model request. Delete an edge, regenerate, and that branch leaves the model's actual context, not just the visualization.
The interface is intentionally human-controlled. I'm testing whether explicit context control is useful for long-running research, or whether most people would rather delegate memory selection to retrieval.
It is MIT licensed, local-first, supports Ollama and OpenAI-compatible endpoints, and includes PDF clipping with page provenance.
GitHub: https://github.com/chenxiachan/thoughtdag
I'd especially appreciate criticism of the interaction model and onboarding.
have you seen other people or project on the same idea ? manipulation history and exploration space of LLM seems to be quite important
Zed's early text threads allowed you to edit the full history as a document.
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.
It would be wonderful if you included a section like "ThoughtDAG vs X" in the README, where you then compare ThoughtDAG against these other approaches/tools, and explain with some clear concise words how it's different than those. For extra bonus-points, also explicitly list where ThoughtDAG falls short (today?) and compare to them in that manner too :)
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.
I vibe coded/sketched a similar idea for the obsidian canvas. https://github.com/ff6347/obsidian-canvas-context it is more a research artifact then a real product/tool.
I think I gave up at some point because it does not integrate with my agent workflow. I also try to keep my second brain free of AI generated text.
But it was a nice experiment. The biggest barrier is for me that it happens in a different space than the agents I run and it does not scratch an urgent itch. I think a bidirectional integration is crucial.
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.
[dead]
[flagged]
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
Thank you!
[dead]