Too Many Subagents Freeze Your Computer. Reduce Concurrency or Upgrade?

Identify what each subtask actually runs on your machine

List the work you intend to run in parallel. Note whether it only reads material or also starts a browser, runs a build, processes images or calls a local model. Check whether the main task already has similar tools running. The number of subagents is easy to see; the programs they start and the work they repeat also belong in the record.

Schedule independent work separately from steps that depend on an earlier result. A build that needs an upcoming code change can wait until its input is stable, for example. If several tasks repeatedly read the same material, prepare a shared input first and consider whether every role still needs to repeat that work.

Use repeatable tasks to observe the effect of concurrency

Complete one familiar task on its own first. Record the elapsed time, the local programs it starts and changes in system resource use, then gradually add independent tasks. Keep the inputs as similar as practical. Watch total completion time, whether the interface remains responsive and whether processes remain after the task ends. These comparisons make changes easier to explain.

If slowdowns cluster around one stage, try queuing that type of work while allowing lighter steps to continue. After a failure, preserve completed results and the point of failure before rerunning a smaller task. Adjusting concurrency from your own records is easier to maintain than copying someone else's subagent count.

Set a clear handover order for edits to shared files

When several agents need to change the same files, define each agent's scope and agree who will integrate the results and when builds and checks should begin. Save a result you can verify at the end of each stage and identify any tasks still running at handover. This also helps distinguish resource contention from rework caused by overlapping edits.

This article explains how to observe your own development workload. We have not tested Claude Code or the computers mentioned, and we recommend no universal concurrency limit. If freezes continue after you reduce the workload, investigate further using the times, processes and resource readings you recorded. Base any hardware upgrade on a bottleneck you have actually identified.

Turn the discussion into a checkable task

Increase concurrency on the same test repository from one task to two and four, holding tasks constant and recording memory pressure, swap and longest wait. Retain process names on failure and distinguish request limits from local resource shortages. Not every wait is a slow CPU. No computer benchmark was run here.