[FEATURE] Conversation map panel: topics, open questions and decisions next to the chat, generated inline at no extra token cost

Status Open
Maintainer reply None cached
Activity 0 comments · opened Oct 8, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

In a long session, every topic spawns follow-up questions, and every answer spawns more. They get buried in the scrollback, forgotten, or answered only partly. Nothing in the UI shows what is still open, what was decided, and which topic a question belongs to.

Existing requests cover a slice of this: a live list of open questions with stable IDs (#98624), a side panel for open questions (#79078, closed as inactive), an open-items window (#98741). This request is for the more general structure those are special cases of: a map of the conversation. Topics, sub-topics branching from them, and the questions and decisions that belong to each. Open questions are one view of that map.

Proposed Solution

A panel bound to the current chat, docked next to the session list (narrow, resizable, collapsible), kept in sync with the conversation:

  • Structure. Topics as group headers, sub-topics nested under the topic they grew from, questions and decisions as entries inside them, sub-questions indented. Connecting lines make the hierarchy visible.
  • One line per entry. A short code (Q3) plus a two or three word name. The full wording shows in a tooltip (with a short delay, so it doesn't cover the list) and inside the expanded entry. Topics have a one-line description too.
  • Status by color. Answered (green), waiting for an answer (yellow), closed by the user without an answer (red). A filter bar shows all / waiting / answered / closed, with counts. Each topic header shows how many questions below it are still waiting.
  • Answering from the panel. Expanding an entry shows the preset options, the same ones AskUserQuestion offers, plus a free-text field and "close without answer".
  • Branching. An entry can be forked into a new chat.
  • Navigation. Clicking an entry scrolls the chat to where it arose.
  • The model fills the map, the user curates it. The user never writes the map. They answer, close, or correct entries.

The key requirement is cost. The map must be produced as a small structured delta in the same response that writes the reply (an inline block consumed by the UI, not shown in the transcript), and only when something changed. It must not re-read the transcript or make a separate call, because that costs far more than the feature is worth. Used this way it adds a few dozen output tokens to some replies, and the map can later serve as a compact state after compaction or in a new chat (see #70555).

Alternative Solutions

I built an external prototype to test the idea (screenshot attached; demo data only):

  • A SessionStart hook injects a ~600-token instruction when the panel is open.
  • The model appends a short HTML-comment tag at the end of a reply only when a topic, question, decision or status changes.
  • A local script parses the session .jsonl (assistant text blocks only) and serves a small page that I keep in a separate window next to the app.

It works well enough to be useful day to day, but it also shows what only native integration can fix:

  1. Answers can't go back into the chat from the panel. A page cannot write into the app, so the answer is copied to the clipboard and pasted.
  2. There is no way to scroll the chat to the message where an entry arose.
  3. The tag stays visible in the transcript unless it is hidden by the UI.
  4. The model duplicates records (a new "done" entry instead of flipping the status of the existing question) unless the instruction says so explicitly, and it sometimes uses a topic code without declaring the topic. A native feature with a structured output channel would avoid both.

Measured on one long real session (430 model requests, about 452k output tokens). The numbers are estimates from character counts:

  • Tags added by the model: 13, about 1.8k tokens, roughly 0.4 % of output.
  • Instruction in context: about 600 tokens, roughly 0.15 % of the cache-read tokens in that session.

So the cost of the approach is small. I have not measured savings (there is no baseline session without the map), so that part is still a hypothesis.

A manual convention (number every question, end each reply with a list) also works, but costs output tokens on every reply and depends on the model following it.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

A long feature-building session: "add login to the app" produces questions about session policy, reset-link lifetime, rate limiting, database migration and rollout. I answer two of them, the conversation moves on to the reset flow, and three questions from earlier replies are now off-screen. With the panel they stay visible under their topic, I can answer one with a preset option without scrolling, close one that no longer matters, and fork "rollout" into its own chat.

Additional Context

<img width="1653" height="993" alt="Image" src="https://github.com/user-attachments/assets/2fe890f2-7e8b-4d9a-ad7e-722a830d395c" />

<img width="720" height="1320" alt="Image" src="https://github.com/user-attachments/assets/f70b4881-ec45-4fb2-aa3b-d13abd423333" />

View original on GitHub ↗