Show HN: ThoughtDAG – An editable context graph for LLM conversations
chenxiachan.github.ioEach 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.
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.
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.
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 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?
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 :)
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! :)
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.
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.
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.
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'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.
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.
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.
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.
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?"
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.
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.
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
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.
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.
Looking forward to looking more at ThoughtDAG.
Visual: https://i.ibb.co/NRHSFrg/tangents-context-complier.png
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.
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?
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.
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.