herdr‑cockpit · Herdr layouts and mods for watching orch
Period — Present
herdr‑cockpit is the set of Herdr layouts and mods I built so that orch runs are easy to follow. It shows the orchestrating main session, worker agent sessions spread across accounts and machines, and remaining usage allowances by provider on one screen. It also works with plain CLI sessions without orch.
Sessions and usage across accounts and machines on one screen
- Top bar with remaining usage allowances for Codex, Claude and Gemini, reset times, CPU and RAM
- Machine, space, tab and pane tree, with an agent list that counts workers per main session
- A grid of this computer's main‑session terminals that takes input directly (hub)
- Routing spoken or typed instructions to the right main session, with Korean voice input (nexus)
- Hiding and restoring tabs of disconnected remote machines
- A Go helper on each machine that collects usage and pane data
Different logins and rate limits per provider
- Problem
- Reading Codex, Claude and Gemini usage meant handling a different login and rate limit for each provider.
- Solution
- Authentication, requests, caching and retry intervals live in a Go helper on each machine. The screen only receives JSON and never handles credentials.
Late responses while switching machines
- Problem
- A late response from the previous machine could overwrite usage for the machine on screen after a switch.
- Solution
- Responses are kept per machine, and only the selected machine's response updates the screen. Switching machines quickly no longer mixes usage from another machine into the view.
Instructions that could reach the wrong session
- Problem
- A spoken or short typed instruction could be ambiguous about which main session it was for.
- Solution
- A model picks the target from this computer's main sessions only. Below 0.6 confidence it asks with candidates, and on failure or after 20 seconds it sends nothing.
Overlapping layout changes
- Problem
- In the view that gathers several main sessions into one grid, session list and layout changes could overlap asynchronously. A change that finished late could bring back a view that was already gone.
- Solution
- Layout writes run one at a time, and the open view is kept as one shared state. When the session list changes, the view waits 500 ms and applies the change once. A late write no longer selects an outdated view.