Running coding agents in parallel has a hidden job attached: checking on them.
You start three Claude Code sessions, one of them spawns four sub-agents, a Codex thread is running a migration somewhere. Then you spend the afternoon alt-tabbing between terminals asking the same three questions:
- Is this one still working, or is it stuck on a command?
- Is that one waiting for me?
- Which sub-agent just burned 400k tokens?
I got tired of being the person refreshing terminals, so I built the thing I wanted to look at instead: a stand-up call.
What it actually is
Agent Standup reads the session files that Claude Code, Codex and Mistral Vibe already write to disk, and plays them as a live team call:
- The lead agent gives the orders. Sub-agents join the call when they get a task, work at their desks, report back, and leave.
- Whoever is working shares their screen: the real command and its real output, or the exact diff it's applying.
- Each tile has one status: working, waiting on another agent, needs you, done. A tile pulses amber when a command has run for over a minute, and shows 💤 when an agent has gone quiet.
- Tokens per agent, so the expensive sub-agent is obvious.
- It only calls you in when an agent actually needs you (a permission prompt, a question), not every time a turn ends.
It costs zero tokens: it never calls a model to watch your agents, it just reads files. It runs locally and sends nothing by default.
Yes, they talk
The agents speak their updates out loud, with a small speech model that runs on your machine, and their mouths move with the voice. You can switch to an Animal Crossing–style babble, or mute it.
This is the part people call a gimmick, and on Hacker News some did. Fair. But here's what I found: I notice a voice saying "I need you to approve this" from across the room. I don't notice a terminal that silently stopped scrolling. Sound turned out to be the feature, not the decoration.
Three things I learned reading agent logs
None of these formats is documented, so the reader has to be defensive. A few traps, in case you're building something similar:
-
Token usage is repeated. Claude Code writes the same assistant message once per content block, each copy with identical
usage. Count once permessage.id, or a five-block message costs five times as much. -
"Quiet" doesn't mean "done". The end of a turn is an explicit
stop_reason: "end_turn"mark. Until it arrives the agent is still working, even after a minute of silence. - Most Codex sub-threads aren't yours. On my machine, 34 of 57 Codex rollouts were short automatic "guardian" reviews. Show them all and the list drowns.
I wrote the full field guide (where each tool keeps its sessions, how sub-agents show up, how to survive format changes) in Reading the undocumented session logs of Claude Code, Codex and Mistral Vibe.
Try it
No install, from any terminal (Node 18+):
npx @double_geste/agent-standup@latest --open
No sessions yet? ⚙ → Source → Demo plays a fictional team fixing a slow login page.
It's also a VS Code extension (Cursor and Windsurf via Open VSX), a Claude Code plugin, and a macOS app. MIT licensed, interface in 10 languages: github.com/Atoll92/agent-standup.
Your turn
I'm curious how other people handle this, because I don't think a cartoon call is the only answer:
How many agent sessions do you run at once, and how do you know which one needs you? Separate terminal tabs? tmux? Notifications? Just... checking a lot?
Top comments (18)
From the Auten team: we run three long-lived agent sessions in parallel, and what helped most was each one appending to a shared journal file plus a small task board, so "who needs a human" becomes a grep instead of a tab hunt.
Question: does Standup detect "waiting for me" from the permission prompt itself, or from the session going quiet? Quiet can also just mean a long build or test run.
Hey ! From the prompt itself, not from silence, for exactly the reason you give.
Claude Code keeps a small status file per open session in ~/.claude/sessions/: busy, idle, or waiting while a menu is open (a permission or a question). That's the only reliable signal. In the transcript, a Bash command waiting for your OK looks exactly like one that's running. So a 20-minute test run stays "working", with its live output on that agent's shared screen. Only an open menu makes someone knock on the call.
Older Claude Code versions don't write that file. There, a question or a plan left open in the transcript still counts. A call that has only gone quiet gets a "maybe" on its tile, never a "needs you".
Your journal + task board idea is nice because it works across tools. Do your three sessions write to it themselves, or through a hook?
Thanks, the status file is a much better signal than anything we were guessing at.
Ours write it themselves: each session's instructions say "append one line to the journal after every action" and the board is a tiny CLI they call (list, claim, done). No hook. The weak spot is exactly yours in reverse: if a session stalls mid-step, the journal just goes quiet, so a "last entry older than N minutes" check is the closest we have to your "maybe" tile.
Makes sense. If your three sessions are Claude Code, the two can work together. A quiet journal while the status is "busy" is most likely a long step. A quiet journal while it's "idle" means the turn ended and nobody noticed. That's roughly how the call tells "working" apart from "your turn".
For a stall in the middle of a step: Claude Code writes the output of background commands to a file under /tmp/claude-/…/tasks/. If that file is still growing, the command is still alive. The call streams it live on that agent's shared screen.
That 2x2 (busy/idle status x quiet journal) is cleaner than the single "last entry age" check we use, and it splits exactly the two cases we lump together today. The growing task-output file is a good liveness signal for long steps too. Thanks for spelling it out.
My pleasure, good luck on building Auten it looks nice !
One status per tile is a small mercy. Amber for long commands is the detail I would steal for my own setup.
Thanks! Steal away. The amber was a fix for a real annoyance: a long build or test run looked exactly like a stuck agent, so I kept checking on it for nothing. Now anything running for over a minute pulses amber, and red is kept for "needs you". What does your setup look like, several terminals side by side?
The amber pulse is the part worth stealing. Red only for needs-you keeps the signal clean. Is the pulse on time alone, or on output too?
Time alone: it pulses once a command has been running for a minute, whatever it prints. Output doesn't reset it, because the transcript only records a command when it finishes. For background commands, the shared screen shows their live output, so you can see whether it's still moving.
so output never resets it. the minute is the whole rule?
Yes, the minute is the whole rule. A command that keeps printing is still a long command, and amber only means 'not stuck on you, give it time'. For a background command, the shared screen shows whether its output is still moving.
A printing command still counts as long, so amber reads as give it time rather than stuck. That shared screen check for background work is the useful part.
Side by side would still leave the same hunt, just wider. The tile that says needs-you is the part that changes it.
Exactly, more terminals just make the hunt wider. What changed it for me was one place that says whose turn it is, so I only look when something is actually on me.
One place saying whose turn it is beats hunting through terminals. I only want to look when something is actually on me.
The 34 of 57 Codex rollouts being automatic guardian reviews is the detail that would break this in practice, since showing them all drowns the real work. Deduplicate by message.id too, or a message split across five blocks will look five times as expensive as it is.
Both are handled in the app. Codex threads only join the call if they were explicitly spawned as sub-agents, so the guardian and approval reviews never show up. Token usage is stored once per message.id, so a message split across five blocks counts once. The guardian one surprised me most: without the filter, my Codex list was more than half reviews.