Architecture
Five agent harnesses, one honest status light
Knowing whether an agent is working, stuck, or waiting on you is harder than it sounds when every harness reports differently.
4 min read
Run eight agents at once and the interesting question is never what they are doing. It is which one needs you. A grid of eight scrolling terminals answers that question badly — by the time you have read enough output to tell, the answer has changed.
So NabuCode resolves every pane to one of five states: working, needs you, idle, done, error. One dot per pane. You are supposed to be able to sweep the grid and know where to look.
Nobody agrees on how to say it
The difficulty is that NabuCode drives five different harnesses in the same window — Claude Code, Codex, Gemini, OpenCode, plus a generic CLI mode and a plain shell — and they do not report their state the same way. Some emit hook events. Some only change the terminal title. Some tell you nothing at all, and a plain shell has no opinion about whether it needs you.
Three signals, ranked
- Harness hook events, where the harness supports them. Most reliable, least available.
- Terminal-title parsing, which several harnesses update as they change phase.
- A screen-fingerprint heuristic over what is actually on the pane — the fallback that works everywhere and trusts you least.
An arbiter ranks those signals rather than picking one. A hook event beats a parsed title; a parsed title beats a fingerprint. The dot shows the best evidence available for that pane right now, not the output of whichever detector happened to run last.
Why bother ranking
Because a status light that is sometimes wrong is worse than no status light. If needs you shows up when nothing needs you, you stop believing the dots within a day, and then you are back to reading eight terminals. Ranking the signals is how the cheap heuristic stays useful without being allowed to overrule the reliable one.
The bar for an ambient indicator is not accuracy. It is whether you still trust it in week three.