ThoughtDAG: wires as the model's context, and a canvas you can cut
Your thinking deserves a map: an infinite canvas where LLM conversations grow into an editable thought graph. Wires are the context.
At a glance
- What is it?
- ThoughtDAG is a local-first TypeScript app that turns LLM conversations into an editable graph, where an edge into a node is literally what the model sees. It ships as a desktop app, a CLI with read-only MCP tools, and a DeepSeek Harness plugin.
- Who is it for?
- Adopt ThoughtDAG if you already run Claude Code, Codex, DeepSeek Harness or Pi locally and keep losing track of which session produced a given edit, or if you want to prune what a model sees before asking again. Skip it if you need a hosted, multi-user knowledge base, or if you expect the graph to drive autonomous agents: the README states plainly that no autonomous agent redraws your graph.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem ThoughtDAG picks: context you can see and cut
Most chat interfaces give you a scrolling transcript. The model's context is whatever the client decided to resend, and you cannot inspect it, let alone remove one paragraph from it. ThoughtDAG's answer is a single rule stated in the README: "Wires are the context." A node holds a question or an answer; an edge into that node is a piece of context the model will receive. Delete the edge and the next answer changes. That is the whole product thesis, and the README leans on it hard, including an illustration captioned "Delete one edge, get a different answer" with the claim that the same prompt then returns a clean answer.
The audience is narrow and identifiable. It is people who already run coding agents locally (the README names Claude Code, Codex, DeepSeek Harness and Pi), accumulate sessions across all of them, and then cannot answer a simple question: which conversation touched this file, and what did I decide there? ThoughtDAG's second feature set, the query layer, targets exactly that. It is a personal knowledge tool for one engineer on one machine, not a team wiki.
How the graph and the query index actually fit together
Two mechanisms sit side by side in this repository, and they are worth separating because they have different costs.
The first is the canvas. Nodes are conversations, notes, file passages and summaries. Edges carry context. The README describes a reading flow where you select a passage in a PDF, ask beside it, and the answer lands on the canvas tagged with its page number, with a p.N chip that jumps back to the page. Later, nodes merge into a higher-level conclusion, and the whole structure exports as a light or dark Thought Map. The interactive pieces (canvas, PDF and file readers, model and search connections, clipping, export, handoff) live in the desktop app.
The second mechanism is the index. The CLI scans conversation history from Claude Code, Codex, DeepSeek Harness, Pi and ThoughtDAG canvases, and builds a local searchable store. The README says these are "indexed together on your machine" and that the desktop app is not required for this part. The CLI then exposes read-only MCP tools named why_check, why_file, find and recall_turn. The distinction matters: the query layer is read-only by design, so an agent can consult your history without being able to write to the graph.
Getting it running: three entry points, three install paths
The README gives three ways in, and they are not equivalent.
The lightest is a one-off run with no install, useful for deciding whether the index finds anything worth finding:
npx thoughtdag why src/lib/api.ts npx thoughtdag find "a phrase you remember"
For regular use, the README suggests installing the CLI globally and wiring up the MCP tools:
npm install -g thoughtdag thoughtdag setup mcp
The desktop app is a Homebrew cask (brew install --cask thoughtdag) or a download for macOS, Windows and Linux. The DeepSeek Harness plugin is separate again, and the README is explicit that it bundles the canvas so no other ThoughtDAG install is needed:
dsh plugin --profile web add dsh-thoughtdag dsh web
That plugin requires Node 22.19+ and DeepSeek Harness 0.1.2-rc or later. It adds a 对话 | 思维图 switch above the chat, lets you pick one of the harness's models or DeepSeek Harness · Agent to run a question as a real harness turn with tools, and states that the turn stays in the harness's session log. The version cadence visible in the releases (v0.4.10, v0.4.11, v0.4.12 within four days in September 2026) is consistent with the README's own "active_development" badge.
What the CLI output looks like, and what it does not tell you
The README shows shortened sample output. A why query prints a header like "why src/lib/api.ts · 12 turns in 6 sessions", then per-session lines tagged by agent, with an edit marker and a question, followed by a diff-style line such as "Δ storedProviders → storedProviders, storedVision…". A find query accepts a scope flag: --in q for questions, --in m for materials. One example returns "find \"arxiv\" · 1 turn in 1 canvas" with a thoughtdag M: line quoting an arXiv identifier.
These are described as "real local results, shortened to the most useful lines", which is an honest framing and also a warning. Shortened output means the README does not show how noisy a full result set is, how the tool handles a phrase that appears in hundreds of turns, or what happens when the index is stale relative to the working tree. None of that is documented in the supplied material. The README also promotes the query layer with a claim about outcomes: "Give agents less irrelevant history. Reduce context-driven hallucinations and wasted tokens. Improve answer accuracy." No measurement backs that sentence, and it should be read as the project's stated intent rather than a demonstrated result.
The limitation: a canvas that will not drive itself
The design decision that gives ThoughtDAG its coherence is also the one that will rule it out for a set of users. The README states the principle as "the human in the loop, the model on the wires. No autonomous agent redraws your graph."
If you want a system that plans, spawns sub-agents, writes intermediate results into a shared graph and iterates without you, this is the wrong tool by construction. There is no auto-layout of reasoning, no agent that rewrites your branches. Every structural change is a gesture you make. On a canvas with a few dozen nodes that is fine. On a graph that grows past the point where you can hold its shape in your head, the maintenance burden falls entirely on you, and the README offers no pruning heuristic beyond the manual act of deleting an edge.
The second limitation is scope. The index covers five named sources. A conversation in some other client, or in a browser tab, is invisible to why and find. And because the MCP tools are read-only, an agent cannot record its own findings back into the store.
Compared with a plain note tool or a RAG pipeline
The obvious comparison is Obsidian or Logseq. Those store prose you wrote, in files you own, and linking is a reference for your own reading. ThoughtDAG stores a graph in which an edge is consumed by a model at request time, not just displayed to you. That is a functional difference: in a note tool, deleting a link changes your notes; here, deleting a link changes the next completion. The README's framing of the canvas as the place where you "decide what the harness sees next" only makes sense under that rule.
The other comparison is a retrieval pipeline that embeds your history and injects top-k chunks automatically. That approach optimizes for not thinking about context. ThoughtDAG optimizes for the opposite: you see the wires and you cut them. The cost is attention. The benefit is that when an answer is wrong because of contaminated history, you have a lever that a similarity search does not give you. Which of those you want depends on whether you would rather tune a retriever or edit a graph.
Licence, upkeep and what to check before you commit
ThoughtDAG is MIT licensed, so the code can be used, modified and redistributed with the licence and copyright notice preserved. That covers the repository. It says nothing about the model providers or the agent tools you connect to, and nothing about the terms attached to the conversation data the CLI reads from disk, which is worth checking separately rather than assuming. This is not legal advice.
On upkeep: the release history shows three patch releases in the four days before this writing, and the README carries an active-development badge. Expect the graph format and the CLI surface to move. The DeepSeek Harness plugin pins a floor of Node 22.19+ and harness 0.1.2-rc, so a harness upgrade is a compatibility event you will have to track. The query layer is the part least likely to churn, since it reads files other tools wrote rather than a format ThoughtDAG controls.
The first thing to verify is the index itself. Run npx thoughtdag why on a file whose history you remember well, and check whether the turns it returns are the ones you expect. Everything the canvas and the MCP tools offer is downstream of that index being correct, and the README's shortened examples do not let you judge its recall.
Editorial conclusion
Adopt ThoughtDAG if you already run Claude Code, Codex, DeepSeek Harness or Pi locally and keep losing track of which session produced a given edit, or if you want to prune what a model sees before asking again. Skip it if you need a hosted, multi-user knowledge base, or if you expect the graph to drive autonomous agents: the README states plainly that no autonomous agent redraws your graph. Before committing, run npx thoughtdag why on one file you know the history of and check whether the turns it returns match what you remember, since the value of everything else depends on that index being right.
Community notes