Why does running several Claude Code sessions in parallel get unmanageable?

We had three Claude Code sessions going. One of them reported that it was done. For a second we could not remember what that one had been working on. We opened the terminals one by one, scrolled back, and eventually found it: right, the retry logic.

A few days later the opposite happened. One session had asked us to pick between two options and then sat there for a long while. We were reviewing another session's output the whole time. Nothing tells you this is happening. The AI is just waiting, so there is no error and no notification.

The delay is not really the part that hurts. What hurts is that nobody can tell anything until they open the terminal. Running, finished, waiting on a person: on screen those are all the same thing, a window that stopped scrolling. The only way to separate them is to read the transcript.

Faster models meant we could run more sessions at once. Running more meant we had to keep track of which session had which job. That work does not shrink when the model gets smarter, because the only place that state lives is our heads.

In the order we tried them. All of these helped to some degree.

First, tmux, everything in one window. We still use it. Seeing every session on one screen is genuinely useful. But what you see is the current scroll position, nothing more. If a session asked you something ten minutes ago, you scroll back and find it yourself.

Then a TODO.md in the repo with a marker on whatever was in flight. It is accurate the moment you write it. The problem is that it goes stale the moment a session stops, and nothing tells you it went stale. It ended up being a note we had to maintain by hand.

We also tried one Git branch per job. You can infer how far something got from the commits. What never shows up in a commit is that the AI is waiting for a human to answer.

GitHub Issues was the best of these. Issues persist, you can refer to them by number, another AI can read them, and labels can carry state. What is missing is a place where everything blocked on a human collects by itself. You end up inventing a label convention and then moving labels around by hand. With five sessions open, nobody keeps that up. We did not.

Last resort: ask each session directly. Type "where are you?" and it tells you, accurately. Except that typing it into five terminals in turn is the same checking work we were trying to get rid of.

They stopped in the same place. Every one of these can hold what the work is. None of them has a place for what state the work is in. That state lives in a terminal or in our memory, and closing the terminal takes the first one with it.

And the one state that kept stopping us, blocked on a human answer, never gets a first-class home anywhere.

Between our own product and client work we move between three or four projects in a single day. On a busy day about five AI sessions are open. That count is typical for us, not a measurement.

As a rule of thumb, past three sessions we started losing track. Two we can hold in our heads. At four, one of them reliably becomes the one where we think, wait, what did we give this one? That is our experience, not a claim about people in general.

Two things happened a lot. One: a session was waiting on an answer and we did not notice for a long time. Two: a session had finished and we had not handed it the next thing. An AI stops when it is done, and a stopped window looks exactly like an abandoned one.

So what we were losing was less working time than idle time on work that was ready to hand off and did not get handed off. While we failed to notice, the session waited politely.

What we wanted was to know that an AI is stopped waiting for a person without opening a terminal. So waiting became its own status, separate from in progress. A card set to waiting leaves the Today list and collects in a view of its own, so everything we can take our hands off piles up in one place.

The other thing we wanted was for the AI to record what it is doing, rather than us. Anything a person has to remember, that person eventually forgets. The flow ended up like this.

1. 1One job, one card. Each card gets a number like dz51.
2. 2When we start a session, we hand it the number and nothing else. "Do dz51" is enough. Not handing the same card to two sessions is on us.
3. 3When the AI picks the work up, the card goes to in progress.
4. 4Once it is moving, the card shows an AI-working mark. The mark runs on freshness: every step the AI takes pushes the timestamp forward, and five minutes after the last signal the card drops out of working. Nothing can pretend to be busy.
5. 5When a decision is needed, the AI asks with the options spelled out. A browser notification fires.
6. 6If it is stopped waiting on a reply from us or from someone else, the card goes to waiting. It leaves Today and moves to the waiting view.
7. 7A card can only be completed after a person approves. An AI cannot mark its own work done.

There is also a dependency mechanism for pulling only the cards that can start right now, but that belongs in another article.

Opening terminals one by one to check on things is gone. Whether the mark is moving or stopped decides which session we go back to.

The stretches where a session was waiting on us unnoticed got shorter. We have not measured that. It is how it feels.

"What did we give this one?" is answered by a card number now. With the remembering moved out of our heads, adding another session stopped feeling risky.

The parts that are not solved, plainly. Showing the working mark for Claude Code needs a one-time connector install, which Claude Code does itself if you ask it to connect to Dazbench. claude.ai and ChatGPT show it with no setup. The deciding is still a human job, and waiting cards pile up just as fast as before. Handing one card to two sessions is still a mistake we can make. And we have no measured answer for how many parallel sessions actually work.