Supacode

The deciding trait is the status badge. Every pane tells you whether its agent is working, waiting on you or finished, which sounds trivial until you have six of them and are cycling through windows to find the one asking a question. Attention is the scarce resource when you parallelise, and this is the only thing on the row that manages it directly.

It is one platform, and the terms are unwritten. Pick it if you are on a Mac and already running more agents than you can watch. Pick a multiplexer if that is not your problem.

Observation by configuration injection is clever and brittle in equal measure. The badges depend on hooks written into tools this project does not control, published by companies with no reason to keep that format stable, and when one of them changes it the display does not error, it simply stops being accurate. A pane that reads idle while its agent waits is worse than no badge at all.

What it does right is work over a remote connection as well as locally, with the same detection either way.

1. Decoupling process lifetime from window lifetime is the correct structural decision and the one most desktop wrappers get wrong: an agent killed because a user quit an application is a failure caused entirely by the presentation layer. 2. Reattaching with scrollback intact means the record survives too, not just the process.

2. The same property holds across a dropped remote connection, which is the case that distinguishes a real design from a convenient default. Nothing is published measuring recovery, so the claim is architectural.

Attention at this scale with no stated business model is a decision to defer, not an absence of intent. Two thousand stars is a distribution asset somebody will eventually want to convert, and until the conversion is announced an adopter is guessing whether it arrives as a subscription, a team tier or an acquisition that ends the download.

Moat: the workflow habit, which is genuinely sticky once a team's parallel work lives here. Likely acquirer: a developer-tools company buying the interface and the author together. Position: use it, and keep your worktree process reproducible somewhere else.

Half a fleet is not a rollout. My engineers are split across platforms and this reaches one of them, which means any process I build on it has to have a second process behind it for everyone else, and two processes is worse than the one we already have.

There is no counterparty either: nobody to sign a support agreement, nobody to escalate to and no terms to review. Add no directory login, no audit trail and nothing that runs unattended, and the answer writes itself. Not yet.

This is the worst of both arrangements and it is worth naming precisely. Published source without a grant is not open: no fork, no patch I can distribute, no right to keep using it if the repository disappears, and no defence at all if the author changes their mind. Reading it only tells me what I am not allowed to keep.

The session daemon underneath is at least a component I already know, so my own tooling can attach to those sessions directly and I am not entirely dependent on the application to reach them.