A Shared Kitchen for GPU Coding Agents: Metal Sandbox Turns Idle Mac Mini Clusters into Parallel Kernel Factories

Infrastructure paper, not a model paper. Sandboxed execution + cross-node scheduling for Metal kernel-writing agents yields ~2× throughput on 4 Mac Minis. Open-source, narrow scope, honest numbers.

Imagine four cooks sharing one kitchen. Each cook alternates between reading a recipe (thinking), chopping vegetables (CPU work), and using the stove (GPU execution). The stove sits cold most of the time because each cook waits for their own next step. Now imagine a dispatcher who watches all four cooks and says: "Your stove is free — you, go now." That is Metal Sandbox. The committed claim: if you have LLM-powered agents generating Apple Metal GPU kernels, you are leaving most of your GPU capacity on the table because agent rollouts are bursty — long think phases interspersed with short GPU bursts. Metal Sandbox provides per-agent file isolation, native macOS command execution, and a scheduler that packs parallel commands across interconnected Mac Minis. The result is a 1.68×–2.05× improvement in command throughput under concentrated demand on four Mac Mini M4 nodes. The architecture is deliberately simple. Each agent gets a private workspace with restricted file access — no agent can corrupt another's state. Commands are tagged serial or parallel. Parallel commands run concurrently on a node; serial commands compete for a single execution slot per machine. When a node's slot is busy, eligible waiting commands migrate to available Macs and return results to the originating agent. The whole thing integrates with Harbor, a task-execution framework that handles verification and rollout collection. This is systems engineering, not ML research — the contribution is plumbing, not modeling. The evaluation is a two-part affair. First, controlled experiments on four Mac Mini M4 nodes show the raw throughput gains under synthetic load. Second, sixteen static agent traces — real recorded sessions — are replayed through the scheduler to estimate sustained-throughput gains. The replay analysis estimates a 2.14× sustained-throughput gain for four sessions per node versus one, with dynamic scheduling reducing mean tool waiting by 18.8% and batch elapsed time by 22.3%. The authors are careful to note these assume unchanged mean phase durations and continuously replenished sessions — honest qualifiers that weaken the headline number but strengthen credibility. The integrity picture is mixed. On the positive side: code is open-source on GitHub, the system is concrete and reproducible, and the authors explicitly state their assumptions. On the negative side: there is no independent replication, the workload is synthetic or trace-replayed rather than a live multi-agent training run, and there is no comparison to alternative scheduling approaches (e.g., Kubernetes-based GPU sharing, NVIDIA MPS, or even a simple round-robin baseline). The "benchmark" is their own traces on their own hardware — the homework is graded by the same team that wrote it. The field context matters. The emerging space of "coding agents that write GPU kernels" — think of efforts to have LLMs generate CUDA or Metal shaders — needs infrastructure to train and evaluate those agents efficiently. This paper addresses a real bottleneck: agent rollouts waste GPU time. But the contribution is narrowly scoped to Apple Silicon, Metal shaders, and a specific agent workflow. Whether this generalizes to CUDA agents on NVIDIA clusters (where GPU sharing is a much more mature problem) is unstated. What this actually is: a well-executed infrastructure contribution for a very specific niche — on-device Apple Silicon kernel generation by LLM agents. It solves a real scheduling problem with straightforward systems techniques. It does not advance ML, scheduling theory, or GPU virtualization in novel ways. It is useful plumbing for anyone working in exactly this corner, and likely irrelevant to everyone else.