Agent Threads: compact tool display

[Vlaaaaaaad]

TL;DR: I am proposing 1 single row of "30 thinking blocks, 50 tool calls: 25 🔍, 10 🔨, 15 ✏️" instead of 80 individual rows (1 row for each tool call / thinking)

What are you proposing?

I'd love to have Agent Threads use the screen space more efficiently and, since tool calls take a lot of space, I'd love to see a more compact display option.

Thinking can already be nicely hidden with the thinking_display option (always shown, always closed, preview, auto) and I would love to see that idea expanded more to cover both tool calls and to have even more compressed views.

Why does this matter?

A lot of space is wasted in the Agent Threads, especially for longer threads. This not only makes scrolling a mess but also confuses the user ("omg, I scrolled so much I even forgot what I was searching for").

For example, a lot of my threads look like this:

• Me: "Hey agent, do this thing for me"
• Agent: thinking
• Agent: read file X (lines 1 - 100)
• Agent: read file X (lines 100 - 200)
• Agent: read file X (lines 200 - 250)
• Agent: thinking
• Agent: read file Y (lines 1 - 40)
• Agent: thinking
• Agent: search for X
• Agent: read file A, lines that contain X +/- 10 lines
• Agent: read file B, lines that contain X +/- 10 lines
• Agent: read file C, lines that contain X +/- 10 lines
• Agent: read file D, lines that contain X +/- 10 lines
• Agent: read file E, lines that contain X +/- 10 lines
• Agent: thinking
• Agent: ran a command
• <insert 50 more thinking + reading + running commands)
• Agent: edit file One
• Agent: edit file Two
• Agent: thinking
• Agent: run build
• Agent: thinking
• Agent: read file One
• Agent: read file Two
• Agent: thinking
• Agent: "ok, here's how I did the thing"

That is A LOT to scroll through. Hiding the thinking output helps a bunch (tens/hundreds of rows are collapsed into 1 single row) but there are still tens/hundreds of rows for tool calls ("Read X", "Searched for Y", etc) which provide very little value and which are a hassle to scroll through.

What becomes easier or possible?

With tool calls getting a more compressed display option, a lot of space is reclaimed and it becomes a lot easier to work with LLMs efficiently. In case more visibility is needed, the compressed tool calls can be expanded to see the exact steps the agent took, just like thinking blocks can be expanded today.

Are there any examples or context?

LLM-written proof-of-concept implementation in Zed

Before (silly prompt example):

After (same thread with the same silly prompt example):

Short video (same silly prompt example) — note the left borders / guide lines and the increasing indentation used to display a clear hierarchy to the user (AKA to show what's currently being worked on nicely instead of a confusing single-level):
480p, 8MB: https://github.com/user-attachments/assets/63a9d131-55ef-4607-9958-d9d68c52e0f7
720p, 24MB: https://github.com/user-attachments/assets/e2bf99b4-7ee8-4d15-9cb0-26def8025da8

GitHub Copilot

GitHub Copilot in Visual Studio takes the same approach: consecutive tool calls are grouped, with a LLM-summary used as the title. That can be seen in the last video on this changelog post. Screenshots from that video for reference (note the "Created 10 files and 5 todos" group):

In-progress work shows expanded tool calls (source video):

Completed work/step shows 1 single row with a summary of the tool calls (source video):

The idea of auto-generating a summary title is very nice, but I think I personally still prefer the icons to be shown (summary means a text block in a sea of text blocks which is not easy to skim VS a row of icons creates a clearer structure and separation) 🤔 Something for the Zed UX experts and Zed Designers to investigate!

Possible approach

Tool calls are already compressed into rows, so I propose compressing multiple rows into a single row. A low-quality LLM proof-of-concept can be seen in this commit on this branch in my fork. Since that code is 0) terrible LLM-generated code, 1) a new feature, 2) a big visual change, 3) ugly and in desperate need of design work, I did not think creating even a draft PR was a good idea.

---

Semi-related: #34158 and Discord thread

[hivrich]

I have exactly the same problem when using Codex through Zed.

The agent itself works well, but the actual conversation gets buried under file reads, searches, command output, and other tool calls. During longer tasks, it becomes very difficult to follow what the agent is saying or find previous messages.

A compact or collapsed-by-default tool display would significantly improve the Agent Panel for me. I would still like the details to remain available when expanded, but I do not need every low-level operation to be shown by default.

[Sergio-3]

+1 — I proposed the same idea in #62385 before finding this thread (thanks @Vlaaaaaaad for the pointer). Two additions from over there:

1. Group per work stretch instead of one global summary row: consecutive tool calls between two assistant messages collapse into one borderless line (e.g. "Ran 2 commands, read and edited foo.mjs +83 −40 ›"), expandable into today's individual cards — a two-stage drill-down that keeps each summary next to the prose it belongs to, so the thread still reads as a narrative.

2. Independent of aggregation, collapsed cards need a bounded height: a collapsed terminal card currently renders its complete command — a heredoc easily makes that 20+ lines while "collapsed". Screenshot in Agent Panel: collapsed tool-call cards still dominate the transcript #62385. Truncating collapsed input to one line would help even if grouping never lands.

[Sergio-3]

One more angle on why grouping is worth it, from the sub-agent case.

When an agent dispatches background sub-agents, their tool calls do not arrive between assistant messages — they arrive inside one, asynchronously, while the main agent is still writing. Today every card is its own thread entry, so the message is cut in two at that point. That is not only noisy: it corrupts the rendering, because the second half is parsed as a fresh Markdown document and an open code fence is lost. I filed that separately as #62631, with a dependency-free repro agent.

So grouping has a second payoff beyond saving space: if sub-agent activity collapses into one group instead of being spliced into the transcript at arbitrary points, the main agent's answer stays one continuous block and reads as it was written.

The obvious objection is chronology — a group no longer sits exactly where its calls happened. I would trade that, with one condition: keep per-entry timestamps inside the expanded group. The time position carries real information in two situations, both about trust. When I interrupt a run, it is the only answer to "what had already executed when I hit stop?". And when the agent asserts something — "tests pass, moving on" — it tells me whether the evidence arrived before or after the claim. A collapsed summary line plus timestamped entries on expand keeps both.

To be clear, this is a display improvement and not a substitute for #62631: any other in-message interleaving would still break the same way.