The flock: three dashboards, because one view can't hold a fleet
Two coding agents in the same git checkout silently destroy each other’s uncommitted work. Not with a conflict, not with an error — one writes a file, the other writes it back, and the loser’s work is gone with nothing in any log to say it happened. Every individual session reports success. The fleet reports success. The work is still gone.
That is the shape of every expensive failure I have hit running more than a couple of agents at once: it is invisible from inside any single session, and it is obvious the moment you can see all of them on one screen. So I built the screen. Then I built two more, and the reason there are three is the interesting part.
roost: top, for the thing top structurally cannot see
top shows you processes. A Claude Code subagent is not one — it runs as a
sidechain inside its parent’s process, so anything that watches pids is blind
to it by construction. roost shows
every live session, the model it is on, how much context it has burned, and the
subagents each one spawned.
It groups by what it costs to ignore a session rather than by size. NEAR LIMIT
is about to stop working. PARKED + COSTLY bills its entire held context on the
next turn whether you look at it or not. Everything quiet collapses to a single
line, so two dozen sessions do not scroll the important three off the bottom.
One file, standard library only, Python 3.9+.
brew install gmhoward9289-ops/tap/roost
A session reports intent; git reports what landed
roost reads sessions, and a session’s account of itself is exactly that — the task string, the model, the context burn, and eventually a claim that it finished. What did this agent actually do is a different question, and only one of the two sources answering it can be wrong. It is never git.
leghorn answers the other half: every session joined to its worktree and its real git state, your GitHub CI and open PRs with failures pinned until they go green, and a commit feed across every repo, newest first. Sessions sharing a working tree are marked contested — that is the failure in the first paragraph of this post, given a glyph.
The GitHub pane ranks by cost of ignoring, same principle as roost’s buckets: running first, then red — a failure must not be allowed to scroll away — then stuck-in-queue, then everything else by freshness.
brew install gmhoward9289-ops/tap/leghorn
Two true views that disagree by eye are their own failure mode
Both of those are correct at once and neither contains the other, which meant watching a fleet meant watching two windows and joining them in my head. That join is where I made mistakes: the session I was worried about in one window was not obviously the session behind the red build in the other.
legbar draws both lanes on one canvas — from a single discovery layer, specifically so the two panes can never disagree about which repo a session is in. That constraint is the whole design; a merged view that stitches two independent scans together and guesses at the correspondence is worse than two honest windows, because it is confidently wrong instead of visibly incomplete.
It also sees Cursor agents, marked cu. Cursor writes no session marker and
no claim file, so any fleet view that only reads Claude’s session directory is
blind to every Cursor agent running beside it. Here is real output from my box:
legbar 5 sessions | 1 cursor | 1 need input | 15 ci red | 125k held | 18:37:00
SESSIONS CI / PRS
-------- --------
cc heron-ops-3c FB5 ###------- 32% needsinput dev X roost ci
cc swamp-ops-ad OP5 ###------- 25% working dev X roost #56 ci: skip winget~
cc heron-ops-16 FB5 #--------- 10% working dev X copilot-money~ Tests
cc claude-10 OP5 #--------- 8% idle Claude > leghorn release
cu c5468eb1 - - idle dev . leghorn #61 checks pending
One of those five sessions was not a Claude session at all. Before legbar, it did not exist as far as any dashboard I owned was concerned.
What they all refuse to do
All three are read-only by construction. They read session transcripts, run
gh and read-only git plumbing, and probe localhost ports. They do not write to
a tree, a registry, or a session. roost has exactly one exception and it is
gated behind an arming key with an EXPERIMENTAL marker on screen, because
there is no local control channel into a running session and ending a process is
the only lever that exists from outside it.
Every data source is optional. No gh? The GitHub pane says so and the rest
keeps working. A missing source degrades to a labelled gap, never an error —
a monitoring tool that dies because one of its inputs is absent has chosen the
worst available behaviour.
In order of what they cost me to learn
Aggregate state is a different kind of data, not more of the same. Nothing in a single session’s output tells you that another session is in the same checkout. The information only exists in the join, which means no amount of improving the individual agent produces it.
Rank by cost of ignoring, not by magnitude. Sorting by context size puts the biggest session first; sorting by consequence puts the one that is about to stop working first. Those are usually different rows.
Refuse to guess when you can refuse to merge. legbar exists because I wanted one screen, and it is trustworthy only because the one screen comes from one scan. If I had merged roost’s and leghorn’s outputs post-hoc I would have shipped it a week earlier and spent every week since not quite trusting it.
Without any of this the fleet looks fine, and that is the trap: every agent reports that it finished its task, because from where each one is standing it did. The contested checkout, the red build nobody is watching, the Cursor agent holding a tree — none of them produce an error anywhere. You find out days later from a diff that is missing work, and by then there is no log that says why.
From my swamp to yours.