Turning long AI sessions into a work map: dsh-topic-graph

A developer built dsh-topic-graph, a plugin for the dsh AI coding agent that splits long sessions into turns and uses a model to incrementally cluster them into named topics and stages, each tagged with token usage, tool calls, and agent time. The tool renders the results as a stage-to-topic tree, a turn-by-time timeline, and a semantic relation graph that surfaces revisits and subagent delegation. It is aimed at answering effort questions—which part of a session was most expensive, slowest, or most tool-heavy—rather than summarizing chat content.

Split a session into turns, let AI incrementally cluster them into topics and stages, and see at a glance where tokens, tools, and time went. dsh-topic-graph If you use an AI coding agent for real work, you know the feeling: after a few hundred turns, you can no longer answer the simplest management questions about your own session: A chat log is a linear list of messages. But the work is a network: you bounce between features, hit errors, go back, verify, and revisit. Once a session gets long, reconstructing that map from memory and search is a archaeology project. dsh-topic-graph does that reconstruction for you. It listens to the session event stream, splits the session by turns , and asks the model to incrementally fold turns into topics and topics into stages — with names, summaries, and stats. The whole plugin is built on a deliberately boring abstraction: | Concept | What it is | |---|---| | Turn | One user message → the assistant's completed reply. The unit of measurement and segmentation. | | Topic | One continuous line of work, e.g. "implement the login endpoint" or "debug the cache stampede". | | Stage | A group of adjacent topics that belongs together, e.g. "requirements → implementation → integration". | Every topic and stage is named and summarized by the model, and carries its token usage, tool calls, and agent time . That's the key difference from a plain "chat summary": it measures effort , not just content. The main view is Topics · Workflow . On the left is a stage → topic tree; on the right is the selected stage's detail. Drill into a turn and you get the token breakdown input / output / cache read / cache write , step activity time, tool calls, total steps, and the model — plus the user prompt and assistant reply, with a one-click jump to the conversation . Some turns are dense — a messy debugging session, a long investigation. One click turns the turn's model/tool trace into a human-readable, step-by-step explanation , with each step tagged by how many trace steps it covers. The result is cached and can be regenerated. Switch to Topics · Graph and you get the timeline by default: the X axis is turns time , the Y axis is stages lanes , and each topic is drawn as a colored bar spanning its turn range. Semantic relations between topics are drawn as faint dashed curves — subtle by default, highlighted on hover or click. You can read "where did we go back to something" without turning the view into a spider web. The structure graph is the stage → topic tree, with a relation rail on the right that draws the relations between topics. Stages collapse, hover shows details, click opens the topic. The timeline answers "what happened when" . The structure graph answers "how does the work fit together" . They're complementary, not alternatives. The top bar shows session-level stats — tokens, step time, tools, turns, topics, stages, relations, and the AI segmentation cost — with the segmentation model selector and manual segmentation controls right there. Each topic, stage, and turn gets three shares : After one "project" in a single session, you can answer directly: which part was most expensive, which was slowest, and which was the most tool-heavy. Beyond "what came before what", the plugin identifies semantic relations: next — the chronological chain of adjacent root topics; belongTo — a topic belongs to a stage / a subtopic belongs to its parent / a subagent topic belongs to a branch; has relation — model-judged semantic relations depends on / continues / contrasts / fixes / verifies / delegates — parent topic → subagent branch delegation. Revisits are the pattern that matters most in long sessions: "we talk about A, move to B, then come back to A" . After segmentation, the plugin runs a cheap, title-only relation pass specifically to surface these "we came back" loops. In dsh, a subagent runs in its own session — easy to lose track of. The plugin segments subagent sessions too and draws them as branches under their parent topic. Multi-level delegation a subagent spawning another subagent is supported. The result: the main agent's and the subagents' tokens and time can be compared on the same map, instead of each session being its own island. The hard part of "draw a structure over hundreds of turns" isn't the model's intelligence — it's context length and stability . A few things the plugin does: The result is that even a huge session can be imported incrementally, while you watch , instead of waiting for one big request that may fail. The plugin adds a Topic Graph page under dsh Settings : Option 1 recommended : from the dsh-market plugin market Search for dsh-topic-graph in dsh's plugin market and click Install . Plugin page: 👉 https://awesome-dsh-plugin.com/p/hagen666/dsh-topic-graph/ https://awesome-dsh-plugin.com/p/hagen666/dsh-topic-graph/ Option 2: npm dsh plugin --profile web add dsh-topic-graph Option 3: GitHub dsh plugin --profile web add github:hagen666/dsh-topic-graph Restart dsh and refresh the page — the Topics view appears right after Chat / Trajectory . The premise is simple: sessions are written for the AI, but progress is read by humans. Fold a few hundred turns into a map with stats, relations, and jump-to-turn, and questions that used to require memory — "where are we?", "why did this take so long?", "where was that conclusion?" — become a glance. If you run long tasks with dsh, give it a try. Issues and ideas are very welcome.