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
{{ message }}
Repository navigation
While a turn runs and after it ends: honest timing, running commands you can watch, and a count of what's still running
#32436
"Worked for" while the agent is still waiting. When an agent waits on background work it started (a subagent, a background task, a command passed to t3_background_wait), the turn already folds as "Worked for 53s". The banner below says Waiting, and the agent's own message says it is still waiting.
Text-only turns never say how long they took. Only turns with tool activity get a fold.
A running command doesn't say how long it has run. The row reads "Running vp", or "Running command" for a shell loop, with no elapsed time. Expanding a finished command shows the command twice: once in the header, then again in the panel.
You can't watch a running command. Its output is reachable only after you open the work group and then the command. A build or a test run can take minutes with nothing to read where it happens.
Nothing counts what is running. With several commands, subagents or background tasks, nothing says how many there are or for how long. There's no single place to stop them.
Long output loses its beginning. A finished command keeps its last 64K characters, so for a long log you see the end but never the start, where the command printed its setup and first errors.
Prompts don't say where they are in the thread. On a long thread you can't tell that a prompt was turn 12 of 136, or how long ago it was without reading the date.
Proposal
All of it is built and running in my fork. Web and mobile (iOS and Android) unless noted. It would land as one PR per item, each with before/after images.
"Progress after 53s" while the agent waits on background work it is waiting for. This uses the rule the server and sidebar already use (backgroundWorkHoldsCompletion). It flips to "Worked for" when that work ends. Background work the agent isn't waiting for, such as a dev server, keeps today's "Worked for" plus the Running banner. Every finished turn also gets a "Worked for 2m 36s" line under its final answer, text-only turns too. Stopped and failed turns show none.
Before (main)
After
Android, waiting
Android, text-only turn
Running commands show how long they have run: "Running vp for 1m 5s". On web it ticks through the DOM (tickTextContent), so the timeline doesn't re-render. On mobile it uses the visible-second clock. An expanded command's header shows only its status (Ran, Running, Failed), since the panel already shows the command.
Before (main)
After
Android
Live command output, a Labs setting, off by default. Each running command opens in place with its full command line and an output window. The window grows to seven lines, then follows the end unless you scroll up. It closes when the command ends. It reuses CommandOutputPanel, so a window subscribes to its command's output only while it shows. Output never travels as orchestration events. With the setting off, rows behave as today.
Setting off (as on main)
Setting on
Labs
Android
A running-task count beside the context meter, opening a Running list (web). The chip reads "1 running task". It opens the thread details card at a Running section: each command, tool, subagent or background task, with how long it has run. A subagent opens its thread. No adapter can stop a single command today, so the section has one Stop all, armed by a first press ("Confirm: stop all running work"). Mobile keeps its background-work sheet for now.
Chip and Running section
Stop all, armed
Long output keeps its head and its tail. The same 64K budget as today, split into the first 200 lines (at most 16K characters) and the end, with "… 26,856 lines omitted …" between. Output that fits shows in full, so no command shows less than today. When Codex has already cut the output itself (1 MB, with its own omitted-bytes line), the marker says "… output omitted …" rather than a wrong count.
Before (main): 30,000 lines
After
A prompt's time shows its turn number and how long ago it was. Hovering it on web shows "Turn 136 · 10:26 PM, 15th April 2026 · 6 months ago". On mobile, a tap swaps the time for "Turn 132 · 6 months ago". The server derives the number from the visible prompts, inherited fork turns included, so it stays right after a rewind and on paged-in older turns.
Web
iOS
Default or Beta
Item 3 is opt-in already.
Item 4 adds a chip next to the context meter. I'm happy to put it behind Labs, or hide it until two things are running.
Items 1, 2, 5 and 6 change labels and output only.
The redesign
@maria-rcks's redesign (#28839-#28845) reworks this same timeline and composer. I've merged all six items onto her stack as well, and kept to its design system: text roles, Button, no spaced capitals or "·" joins. On her stack:
every turn already has a fold row, so item 1 is only "Progress after", as a fifth fold ending;
items 2 and 3 live in her working window;
item 4's chip sits in her composer footer.
Items 1 and 2 fit her layer 2 as small fixes, and I've offered them there. I've also asked on #28840 where she'd like the rest.
Performance
Main against all six items, medians of 3 alternating rounds:
On a 2,000-item thread, deriving the web timeline takes 3.89 → 3.91 ms on first open, and each streamed update after it takes 0.70 → 0.69 ms. The mobile feed takes 4.67 → 4.81 ms and 0.22 → 0.23 ms.
Item 4 derives the running tasks on each projection change: 0.01 ms on a 2,000-item thread, 0.05 ms on 10,000.
Item 2 ticks through the DOM on web, so the timeline doesn't re-render each second. On mobile only the time text re-renders.
Item 3 subscribes to a command's output only while its window shows.
Item 5 costs once per expand: head and tail of a 22 MB log take 6.9 ms on the server, against 3.8 ms for the tail only.
Item 6 lists a thread's prompts with a partial index: about 1 ms on a 13.7k-item thread, on bounded snapshots only.
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.
Problem
t3_background_wait), the turn already folds as "Worked for 53s". The banner below says Waiting, and the agent's own message says it is still waiting.Proposal
All of it is built and running in my fork. Web and mobile (iOS and Android) unless noted. It would land as one PR per item, each with before/after images.
backgroundWorkHoldsCompletion). It flips to "Worked for" when that work ends. Background work the agent isn't waiting for, such as a dev server, keeps today's "Worked for" plus the Running banner. Every finished turn also gets a "Worked for 2m 36s" line under its final answer, text-only turns too. Stopped and failed turns show none.tickTextContent), so the timeline doesn't re-render. On mobile it uses the visible-second clock. An expanded command's header shows only its status (Ran, Running, Failed), since the panel already shows the command.CommandOutputPanel, so a window subscribes to its command's output only while it shows. Output never travels as orchestration events. With the setting off, rows behave as today.Default or Beta
The redesign
@maria-rcks's redesign (#28839-#28845) reworks this same timeline and composer. I've merged all six items onto her stack as well, and kept to its design system: text roles,
Button, no spaced capitals or "·" joins. On her stack:Items 1 and 2 fit her layer 2 as small fixes, and I've offered them there. I've also asked on #28840 where she'd like the rest.
Performance
Main against all six items, medians of 3 alternating rounds:
Related
#28655, #24692, #27071, #30543 (fold timing); #30000 (Labs, hide tool calls); #30229 (Cursor live shell output); #28840 (redesign timeline). Separate bug found while building item 5: #31833.
All reactions