The context-switching tax on running multiple agents.

I used to run a handful of Claude Code, Gemini CLI and Codex sessions at once, spread across different terminals and tabs. Every time I switched context I would lose focus for about ten seconds, and somehow end up on Instagram Reels. Classic.

The interesting part is that the ten seconds was never the real cost. Ten seconds, a few dozen times a day, is a rounding error. The cost was that each switch was an opportunity to stop concentrating, and a decent number of those opportunities got taken.

What the tabs were actually costing

Running several agents in parallel is genuinely useful. One works through a refactor while another writes tests while a third investigates something unrelated. The problem is not the agents, it is that a terminal tab gives you no idea what is happening inside it until you go and look.

So you go and look. Then you look at the next one. Somewhere in that loop you are not really supervising anything, you are just doing rounds, and every round has a gap in it where attention can leak.

The bottleneck was never the models. It was me, hunting for which tab had changed.

What changed

I tried Xirp by Spotify, and everything now lives in one place. All the sessions, side by side, each in its own isolated worktree. I can see what is happening instead of tab-hunting and drifting.

The isolated worktrees matter more than they sound. Running several agents against one working copy means they trip over each other: competing edits to the same files, one agent's half-finished state confusing the next, and a branch that ends up holding three unrelated changes. A worktree per session means each one gets its own checkout, so parallel work stays parallel instead of quietly merging into a mess you have to untangle later.

It is the biggest personal productivity jump I have had in a while, and notably not because the agents got smarter. The constant context-switching tax basically disappeared.

What I am looking at next

The organisational context and shared team features. Parallel agents are a solved problem for one person now. Several people running several agents against the same codebase is a different question, and the coordination problem there looks a lot like the one I ran into when five models built an app together: who can see what, and who is allowed to change it. That is where I expect the interesting failure modes to be.

If you are setting this up and something behaves strangely, I am happy to help. I have already hit a few of the sharp edges.