▲ 129 points
back
58 comments
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.
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.
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?
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.
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.
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 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?
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?
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.
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
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?
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
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.
is this a loom
nice. i was going to develop something like this for my own learning pattern
See also this post (“Every Fucking Website, Slop edition”):
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.