Inside my Dark Factory hardware stack: 48 Agent Pods on 2019 Mini-PCs

When people hear that Leaf, my local Level 5 dark software factory, runs 48 concurrent pod slots shipping features, enforcing adversarial CI/CD gates, and dreaming over its own telemetry overnight, they usually picture a loud rack of enterprise servers in my garage or a four-figure monthly cloud bill.

Today I queried the live fleet state from apps:4600/api/state and SSH’d into every host on my tailnet running factory-hostd (all on commit 9356bac) to inventory the hardware and benchmark the nodes while they ran live pods.

Three-quarters of my factory’s pod capacity runs on seven-year-old 2019 Intel NUCs.

The nuance: agent factories are timer and I/O bound, not CPU bound

We talk about AI software engineering as if every layer of the stack needs bleeding-edge silicon. That narrative gets the workload backwards.

Unless you are serving local model weights on the same box (my local LLM server, Home Assistant box, and Mac Mini sit on the tailnet without factory-hostd), an unattended coding pod spends almost its entire life waiting. It waits on frontier model API responses over the network, it waits on Node and container process startup, it waits on small filesystem I/O, and it waits on test timers.

Across my entire fleet, CPU pressure on every node is about 1% of the time since boot.

When I benchmarked my newest 2024 AMD Zen 4 mini-PC (factory-node-4) against my 2019 Intel Comet Lake NUCs (factory-node-1 through 3) today, the Zen 4 chip beat the NUC by 2.08x on a single core and 2.59x across the whole host. When I ran Factory’s actual test suite inside a live pod image on both machines, that 2.59x hardware lead collapsed to 1.17x (104 seconds vs. 122 seconds).

Buying twice the clock speed buys you almost nothing when your pods spend 99% of their lives waiting on timers and sockets.

Six hosts, four CPU generations, 48 pod slots

Six palm-sized mini-PCs on my tailnet run factory-hostd. Four of them take scheduled pods; the other two run stateful services with SLOTS=0 and stay connected to hostd strictly for automated deployments and secret distribution.

Pulling the live state on November 7, 2026 (commit 9356bac) shows the exact footprint of the fleet:

Fleet snapshot (apps:4600/api/state @ commit 9356bac)
-----------------------------------------------------
Connected hosts : 6 (Ubuntu 26.04 LTS, Linux 7.0.0-31 / -34 / -38)
Pod slots       : 48 total (33 in use at snapshot)
CPU threads     : 72 total (52 schedulable)
Memory          : 168 GB installed (128 GB schedulable)
NVMe storage    : 2.3 TB installed (1.3 TB schedulable)
CPU generations : 4 (spanning 2019 to 2024)

The four schedulable pod nodes (`SLOTS=12`)

Every schedulable node exposes 12 pod slots to run engineer agents, planning rooms, test suites, container builds, and continuous delivery tasks:

factory-node-1, factory-node-2, and factory-node-3 (2019 Intel Comet Lake, 14 nm): Three identical Intel NUC10i7FNH mini-PCs. Each runs a 15W Core i7-10710U (6 cores / 12 threads, up to 4.7 GHz), 32 GB of DDR4-2667 (2x16 GB), and a 250 GB Samsung 970 EVO Plus NVMe. At the time of the snapshot, node-1 held 8 active pods (12 / 12 slots), node-2 held 3 pods (7 / 12 slots), and node-3 held 5 pods (8 / 12 slots). Together, these three 2019 boxes carry 36 of the 48 pod slots (75% of the fleet).
factory-node-4 (2024 AMD Zen 4 Hawk Point, 4 nm): A GMKtec NucBox K8 Plus I bought after blowing through 50,000 GitHub Actions minutes in October. It runs a 45W Ryzen 7 8845HS (8 cores / 16 threads, up to 5.1 GHz), 32 GB of DDR5-5600 (2x16 GB), and a 512 GB AirDisk NVMe (203 / 500 GB free). During the snapshot it was running 4 pods (6 / 12 slots), accounting for the remaining 25% of pod capacity.

The two service hosts (`SLOTS=0`)

Keeping stateful control-plane and production services off the pod scheduler prevents a runaway build from starving the factory supervisor or a live database:

apps (2023 AMD Zen 3 Barcelo-R, 7 nm): A GMKtec M5 Ultra-R running a 15W Ryzen 7 7730U (8 cores / 16 threads, 4.5 GHz), 32 GB of DDR4-3200, and a 512 GB GMK NVMe (281 / 500 GB free). This is the Factory host itself: it runs the Leaf supervisor, factory-git, bark-dev, binpacker-dev, Sadie and its Actions runner, Immich, Music Assistant, Kokoro, Caddy, and cloudflared.
binpacker (2019 AMD Zen+ Picasso, 12 nm): An AZW SER3 with a 15W Ryzen 3 3200U (2 cores / 4 threads, 2.6 GHz), a single 8 GB stick of DDR4-2400 (5.6 GiB visible to Linux), and a 480 GB Crucial E100 NVMe (424 / 468 GB free). It serves production binpacker-server and binpacker-postgres for my wife’s kids’ clothing resale store, reached through cloudflared at garner-ssh.binpacker.net.

Generation	Year / Node	Hosts	Threads	RAM	Memory Type	Slots	Share of Slots
Intel 10th Gen (Comet Lake)	2019 · 14 nm · 15W	`node-1`, `node-2`, `node-3`	36	96 GB	DDR4-2667	36	75%
AMD Zen 4 (Hawk Point)	2024 · 4 nm · 45W	`node-4`	16	32 GB	DDR5-5600	12	25%
AMD Zen 3 (Barcelo-R)	2023 · 7 nm · 15W	`apps`	16	32 GB	DDR4-3200	0	0%
AMD Zen+ (Picasso)	2019 · 12 nm · 15W	`binpacker`	4	8 GB	DDR4-2400	0	0%

Where the real limits hide: iGPU carve-outs and the 20 GiB disk floor

When you run 48 container slots across consumer mini-PCs, the operational walls you hit have nothing to do with CPU Geekbench scores. They come down to RAM per slot and NVMe free-space floors.

First, an iGPU BIOS reservation makes my newest DDR5 machine the tightest node on per-slot memory. Because every schedulable host is configured with SLOTS=12, the 16-thread Zen 4 box (node-4) carries a relaxed 0.75 slots per CPU thread, compared to 1.0 slot per thread on the 12-thread Intel NUCs. However, factory-hostd divides usable host RAM by slot count to enforce per-slot memory reservations. Because node-4’s integrated Radeon graphics carves out 3 GiB of DDR5 at boot (leaving 27 GiB visible to the kernel), each slot on the brand-new Zen 4 box gets 2.3 GiB of RAM, whereas each slot on a 2019 Intel NUC gets 2.5 GiB.

Second, 250 GB NVMe drives fill up with container layers and git worktrees long before 10th-gen CPUs run out of breath. All three Intel NUCs still run the 250 GB Samsung 970 EVO Plus drives they shipped with (242 GB usable filesystem capacity). When I pulled the fleet state today:

factory-node-2 had 76 GB free (76 / 242 GB).
factory-node-1 had 50 GB free (50 / 242 GB).
factory-node-3 was down to 27 GB free (27 / 242 GB).

That 27 GB figure on node-3 is the closest thing to a red light on my dashboard. factory-hostd enforces a hard 20 GiB free-disk floor: if free space drops below 20 GiB, the daemon refuses to accept new pods until completed rooms prune their workspaces. node-3 was sitting just 7 GB above the scheduling cutoff while its CPU idled.

Benchmarking 2019 vs. 2024 under live pod load

To see what five years of silicon progress actually buys inside the factory, I benchmarked all six hosts today while they ran their normal live pod load. I took the best run on each host and normalized every score against the 2019 Comet Lake NUC (1.00x).

Look at the three tiers of that test:

Single-core synthetic CPU (Python 3.14 loop of integer math, dictionary building, and sorting; NUC baseline = 0.60s): A single 4 nm Zen 4 core on node-4 is 2.08x faster than a 14 nm Comet Lake core. The Zen 3 core on apps comes in at 1.47x, and the two-core Zen+ chip in binpacker trails slightly at 0.89x.
Whole-host synthetic throughput (running one Python loop process per hardware thread; NUC baseline = 7.8 jobs/s across 12 threads): Combining faster cores with 16 threads and DDR5-5600 pushes node-4 to 2.59x the throughput of a NUC. Meanwhile, binpacker (4 threads) drops to 0.38x.
Real factory workload (the full npm test suite at commit 9356bac inside the factory-node-24 container image; NUC baseline = 122s): On the workload the fleet actually exists to run, node-4 finishes in 104 seconds against the NUC’s 122 seconds, a speedup of just 1.17x.

Two methodology wrinkles are worth calling out before anyone quotes those numbers out of context:

apps ran with a load average of 13 during the benchmark. Because I measured the fleet live rather than shutting down production, apps was simultaneously running the Factory supervisor, factory-git, Immich, Sadie, and six other services. That background load explains why a 16-thread Zen 3 box scored 1.24x on the whole-host test and 0.94x (130 seconds) on the test suite.
I threw out the OpenSSL sha256 numbers. When I first checked openssl speed sha256, the AMD hosts looked 3x to 13x faster than the Intel NUCs. That gap has nothing to do with general compute speed: AMD Zen processors include hardware SHA-NI instructions, while 10th-gen Intel Comet Lake chips omitted them. Including that number on a chart would just measure a missing crypto instruction set.

Even with a clean run on node-4, a 2.59x whole-host CPU advantage shrinks to 1.17x on a real test suite because test wall time is governed by timers, filesystem I/O, and process startup rather than raw arithmetic.

In a synthetic loop, the CPU is pinned at 100%.
In an agentic factory, the CPU is waiting on the world 99% of the time.

Pricing the same six boxes on AWS ($20k to $33k a year)

When I moved git, CI, CD, and agent pods onto this shelf in October, my goal was escaping per-minute cloud CI billing and unifying telemetry. Out of curiosity, I priced out what it would cost to rent this exact six-host footprint (72 threads, 168 GB RAM, 2,254 GB of NVMe storage, and 6 public IPv4 addresses) on AWS EC2 in us-east-1 at Linux on-demand list prices (730 hours/month).

Because EC2 does not offer a 6-core / 12-thread instance shape to match the Intel NUCs, a fair comparison requires a range:

The low match ($1,688.86/month) matches the NUCs’ 32 GiB of RAM using m6i.2xlarge instances (8 vCPU, or 4 physical cores, vs. the NUC’s 6 physical cores).
The high match ($2,782.11/month) covers the thread count using m6i.4xlarge instances (16 vCPU and 64 GiB of RAM, double the NUC’s memory).
For factory-node-4, an m7a.2xlarge ($338.49/month) is an exact match in both columns because AWS disables SMT on 4th-gen AMD m7a instances, so every m7a vCPU is a full physical Zen 4 core.

Fleet Host(s)	AWS Low Match (`us-east-1` On-Demand)	Low $/mo	AWS High Match (`us-east-1` On-Demand)	High $/mo
`factory-node-1, 2, 3` (x3)	3x `m6i.2xlarge` (Ice Lake, 8 vCPU, 32 GiB @ `$0.384/h`)	`$840.96`	3x `m6i.4xlarge` (16 vCPU, 64 GiB @ `$0.768/h`)	`$1,681.92`
`factory-node-4`	`m7a.2xlarge` (Zen 4, 8 cores, 32 GiB @ `$0.46368/h`)	`$338.49`	Same (`m7a` vCPU = 1 full core)	`$338.49`
`apps`	`m6a.2xlarge` (Zen 3, 8 vCPU, 32 GiB @ `$0.3456/h`)	`$252.29`	`m6a.4xlarge` (16 vCPU, 64 GiB @ `$0.6912/h`)	`$504.58`
`binpacker`	`t3a.large` (2 vCPU, 8 GiB @ `$0.0752/h`)	`$54.90`	Same	`$54.90`
NVMe Disks	`2,254 GB` gp3 @ `$0.08/GB-month`	`$180.32`	Same	`$180.32`
Public IPv4	6 addresses @ `$0.005/h`	`$21.90`	Same	`$21.90`
All 6 Hosts Total	$20,266 / year	$1,688.86	$33,385 / year	$2,782.11
4 Pod Nodes Only	`node-1..4` + 1.25 TB gp3 + 4 IPv4	$1,295.00	`node-1..4` + 1.25 TB gp3 + 4 IPv4	$2,136.00

Like any cloud cost table, this one needs honest caveats on both sides of the ledger.

On one side, that $20k to $33k annual total leaves out the line items that usually blow up a real AWS bill: outbound data transfer, EBS snapshots and backups, a NAT gateway, and the Tailscale or Cloudflare routing layer.

On the other side, no pragmatic infrastructure team pays retail on-demand rates for 24/7 base capacity. A 1-year Compute Savings Plan or EC2 Spot instances cut those numbers substantially. Right now, Spot pricing for those four pod nodes sits around 45% of on-demand (roughly $580 to $960 a month for the pod tier alone), with the obvious catch that AWS can reclaim a Spot node in the middle of a multi-agent build room.

Still, even at a 55% Spot discount, a single month of cloud rent for one node pays for a used 2019 Intel NUC outright. And so far, Duke Energy hasn’t called to renegotiate my closet’s enterprise commitment tier.

So what?

If you are building or scaling an unattended agent harness of your own, the hardware data from Leaf points to three practical rules:

Buy RAM density and NVMe headroom, not single-core clock speed. When your pods call hosted frontier models over HTTPS, your local compute fleet is an I/O and process-spawn multiplexer running at ~1% CPU pressure. Spend your hardware budget on 32 GB to 64 GB RAM kits and 1 TB+ NVMe drives so container layers and git worktrees never flirt with a 20 GiB disk floor.
Isolate your control plane from your pod slots. Running apps and binpacker with SLOTS=0 means factory-hostd can still deploy containers and rotate secrets on them, while noisy npm test suites stay fenced onto the four SLOTS=12 worker boxes.
Benchmark your actual container suite before retiring old hardware. If I had looked at a 2.59x synthetic host benchmark or a 13x OpenSSL hash test, I would have written off my 2019 Comet Lake NUCs as obsolete e-waste. Against a real pod test suite, those seven-year-old boxes deliver 85% of the wall-clock speed of a 2024 Zen 4 machine (122s vs. 104s) and quietly carry three-quarters of my factory.