I run six or seven projects at any given time. Each one has at least one AI agent running in a terminal — Claude Code, sometimes Aider, sometimes something else. They read files, write code, run tests, ask me questions. All at once.
And I have no idea what any of them are doing.
Not because they're secretive. Because the tools I use — great tools, mind you — were built for a world where one person uses one terminal for one thing. That world ended about a year ago.
The Actual Problem
Here's what a typical afternoon looks like. Claude Code is refactoring authentication in project A. Another instance is writing tests in project B. A third one hit a compilation error in project C ten minutes ago and is stuck in a retry loop — but I don't know that because it's on a different desktop and I haven't checked.
Meanwhile, project D's agent finished its task twelve minutes ago and is waiting for my approval. I'll find out when I eventually Cmd+Tab my way over there and see the prompt blinking at me.
This is the org chart problem from my last piece, made visceral. I have employees. They're working. I have no dashboard. No standup. No Slack channel. Just a grid of desktops I cycle through like a security guard checking monitors.
Why Terminals Don't Know
Ghostty is excellent. Fast, GPU-accelerated, beautiful. But it renders characters on a screen. That's what a terminal does. It doesn't know — can't know — that the characters scrolling past are an AI agent editing your authentication middleware.
tmux gives you panes. Split, resize, scroll. It's a spatial organizer for text streams. It doesn't know that one pane is stuck and another is waiting for input. It shows you the same green bar regardless.
The existing tools that try to fix this — Claude Squad, Agent Deck — are tmux wrappers. They manage processes. But they still treat agents as opaque text streams. And they look like 1997.
The gap isn't features. It's perspective. These tools see terminals. They don't see agents.
Observe, Never Orchestrate
So I built something. I called it Cosmodrome — a mission control for the fleet of agents that now live on my machine.
The core idea is one sentence: show me what all my agents are doing without touching any of them.
This constraint matters. I don't want a tool that sends commands to my agents, auto-approves their requests, or decides what to do on my behalf. I've thought too much about delegation gone wrong to want that. The agent works. I supervise. Cosmodrome is the glass between me and the factory floor.
The first version was a native macOS app. Swift, Metal, GPU-accelerated, sub-4ms frame times. One window, all projects in a sidebar, all sessions in a grid. It worked. But after a few weeks of using it, I noticed something: the most valuable part wasn't the window. It was the thing running behind the window — the pattern matching, the state detection, the event extraction. The rendering was just one way to look at what the intelligence layer already knew.
So I pulled the brain out of the cockpit.
The result is cosmod — a headless daemon written in Go.
It runs silently in the background. Discovers agent processes on your
machine — Claude Code, Aider, Codex, Gemini — and attaches to their
TTYs as a secondary reader. No configuration. No setup. You start it
once and forget it's there.
Reading the Room
Every time an agent writes to the terminal, cosmod reads the output and figures out what's happening. Not with an LLM — that would be too slow and too expensive. With pattern matching, inline, on the I/O thread.
Four states are all you need: inactive (grey), working (green), needs input (yellow), error (red). That's it. Those four states, exposed through a simple API, changed everything for me.
Then there's what I call the session narrative. Instead of just "working," the status says "Editing auth module — 8 files, 2m." Instead of "error," it says "Stuck: compile error (5x, 3m)." No LLM involved. Just heuristics analyzing what the agent actually did.
It knows when an agent is stuck in a loop — same error three times in a row. It knows when a task is done — the agent went quiet after a burst of activity. It knows what files changed and roughly what happened. It even detects sub-agents spawning inside a session. All from watching the output scroll by.
For tools that support it — like Claude Code hooks — cosmod also receives structured events directly. Two signal paths: noisy but universal (TTY pattern matching) and clean but specific (hooks). The daemon trusts the structured path more, but never depends on it.
The Activity Stream
This is the feature that surprised me most. A structured timeline of everything every agent did. Files created, commands run, errors hit, tasks completed, sub-agents spawned. Across all projects.
I built it because I kept asking myself: "Wait, what did the agent in project C do while I was focused on project A?" And the answer was always: scroll up, read the terminal output, try to piece it together from a wall of text.
cosmod does the piecing together for you. Passively. No agent cooperation required. It watches the output, extracts structure, and exposes it as a REST API and a real-time SSE stream.
Because it's an API, any tool can consume it. A dashboard. A script. A notification system. Another agent. The activity log went from being a screen in an app to being infrastructure.
The Philosophy Under the Hood
I think a lot about what this tool should not be.
It's not an IDE. No file trees, no syntax highlighting, no LSP. It watches terminal output. That's the job.
It's not an orchestrator. No auto-triggering tasks, no agent pipelines, no workflows. The developer decides what happens next. Always.
It's not a process manager. It doesn't restart crashed agents or manage their lifecycle. It tells you they crashed and lets you decide.
Every time I'm tempted to add a "smart" feature — auto-approve safe operations, chain agents together, pre-fill responses — I ask myself one question: would a good mission control operator want the console to start pressing buttons on its own?
The answer is always no.
But there's a second design principle that only emerged with the daemon: separate what you know from how you show it. When observation lives inside a GUI, observation only happens when the GUI is open. When you extract it into a daemon, observation is continuous. The daemon is infrastructure — like a database or a web server. Always running, always available, indifferent to how you choose to look at the data.
A good mission control room has instruments that are always recording, whether or not anyone is watching the screens. The screens are just one way to read the data. The instruments are the real system.
So What?
I wrote a few weeks ago that running multiple agents makes you your own middle manager. Cosmodrome was the management dashboard I wished I had. cosmod is its evolution — the management infrastructure that runs whether or not the dashboard is open.
But building it taught me something I didn't expect. The problem isn't that agents are hard to manage. It's that we don't even have the vocabulary for what managing them means. We borrow from DevOps (monitoring, orchestration) and from management theory (delegation, oversight) and from UX (dashboards, notifications), and none of it quite fits.
This is a new kind of work. Not coding. Not managing. Something in between that doesn't have a name yet. You're reading output, judging quality, deciding priorities, context-switching across domains — all while the agents do the actual typing.
The cockpit was missing. I built one. Then I realized the cockpit was two things pretending to be one — an intelligence layer and a rendering layer. Pulling the brain out made it more powerful, not less. The cockpit is no longer an application. It's a layer. Any application can become a cockpit now.
Maybe that's the pattern with all of this. The first version of a tool does everything. The second version separates what it knows from how it shows. The third version, someone else builds.
*cosmod runs on my machine now. Silently. I forget it's there until I need it, which is the whole point. Still building. Still learning what the cockpit actually is.*