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.
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?
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).
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?
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.
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?
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?"
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 :)
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.
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.
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.
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.
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! :)
reply