Problem: I run several AI CLIs at once (Claude Code, Codex, Qwen). Two things kept breaking overnight runs: an agent quits after an hour (network error, or it just decides it's done), and sub-agents fudge their reports when they hand work back. The existing tools let me see many agents. None of them made one agent responsible for the others.
What Polter does: it's a Ghostty fork with an MCP layer. Any MCP-capable CLI can be the supervisor. It opens tabs, starts other CLIs, types into them, reads their screens. Workers report into a group chat and a shared task list. If a worker's screen goes quiet, the supervisor is told. If the supervisor goes quiet, Polter pokes it.
Here's what that actually looks like:
https://www.youtube.com/watch?v=_u-pgdNeqCc
How it compares (from each project's README/docs, Sept 2026 — correct me if I got something wrong):
| Polter | Claude Code Agent View | cmux | herdr | Claude Squad | |
|---|---|---|---|---|---|
| Works with any CLI (Codex, Qwen, opencode…) | Yes | No, Claude Code sessions only | Yes | Yes | Claude Code, Codex, Gemini, Aider |
| Agents can drive the terminal (read screen, type, open tabs) | Yes, via MCP | No | Yes, via CLI + socket | Yes, via socket | No |
| One agent supervises others (roles, task list, group chat) | Built in | No (you supervise) | You build it on the API | You build it on the API | No |
| Stopped worker → someone is notified | Supervisor agent is told; it can restart | You are notified; unexpected exits auto-restart | You are notified | You are notified (state in sidebar) | Not mentioned |
| Supervisor itself gets nudged if idle | Yes | No | No | No | No |
| Needs API keys | No, uses your CLIs' own login | No | No | No | No |
| Platform | macOS, Windows (63/72 actions), Linux from source | Wherever Claude Code runs | macOS only | macOS, Linux, Windows beta | macOS, Linux |
| Offline / no account | Yes | — | Yes | Yes | Yes |
Honest gaps: only Claude Code is tested end-to-end as supervisor. Codex/Qwen/opencode work fine as workers; their supervisor path is untested. Windows is missing 9 actions. It's a fork, so upstream Ghostty updates get merged with some lag.
What Polter won't do: answer permission prompts for an agent, unlock a tab you've locked, or bypass a CLI's own permissions. Those are hard-coded, not prompts.
MIT licensed: https://github.com/Lugia123/polter
Top comments (7)
I personally use Qoder for long running tasks (beyond the IDE I built), Qoder is AWESOME, though just a note, alot of agent platforms have a /schedule command, which you can use to set a recursive scheduled task to keep the agent alive. Or you can instruct it to use a cron to recheck. They all use it, that's how they 'wait' for a tool to return data, or a build to finish. So if you use it smart, you can use it as a recursive function that keeps the agent alive throughout the night.
That being said, Qoder is really solid as is without it. I set a goal for Dwarven Stronghold, refactoring 3000+ files, day 4 of it running continuously (24/7), it makes solid progress and doesnt really stop. If you instruct it to use sub-agents, it spawns 4, runs them, if a sub-agent dies, or stalls, it spawns a new one and the old 1 just remains dormant till you get back to interrupt start it.
That's a good trick, and yeah, most agent CLIs will happily keep themselves alive with a recursive schedule or cron loop like that.
The angle I went with is a bit different: instead of getting the agent itself to fake liveness overnight, I have a separate session (just a Claude Code tab) actually watching the others — how long a screen's been still, whether it's stuck on a permission prompt vs. genuinely still computing. Feels like it holds up better over a multi-day run, since the agent doesn't need to know it's being kept alive, it just gets nudged or restarted from outside when it actually stalls.
True, but what's the token cost? It likely just runs a recursive function that polls for activity, then either sends an api request, or a 'click' to continue it, if it's constantly polling, then it uses tokens if it checks it manually, if it uses a recursive function, then the AI part of the equation isnt doing anything?
Fair question, but it actually works the other way around. The supervisor isn't actively polling the other agents. Polter itself watches the workers, and when a worker's screen stops changing, it pings the supervisor at intervals, something like "tab 3: idle 4 min."
Only then does the supervisor use an MCP tool to read that worker's screen, see what it's doing, and decide whether to step in. A script can't reliably tell whether an agent is still working or actually stuck, so that judgment is handed to the supervisor model.
It doesn't burn many tokens either, since the supervisor only reads the most recent screen content, not the terminal's entire history. So the cost scales with how many times something stalls, not with how long it runs.
Another plus: Polter works with your regular subscription plan rather than pay-per-token API billing. No API key to set up. You just launch Claude Code or Codex the same way you would for your own dev work.
You know... If you use the same model for the supervisor and the agent, then context caching would trigger and it'd be essentially a 90+% discount on input tokens, which means you'd be able to get the benefit for sub 10% cost increase via token plans? Not always the best approach, eg. if you use Haiku to code and Opus to supervise, but worth mentioning. It's a good move having the agent poll the supervisor, but there's a catch, if the agent is hanging, or looping, it likely wont poll the supervisor, so rather set that as a fixed interval for subscribed agents, that way it's deterministic and given it's the same codebase, having the supervisor monitor would improve the seams' transition.
Good point on caching. I checked the Claude Code docs: parallel sessions in the same directory on the same model do build matching prefixes and read each other's cache, so the supervisor and workers can share the static system prompt + project context part. That part's cheap to share.
The bigger saving though is the supervisor's own conversation caching across turns (and on a subscription, Claude Code gives the main conversation a 1h TTL, so it survives the idle gaps). The worker screen text it reads is new input either way, so I wouldn't put it at "sub-10%", but same-model setups definitely help.
On polling: the workers don't poll anything. Polter watches their terminals from outside, so a hung agent still gets flagged since its screen stops changing.
You're right about loops though: an agent stuck in a retry loop keeps its screen changing and never trips the idle check. A fixed-interval check-in as a fallback makes sense, I'll add that. Thanks!
Something that seems to be fixed, but has surfaced in the past, is that Gemini through antigravity, would sometimes hit a bug where it writes the same sentence continuously. Given that it's output tokens, it gets really expensive really fast, so worth adding another guardrail for repetition, that way you can stop token bleed early?