November 3, 2026
How many agents can you run at once before your judgment drops?
Everyone has a number of agents they run at once. Nobody measured it. What people say, what they do, and a check you can run on your own last week.
On 27 August 2026, a developer asked on Hacker News: “How many of you juggle multiple agent sessions?”
If you run Claude Code in four terminal tabs, or Codex, or Cursor background agents in git worktrees and tmux panes, you have probably asked yourself the same thing. The replies ran from three to five, up to “8 is my limit”. Boris Cherny, who created Claude Code, wrote on X that he runs five in parallel. Simon Willison runs four. Addy Osmani puts his limit at three to four.
Everyone has a number. Nobody measured it.
By the end of this post, you will have a way to find your own number from your own record of the past week, and to see why that number moves.
What people are saying
In the past year, running parallel coding agents has turned from a setup puzzle into an argument about AI coding fatigue. The two largest Hacker News threads on it, “AI fatigue is real and nobody talks about it” (471 points) and “I think I have LLM burnout” (408 points), drew over 680 comments between them.
On Lenny’s Podcast in April, Simon Willison described what four sessions did to his morning:
“I can fire up four agents in parallel and have them work on four different problems. And by like 11 AM, I am wiped out for the day.”
In a 15 July video watched over 322,885 times, Matt Pocock explained why the day feels heavier: manual coding had easy stretches that let your brain rest, and AI removes them, so you make lead-engineer calls all day (we looked at Matt’s work in an earlier Watching post). Steve Yegge, in “The AI Vampire”: “Assume that exhaustion is the norm.” On a 7 September Lex Clips episode, DHH compared switching between Claude, Codex and OpenCode panes to driving a race car in the rain on a track with no straightaways.
In March, researchers from BCG and UC Riverside published “When Using AI Leads to ‘Brain Fry’” in Harvard Business Review (open coverage in The Register). They surveyed 1,488 full-time US workers. “Fourteen percent of participants in our study using AI for work endorsed the experience of AI brain fry,” and those workers self-reported 33% more decision fatigue. Self-reported productivity rose with a second and third AI tool, and “After three tools, though, productivity scores dipped.” Articles such as Built In’s turned that into a rule that developers break after three coding agents. Read the original: BCG asked all kinds of workers about general AI tools, once, and they reported it themselves. It did not measure coding agents.
What people are doing
Most writing on this is about setup, like tmux panes with Markdown specs. To protect their attention, developers make their own rules. In “Your parallel Agent limit”, Addy Osmani writes: “Your cognitive bandwidth doesn’t parallelize.” He caps himself at three to four threads and timeboxes sessions. Yegge keeps his workday to three or four hours. In “Toxic flow”, Daniel Vaughan runs agents in waves and re-reads the diffs he approved; his own rule of thumb is that if fewer than “80 per cent” pass a second read, “your concurrency is too high”.
What drops out is the reading. Willison saw it in October 2025: “the natural bottleneck on all of this is how fast I can review the results.” Vaughan, six months later: “I had approved at least two diffs without reading them.” In a January video, Theo ran six parallel sessions to turn a web project into a mobile monorepo, glanced at the 2,300-line pull request, and merged it without noticing the mobile app folder was missing from git.
It reminds me of the 1952 “Job Switching” episode of I Love Lucy. When the chocolate belt speeds up, Lucy and Ethel do not stop the belt. They hide the chocolates they cannot wrap in their hats and blouses. When four agents finish at once, you rarely close three terminals. You wave the diff through.
On 18 October 2026, I counted my own record. Of 771 of my messages with a time, 383 (about half) went out while four or more of my chats were open, counting a chat as open if I wrote in it within 30 minutes either side. Only 61 went out with one chat open.
My session notes show what that looks like from the inside. When four or five sessions poured long walls of text back at me, I got bogged down in the volume. I gave my attention to the one or two sessions on problems I liked. To get the other three or four out for testing, I typed things like “Please do multiple checks, please use another agent to verify.” I was asking a second agent to stand in for my own judgment. That same day, a release of our app was held because one of those background sessions was writing to the same folder as another at the same time. The type check caught it, not me.
What to do instead
People compare running five agents to a chess simultaneous exhibition, like Garry Kasparov beating 30 players at Tel Aviv University in May 2010. A simul works because every board waits until the master walks over, and the opponents are weaker. Agents do not wait, and their mistakes are not the easy kind.
I have managed teams of 40 to 50 people, with 40 to 50 different questions a day. That is tiring, yet five coding agents can drain me more. With a person, you give that person your full attention, and they explain the problem to fit you. Every agent sends the same wall of text, whoever is reading and whatever else is running.
Forty years of research on people who supervise many machines says what happens under that load:
1. Each agent you add makes every check slower. In a 2004 CHI paper, Dan Olsen and Stephen Wood showed that how many robots one person can run depends on how long each works unattended and how long you spend on it. Your time on each robot “should increase with FO” (fan-out, the number of robots). “This is because the more robots there are to control, the greater the monitoring and robot selection time.” Past the limit, more robots “may in some situations cause a decrease if superfluous robots still demand user attention.” Add an agent only if each runs longer unattended than it takes you to check it. A September 2026 study with 16 developers on short tasks gave them a supervision dashboard. They got 63% more tickets done and ran one more agent at peak, but they did not feel more in control.
2. The limit is busy time, and it moves. In a 2007 Human Factors study, Mary Cummings and Stephanie Guerlain watched 42 US Navy personnel supervise 8, 12 or 16 missiles; at 16, performance dropped. They found “a 70% utilization (percentage busy time) score is a valid threshold for predicting significant performance decay”, like “controllers managing 17 aircraft as compared with those managing only 10 to 11 aircraft.” Air traffic control does not fix that limit. The FAA’s Monitor Alert Parameter is “a dynamic value”, changed for weather or outages. The warning sign is no slack between checks, and your number should drop on unfamiliar code or a risky migration.
3. The agent that has been right all morning is the one you will stop reading. Lisanne Bainbridge wrote in 1983 that “the operator will not monitor the automatics effectively if they have been operating acceptably for a long period.” Raja Parasuraman and Dietrich Manzey showed in 2010 that “Automation complacency occurs under conditions of multiple-task load” and “is found in both naive and expert participants and cannot be overcome with simple practice.”
What I changed
When I saw that about half my messages went out with four or more chats open, I expected to cut down. I did not. Having four or five things on my plate keeps me energized, and having fewer makes me anxious. The problem was not how many were open. It was that only one or two got my judgment, and the rest went out without it.
So I changed how I finish. I keep several sessions open, but I give my full attention to one piece of work until I have checked it myself and it is out. Then I move to the next. Nothing goes out until I have checked every session I started, and I no longer ask another agent to do my judging. For the past two weeks, my head has felt clearer and the creative work has been better.
A check you can run tonight
You cannot see your limit from inside a busy morning. Count it from your own record in ten minutes:
1. Count sessions by hour. Pick one day last week when you ran several agents. From shell history, git log or chat timestamps, write how many were running each hour.
2. Mark every approval. List every diff or plan you approved that day. Mark each one “read” or “skimmed or not read”. Nobody sees it.
3. Put the two side by side. Does “not read” rise with the count, and at what number? Or did you read your favorite session closely and wave the others through?
4. Write next week’s limit as a stop condition. Write it in advance (“three, or two in code I don’t know; stop when I approve something I didn’t read”), the way a controller’s limit moves with the weather.
# Commits per hour over the last week, to line up against your sessions
git log --since="7 days ago" --date=format:"%Y-%m-%d %H:00" --pretty=format:"%ad" | sort | uniq -cHow KORTURE.ai approaches it
KORTURE.ai does not solve this, and it does not make the AI better. It measures your own pattern over weeks and shows it to you: how many chats were open when you typed, next to which checks you made and which you skipped under load, so your own judgment decides what to change. The AI you already use (Claude Code, Codex, desktop apps) sets it up inside ordinary work, and it is in research preview at /get.
What went into this post
- 13 Hacker News threads, 8 videos and 8 blog posts read for what developers ask
- One BCG and HBR study (1,488 workers) read in the original; secondary reports found to misstate it
- Six human-factors studies checked; two popular ones dropped: the hungry judge, and ego depletion, which failed a 23-lab replication (d = 0.04); and the 23-minute interruption figure, which comes from a 2006 Gallup interview, not Gloria Mark’s 2005 CHI paper
- 771 of SK’s own timed messages counted by how many chats were open
