The hard part of running five coding agents is not the model, it is the process tree

Seventy-seven megabytes per pane is the most instructive number in the write-up ^[14]. It is not a fault that announces itself, because the process the app spawned really does use about that much: the pane's own process is a shell, the agent CLI is its child, and a dev server the agent started is a grandchild or has been reparented away entirely ^[13]. Measure the handle you hold and you get the same figure in every cell, with every agent apparently asleep.

What replaces that measurement is not a better measurement. It is an ownership argument in three passes ^[20]. The first walks the tree from a single machine-wide `Get-CimInstance Win32_Process` snapshot, cached for a second and a half and shared by everything that needs it in that polling cycle ^[15]. The second gives up on lineage: if a process's executable path or command line points inside a worktree, it belongs to that worktree's pane ^[16]. The third reads the process's current directory, which on Windows means going through `ntdll` because no API exposes it ^[17]. Each pass answers a weaker question than the one before, and the author says plainly that the result is a heuristic that gets the common cases right ^[18].

The cache is the part worth stealing. One enumeration of every process on the machine per cycle, reused by all consumers, means the cost does not scale with panes: a five-agent grid pays for one snapshot rather than five ^[21].

All of that sits on top of an isolation story that is close to trivial. A shell is spawned with node-pty, HOME is redirected to the pane's account directory, cwd is set to its worktree, and the command is typed in ^[3]. That is what buys two simultaneous Claude logins where `~/.claude` means something different in each ^[6], and four agents editing one repository without overwriting each other ^[7]. The author notes the Windows specifics of both are genuinely fiddly and covered separately ^[8]. Nothing parses agent output and nothing wraps an API ^[5], which is why supporting a new CLI is a row in a list instead of a release ^[4]. The stated reason for refusing readiness detection is that same economy: read agent output to decide whether a pane is ready, and every upstream CLI update becomes a potential outage ^[12]. The compensation is that raw-keystroke broadcast works against anything that reads a terminal, a REPL or an interactive rebase included ^[10].

The honesty the piece promises about what does not survive a restart ^[19] is where the data model has already answered the question, even if the published excerpt stops before spelling it out. A pane is described entirely by strings and paths ^[2], so a restart can rebuild the container: same HOME, same worktree, same command. What cannot come back is anything that lived in the pty and the process tree hanging off it ^[22]. That last inference is mine rather than the author's, but it is the line any tool in this shape has to draw, and the one users deserve written down: the durable state is a config file, and the session is something you agreed in advance to lose.