Running several coding agents at once: what breaks at three

By Meffysto · updated October 4, 2026

One coding agent fits in a terminal. Two fit in tabs. Somewhere around the third, something breaks, and it isn't your machine. It's your attention. Here are the four problems, in the order they show up, and the known ways out.

Why three is the threshold

With one agent you read its output live. You are its main loop. With two you alternate, miss a few things, and scrollback saves you. By the third, three counters are running in your head at once: where is each one, which one is waiting for me, which one is burning time for nothing.

That last one is the expensive one. An agent stuck for ten minutes on a permission prompt is ten minutes of subscription window gone and a pile of work that didn't happen. And you only find out when you happen to walk past its tab.

Problem 1: knowing who's stuck without looking

The question you need answered at a glance has three possible answers: working, needs you, done. There are three ways to get that answer, from most to least reliable.

CLI hooks. Most recent agents can report their own state: end of turn, permission request, status line. It's the only source that asserts instead of guessing. Use it wherever it exists.
The window title. Many CLIs write their state into the terminal title with an OSC sequence. Free, standard, often good enough.
Reading the screen. Checking whether the bottom of the terminal is still changing. It tells "moving" from "not moving", but not "thinking" from "waiting for an answer". Fine as a fallback, bad as the truth.

The classic trap is treating "nothing's moving" as "it's done". An agent showing a question and waiting doesn't move either. You'll see the most common case every week: the first time Claude Code runs in a new folder, it asks whether it can trust the files in it. While that prompt is on screen there's no input field. Anything you send lands nowhere, and a naive dashboard shows the agent as idle.

In Fauconnier every window carries a status dot: working, needs you, done. When an agent asks a question, the dot flips before you've noticed anything. And one question, "where are we at?", gives you the state of every open agent with its name and scene.

Problem 2: approving without blocking

You want your agents to ask before doing anything irreversible. You don't want them sitting idle while they wait for you. Those two only conflict when approval is synchronous.

The way out is a request queue. The agent files its request, keeps going on everything that doesn't depend on it, and you clear the queue when it suits you, in a batch rather than one modal at a time. Two rules make it livable:

Deny by default on the irreversible. Dropping data, pushing to main, restarting a service: no answer means no.
Exclusion beats blanket approval. "Approve everything except the delete" must exclude the delete, even if it joined the queue between the moment you looked and the moment you spoke.

That second rule sounds like a detail. It isn't. A batch approval that lets through the one item you just excluded is the kind of bug you only forgive once.

Problem 3: chaining work without babysitting

"When that one's done, the other picks it up" is the most common move and the worst tooled. Most people do it with a stopwatch: come back in ten minutes, look, copy, paste. A proper chain fires on the agent's actual state (see problem 1), not on a timer. It also has to be visible, so you can read what's pending, and cancellable, because you change your mind more often than you'd think.

In practice it's one sentence: "when Merlin's done, send Milan: pick up the migration". The handoff waits until Merlin has really finished its turn. If Merlin stops on a question instead, nothing gets sent, and the status dot tells you why.

Problem 4: remembering from one day to the next

This is the hole an agent can't plug for itself: every session starts from zero. You explain again that the build goes through make, that this folder is generated, that this API lies about its error codes. Three layers are enough, and they work better as readable files than as an opaque store:

session history, indexed and searchable;
your corrections, turned into notes and fed back on the next turn ("remember the build goes through make");
repeated procedures, written as SKILL.md files, an open format several ecosystems already read.

One detail matters a lot: a procedure written by an agent should stay disabled until you've read it. Otherwise you end up with a tool that quietly picks up habits you never signed off on.

Three first-week mistakes

Everyone makes them. We did too.

Repeating an instruction without looking at the screen. If the agent is sitting on a menu, your text goes nowhere. Read what it's showing first. A menu wants a key (1, Enter, Esc), not a sentence.
Targeting without naming. "Tell the agent to run the tests" goes to whichever window you're looking at, which may not be the right one. Name every agent and use the name. When two names are too close, a good tool doesn't guess: it does nothing and asks.
Restarting instead of unblocking. Restarting an agent throws away its work in progress. Nine times out of ten it was waiting for a single keypress.

How many agents, really?

The limit is almost never the machine. It's your attention and your subscription windows. Two agents from the same vendor on the same plan share one quota: five Claudes at once drain the window five times faster. Mixing CLIs (Claude on the refactor, Codex on the database, Gemini on the docs) spreads the load across plans. Fauconnier treats quota as a scheduling state rather than an error: when a window runs out, that engine pauses and the app resumes at the reset.

In practice, three to five active agents are manageable for one person doing something else on the side. Beyond that, coordination has to be tooled. Fauconnier allows up to nine agents per scene, one scene per project.

What it looks like assembled

Put together, those four pieces describe a cockpit: one screen where every session is visible at once, an exact state per agent, an approval queue, event-driven handoffs, and a memory you can read. The rest (committing, opening a pull request, creating a worktree) agents already do well on their own. Building buttons for that adds work instead of removing it.

Frequently asked questions

How many coding agents can I run at the same time?

Technically, a lot. In practice three to five active agents stay manageable for one person, as long as you can see their state at a glance. The real limit is quota: agents on the same subscription share one window. Fauconnier allows up to nine agents per scene.

Do I need a git worktree per agent?

Only if two agents edit the same files at the same time. On separate parts of the same repo (frontend, API, docs) one folder is fine. If you do want a worktree, ask the agent: it can create one itself.

How do I know an agent is waiting for me?

From CLI hooks where they exist, otherwise from the terminal title, and as a last resort by reading the bottom of the screen. A screen that stopped moving doesn't mean the agent is done: it may be waiting on a question.

Can I mix Claude Code, Codex and Gemini on one project?

Yes, and it's often a good idea: each has its strengths and its own quota. Give them separate areas of work and one shared place to see who's doing what.

Fauconnier is that cockpit, native to macOS. Thirteen supported CLIs run in real terminals that tile themselves, each agent's state is read at the source, approvals queue instead of blocking, handoffs wait on real state, and the memory is files you can read. Free, no account, your own subscriptions.

Discover Fauconnier