Running three coding agents at once is easy. Noticing when they need you isn't.

Coding agents have genuinely changed how I work, and I don't think that is a controversial thing to say any more. Claude Code, Codex, Cursor, Gemini CLI, Qwen, opencode - most people I know are using two or three of them, not one, and using them on different things at the same time. One session refactoring an API. One writing the landing page. One chewing through a migration. That is a real change in throughput. It is also where a new problem shows up, and it is not the one people talk about. The part nobody plans for Once you have handed an agent a real task, the correct thing to do is leave it alone. So you do. You switch to the other session. You answer a message. You open a browser tab and, if we are being honest, sometimes that tab is not work. This is not a discipline failure. It is what the tool is for. If you had to sit and watch it type, it would not be saving you anything. The trouble is what happens when it comes back. It finishes. Or it stops to ask whether it can run a command. Or it hands you a plan and waits for a yes. And you miss it, because you are three windows deep in something else. Ten minutes later you tab back and find it has been sitting there the whole time, waiting on a one-line answer you could have given instantly. Why that is more expensive than it looks If it were just ten wasted minutes, fine. It isn't. The subscriptions these agents run on are metered in time windows, not in requests you spend when you feel like it. Claude's plans work on a rolling five-hour window with a weekly cap on top. Codex is similar in spirit. The window is running whether you are using it or not. So an agent that sits idle for ten minutes is not costing you ten minutes of your day. It is costing you ten minutes of a window you already paid for, and that you cannot get back. Do that a handful of times in an afternoon and you have quietly moved a chunk of your work into the next window - which means over a week you get less done, not more, even though every individual task felt fast. That is the thing I find genuinely worth optimising. Not the model. Not the prompt. The gap between "the agent needs you" and "you noticed". And that gap is getting harder to close, not easier. Focus is not exactly abundant right now. Running several agents in parallel demands more attention switching, at precisely the moment most of us have less to give. Notifications don't fix it I tried the obvious thing first. A notification tells you something happened and then makes you go somewhere else to deal with it. It is a second thing to dismiss, not a solution. Worse, once you are getting them from three sessions, you start ignoring them, which puts you back where you started with extra noise. What I actually wanted was to answer without leaving what I was doing. Not "go look at the terminal". Just: yes, no, here's the answer. The thing I didn't know I could rely on When I went looking, the useful discovery was this: every one of these agents already tells you what it is doing, if you ask it to. They all support hooks. You register a program, the agent runs it at lifecycle moments - session started, tool about to run, needs permission, finished - and it hands your program a JSON object on stdin describing what is happening. The important one is the permission hook, because it blocks. The agent runs your program and waits. Whatever JSON your program prints on stdout is the decision. Print an allow and the command runs. Print a deny with a reason and the model gets told why. That is the whole mechanism. No plugin API, no daemon, no SDK. Your program is a filter, and for the length of that call it is the thing standing between the agent and the command. The details differ more than you would hope - different config files, different event names, different response envelopes, different timeout units, and one of them treats empty output as "yes" rather than "no decision", which is a fun afternoon. opencode does not use hooks at all; it already runs a local HTTP server for its own interface, so you subscribe to its event stream and answer over HTTP instead. But the shape is the same everywhere: one process can see every agent you are running, and can answer for you. Once that is true, the approval is no longer stuck to the terminal window the agent happens to live in. You can put it anywhere. So I put it at eye level I built this for myself, as a Mac app. Every running session lives in the MacBook notch - which, on most Macs, is doing nothing at all, and is the one part of the screen your eyes already cross a hundred times an hour. Each session shows what it is doing right now and how much of its context is left. When one needs you, the notch opens right there: the actual command, a warning if it looks destructive, and Allow / Deny / Answer. Pressing Allow replies to that blocked hook directly. It does not focus your terminal and it does not synthesise a keystroke - a synthetic keystroke that lands in the wrong window is worse than doing nothing. Which means the failure mode above stops happening. You can be distracted. You can be in a browser, in Figma, in a meeting window. The thing that needs you appears where you are already looking, and answering it costs you one click instead of a context switch. It's called Crew Tower if you want to look at it. It also shows how much of your Claude or Codex quota is left, for the same reason the rest of it exists. I'm curious whether other people are hitting this the same way. If you run more than one agent at a time: how do you currently notice when one is waiting on you - and have you ever measured how much of your window goes to sessions sitting idle? Top comments (0)