You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Render the output of Claude Code's built-in /context command as a compact, collapsible card in the thread, instead of the raw markdown tables it produces today.
Why
/context is 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:
Table
Rows
MCP tools
~190
Skills
~115
Custom agents
15
Memory files
10
Usage by category
10
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's estimatedItemSize={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 /context card (preferred)
Detect the /context result and render it as a card in the timeline:
Header: provider and model, total usage, percentage, collapse chevron.
One stacked usage bar.
The category breakdown as a compact list.
The long tables (MCP tools, skills, custom agents, memory files) collapsed to one row each, showing total tokens and item count, expandable.
Collapsed by default past the header, or remembering the last state.
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: /context output 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.
ThreadFeed already has fold machinery (turn-fold), but it folds whole turns, not an individual oversized message.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
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