4 ms·
Show HN: ThoughtDAG – An editable context graph for LLM conversations
- chatchan 2mo agoHi 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 https://github.com/chenxiachan/thoughtdag I'd especially appreciate criticism of the interaction model and onboarding.
- agumonkey 2mo agohave you seen other people or project on the same idea ? manipulation history and exploration space of LLM seems to be quite important
- chatchan 2mo agoYes, 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.
- embedding-shape 2mo agoIt 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 :)
- chatchan 2mo agoThank 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.
- fmoronzirfas 2mo agoI vibe coded/sketched a similar idea for the obsidian canvas. https://github.com/ff6347/obsidian-canvas-context 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.
- chatchan 2mo agoThanks 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.
- olejorgenb 2mo agoZed's early text threads allowed you to edit the full history as a document.
- urvader 2mo agoWhat about cache? When you change the context the prefill stage will be much slower?
- kruxigt 2mo ago[dead]
- esperent 2mo agoThat'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.
- chatchan 2mo agoYes, 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.
- chatchan 2mo agoI 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?
- olejorgenb 2mo agoI think many providers store the cache such that you can reuse any prefix, so it might not be as bad as you naively expect.
- Zongming 2mo agoThis looks like git, doesn't it?
- chatchan 2mo agoI 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.
- esperent 2mo agoThe 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.
- chatchan 2mo ago[flagged]
- chatchan 2mo agoThank 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?
- esperent 2mo agoWhat 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.
- chatchan 2mo agoYes. 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 :)
- deleted 2mo ago[deleted]
- embedding-shape 2mo agoThis 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! :)
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- chatchan 2mo agoThank 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.
- mashapps 2mo agoCan this integrate with replit?
- chatchan 2mo agoNot 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?
- zhixingheyi2023 2mo ago[flagged]
- dominotw 2mo agonice. i was going to develop something like this for my own learning pattern https://news.ycombinator.com/item?id=49263169 https://news.ycombinator.com/item?id=49263169
- chatchan 2mo agoI 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.
- myshapeprotocol 2mo ago[flagged]
- chatchan 2mo agoThank you!
- angoragoats 2mo agoSee also this post (“Every Fucking Website, Slop edition”): https://news.ycombinator.com/item?id=49302737 https://news.ycombinator.com/item?id=49302737
- darrmit 2mo agoHad the exact same thought. It’s like reading a foreign language – and I’m going to be honest – not load bearing at all.
- chatchan 2mo agoThank 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.
- angoragoats 2mo agoPlease don’t write your posts using LLMs.
- worldthruword 2mo agoAnalogy: 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.
- angoragoats 2mo ago> 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.
- mikeebener 2mo agoI 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.
- chatchan 2mo agoThank 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?"
- frogperson 2mo agoThere 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.
- chatchan 2mo agoThank 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.
- 4b11b4 2mo agois this a loom
- chatchan 2mo agoIf 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 :)
- Acidev 2mo ago[dead]
- deleted 2mo ago[deleted]
- DenisM 2mo agoSometimes 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.
- Esras 2mo agoBut 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.
- chatchan 2mo agoI 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.
- DenisM 2mo agoSometimes 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.
- chatchan 2mo agoI 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
- _hlqj 2mo ago[flagged]
- _boffin_ 2mo agoNice. seems like this converges on something i built called https://Tangents.chat https://Tangents.chat, specifically the "Context complier", which can be seen here (https://tangents.chat/demo 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 https://i.ibb.co/NRHSFrg/tangents-context-complier.png
- kiops 2mo ago[dead]
- kody_06 2mo agoThis 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.
- deleted 2mo ago[deleted]
- chatchan 2mo ago[dead]
- floriangoebel 2mo agoNice 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 https://carolinalombardi.com/physarum-polycephalum
- chatchan 2mo agoThe 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?
- UltraSane 2mo agoI'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.
- chatchan 2mo agoThanks! 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.
- UltraSane 2mo agoI 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.
- chatchan 2mo agoThanks, 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.
- smrtinsert 2mo agoHave we all been vibing around the same idea? There are already arxiv papers in the same vein. Very excited to watch this space
- chatchan 2mo agoThat sounds interesting. Could you share the arxiv papers? I would love to check them
- Xx_crazy420_xX 2mo agoReally 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 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.
- chatchan 2mo agoThank 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.
- Zierax 2mo agoI '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
- gaya3bollineni 2mo ago[dead]
- vancekai 2mo ago[dead]
- Art9681 2mo ago[dead]
- martinAndy 2mo agoLooks cool, I'll give it a try
- chatchan 2mo agoThanks man! Any feedback is appreciated!
- chatchan 2mo ago[dead]