Running a Claude Code agent team on one Mac Mini

I run a team of Claude Code agents: directors, senior developers, marketing, support and HR on Opus, and junior developers on Sonnet. I wrote about why that team needed an HR department, and about how my Claude Code work is set up. This post is the part I left out of both: where the checks run, and the one machine they all run on.

The checks, and why they run on my Mac

Running things in GitHub Actions can get expensive. So the checks run locally, on my computer, and they set flags that GitHub CI reads to know they ran.

There are three of them:

• A security review. It runs locally and writes a file in git that shows it ran.
• The test suite. It runs on my computer too, and it also sets a flag that CI checks.
• A cold review. For each pull request, a fresh review looks at whether the changes are good and reports back if they aren't. There's a whole system involved in that one.

With those three, we catch a lot of issues without running much in GitHub CI.

One Mac Mini is the bottleneck

Everything runs on one Mac Mini: an M4 Pro with 48 GB of memory and about a terabyte of storage. It's a pretty good machine, but it's one machine, and with this many agents it runs short on two things: CPU and disk space.

CPU, and the queue I didn't know about

I have the agents write a lot of tests, because I want everything to work perfectly. The test suite runs in parallel and takes basically 100% of the CPU. If several agents ran it at the same time, there would be too many processes and everything would slow down.

So there's a queue. I didn't come up with it, and nobody asked me about it. I give tasks to the directors, the developers do the work and report to their director, and the directors give me status updates. Directors on the same company account can also talk to each other. Somewhere in there they noticed they had to take turns running the tests, so they built a system for it. Claude wrote a script that checks a lock file for that company and waits in line until it's its turn. Honestly, I don't know exactly how the waiting part works.

I found out about it when someone mentioned they were waiting in line to run the test suite, and that it was a bottleneck. My reaction was basically: what queue? What are you talking about? It was kind of funny to learn about a tool my own team built to solve a problem I didn't know we had. But at least it wasn't crashing the computer.

At first there was one line, and a test run could use the whole machine. With two companies running at once, everyone waited in that same line. Now each company has its own line and its own lock file, and each can use roughly 45% of the CPU, with about 10% left for me. A run's priority is also lowered, so my browser stays usable.

Before the cap, two test runs at once drove the machine's load average to 172, and I couldn't use my own computer. The bottleneck is how many test runs happen at once, not how many agents I have.

How big the test suites are

I asked my three programming directors how long their test suites take. They answered within a few minutes, and each one marked which numbers were measured and which were estimates.

Knowledge ERP is the big one. It's an ERP system with a lot of parts, and it has about 13,100 tests. A full run on the Mac Mini takes about 13 minutes. Swiftrics has about 6,900 tests and runs in about 5. LiveAgentPro has about 4,800, and on a busy day its full runs took anywhere from half an hour to an hour and a half, depending on what else the machine was running. The code didn't change between those runs. What changed was how busy the machine was.

For a while, Knowledge ERP took 30 to 40 minutes in GitHub, and that got expensive fast. My GitHub plan includes some Actions usage. First I got an email saying I was at 90% of it, so I raised the spending limit to $100 a month. Not long after, the emails started again: 75%, then 90%. I raised it to $150 and messaged the director to say we needed to change how we run CI. The fix wasn't in place yet when I had to raise the limit again, to $200.

The fix is in now, and it's a lot less extreme. GitHub splits the suite into 8 pieces that run at the same time, so the wait is 9 to 14 minutes. Its director pointed out that those pieces still add up to about an hour of machine time.

Knowledge ERP is too big to run in full for every change, so it's split up. The app is divided into 50 modules. A change inside one module runs that module's tests, plus a small set that always runs no matter what changed. If a change touches something the map doesn't recognize, the whole suite runs. One change that day ran about 9,100 tests instead of 13,100. The bigger win is in the queue, because a shorter run holds the line for less time.

On a busy day, the slow part isn't the tests. It's the waiting. One change waited roughly two hours for its turn.

Disk space, and cleaning up working trees

The other thing that runs out is storage. About a terabyte sounds like plenty. But with this many Claudes working on projects, each piece of work got its own working tree, and they weren't cleaning them up when they finished.

The drive filled up. Outlook would close itself because there wasn't enough storage left, and other programs would give up and close too. The computer would nearly crash. Then all the Claudes would notice and start freaking out, trying to clean up and delete things.

Now they clean up after themselves when they finish a piece of work, and that helps a lot. I've got about 200 GB free again. If you run a lot of Claude Code sessions, make sure they aren't leaving extra working trees lying around.

More Mac Minis, or EC2?

I'm weighing two options: buy more Mac Minis for the different teams, or run teams on AWS EC2 instances.

EC2 would make it easier to spin up more teams and divide things up. Claude could write CloudFormation templates that define each team and create the stacks itself. HR would probably end up managing CloudFormation templates instead of startup scripts. But it has downsides:

• Agents could end up on different machines, and I think that could make it harder for them to message each other. (Anthropic's docs say sessions on other machines can be reached through Remote Control, but on one machine the messaging is direct.)
• A lot of the time they want to open Chrome to test something in the browser, and I don't think that would work very well on an EC2 instance.
• It would cost a bunch. I haven't priced it out, but each instance costs money, and right now a junior developer sitting idle costs me basically nothing and uses almost none of my usage.

My plan is probably to buy more Mac Minis first and run teams on those, so the CPU load is spread out.

For now it's one Mac Mini, two lines and a lot of tests. The team itself, and how it ended up with an HR department, is in my Claude Code agent team post.