I run six coding agents on the same laptop: Qoder, Claude Code, Codex, ZCode, WorkBuddy, OpenCode. Not for a benchmark — for real work, on different projects, at the same time.
What I did not expect is that the hard part is not throughput. It is knowing which one is stopped.
Three windows, three identical prompts
Last week I spent eleven minutes rewriting a prompt in one window while another session was sitting on a permission question, and a third had already died on an error. All three looked the same on screen: cursor blinking, empty input, exactly how I left them.
Tiling the windows does not fix this, because a window shows its last render, not its current state. A killed CLI leaves a prompt behind that looks identical to an idle one. You type into it and discover the history is gone.
Desktop notifications do not fix it either. Notifications carry "task finished". The two states that cost me time are it is asking me something and it stopped on an error, and neither of them fires a notification — from the tool's point of view the first one did its job and the second one never finished.
The state was already on disk
Every one of those six tools writes a local log: Codex keeps rollouts, Claude Code keeps transcripts, the others keep session stores and local databases. Different formats, same payload: what happened last in this session.
So I wrote Agent Ping, a menu bar panel that reads those logs and sorts sessions into five states, grouped, with the "waiting on you" group first — and it carries the verbatim question, not "1 pending item". Click a row, you land back in that session: in-app sessions open in their app, CLI sessions resume.
The unit of value is one row: a session, a state, a way back.
Three things it deliberately does not do
It does not orchestrate. Plenty of tools dispatch work between agents now, and that is a bigger idea than a status panel. But once an orchestrator owns the flow, it also owns the explanation of "what is happening now", and when it breaks you debug the orchestrator instead of your agents. A panel that only reads logs has a cheap property: when the panel says a session is stuck on a permission prompt, you can open the same file and check.
It makes no network calls. The whole binary opens zero connections — nm -u on the shipped bundle shows no socket symbols. These logs contain your prompts, your code, and the file names you are working on. A tool that sits next to every session all day is the last place that should phone home.
It does not claim rewards on your behalf. Some of these tools keep free-credit state on local disk. The panel shows it and, at most, brings that app to the front. You click.
What it cannot do, listed on screen
The first release has specific gaps, and they are in the README rather than in a support thread:
- ZCode does not expose a session-level URL. "Jump to that session" is a workaround that drives its own ⌘K palette and needs Accessibility permission; without it the row degrades to "activate the app". If the workspace was never opened inside ZCode's UI, its search pool does not contain the session at all.
- The Linux status item and banners were verified against a third-party tray host inside a container, not on a real KDE/GNOME desktop. Clicking a banner does not navigate on Linux.
- Six sources, not "all agents". Other formats are not parsed, so those tools do not appear.
Install
macOS 13+ is a menu bar app; Linux is an X11 tray item; six UI languages. There is no prebuilt binary — the formula compiles from the tagged source, about a minute on Apple silicon, and needs Xcode command line tools once.
brew tap DreamOfXM/agent-ping https://github.com/DreamOfXM/agent-ping
brew trust dreamofxm/agent-ping
brew install agent-ping
agent-ping
Repo: https://github.com/DreamOfXM/agent-ping (Apache-2.0). Site: https://dreamofxm.github.io/agent-ping/en/
When this is useless
If you run one agent, a status panel is overhead — one session cannot be waiting on you out of sight. It starts paying off when two or three run at once and at least one is parked on a confirmation or already dead, and the only way to find out is clicking through windows.
That is the whole thesis. Everything else in the repo is the part where that turns out to be harder than it sounds: six log formats, six ways of encoding "needs input", and three of them inconsistent about whether a session that errored is still alive.
Top comments (0)