Repository navigation
Replies: 1 comment
|
+1. Claude Code Desktop already ships this, and it works well:
The whole thing fits on one screen. As #15984 points out, the Agent SDK's |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
What
Render the output of Claude Code's built-in
/contextcommand as a compact, collapsible card in the thread, instead of the raw markdown tables it produces today.Why
/contextis a Claude Code built-in. Its output is not a normal assistant reply — it is a report made of several stacked markdown tables. On my setup that is roughly:Around 330 table rows in a single message. On an iPhone that is dozens of screens of scrolling to get past one command, and on desktop it pushes the whole conversation out of view. The information is genuinely useful; the presentation is the problem.
It also has a concrete cost beyond aesthetics: a message that tall is far above
ThreadFeed'sestimatedItemSize={180}, which is the ingredient in #12072 (iOS feed teleports when scrolling up through unmeasured tall rows).Prior art
Claude Code's own iOS app used to render this the same way and changed it. It now shows a "Context window" card: the model name, a
243.1k / 1M (24%)headline, one stacked bar, then a short list of categories with tokens and percentages. The two big tables (MCP tools, custom agents) become single collapsed rows showing their total and their count —Outils MCP · 114.2k · 190— expandable on demand. A chevron collapses the entire card down to the title plus the bar.The result is one screen instead of thirty, with nothing lost. Screenshots in a follow-up comment.
Proposal A — a dedicated
/contextcard (preferred)Detect the
/contextresult and render it as a card in the timeline:This is the version that actually improves the experience, and it is the one I would like to see. It applies to desktop, web and mobile equally.
I know the cost:
/contextoutput arrives as plain markdown, so this needs parsing of a format that belongs to Claude Code and can change between releases. That is real, and it is a fair reason to say no. Two things that might reduce it: the parse can be strictly best-effort, falling back to today's raw markdown whenever the shape is not recognised, so a format change degrades rather than breaks. And T3 Code already tracks context-window usage per thread for the composer meter, so some of the same data is available without parsing anything.Proposal B — a generic fold for oversized messages (fallback)
If A is too provider-coupled to be worth it, a much smaller change would still help: fold any assistant message past a height threshold behind a "show more", the way long outputs are folded elsewhere. It parses nothing, it covers every oversized output rather than just
/context, and it reduces the tall-row pressure behind #12072.ThreadFeedalready has fold machinery (turn-fold), but it folds whole turns, not an individual oversized message.B is the safe version. A is the one worth doing.
Related
/context,/reload-plugins, …) do not show up in the command picker. Same family: these commands are first-class for the provider but not yet first-class in T3 Code./contextoutput is the tallest row I have.Surfaces
Desktop, web and mobile. The card shape works on all three; mobile is where it matters most, since that is where the raw tables are unusable.
All reactions