If you measure Apple’s new container system against Docker, it looks broken. Each instance burns 270 to 400 MB of RAM before it does anything useful. Startup is four to ten times slower than a Linux container. Try sharing a volume across multiple containers and you will hit a hard wall: one attachment, one box. For anyone hunting for a lighter way to run microservices, these numbers feel like deal-breakers.
But Apple is not building a replacement for your dev stack. It is building a jail for code you cannot trust.
That single shift in perspective changes every complaint into an intentional trade.
The Wrong Benchmark
Our industry spent the last decade squeezing containers for density. We wanted dozens of apps living on a single kernel, sharing memory pages, mounting the same volumes, and booting in milliseconds. Docker solved that problem brilliantly. The whole point was to make the abstraction between software and hardware as thin as possible.
Apple’s design runs the other way. It sacrifices density for separation. It trades shared resources for rigid walls. Looked at as infrastructure for a Kubernetes cluster, the math is absurd. You would never pack a fleet of nodes where every container carries a quarter-gigabyte of overhead and its own kernel. The economics simply do not work.
Unless the workload is an AI agent that you just invited onto your laptop.
The Tenant Changed
In 2026, the most dangerous code running on your machine is not a poisoned npm package or a sketchy browser extension. It is the autonomous coding agent. These tools read your codebase, rewrite functions, execute shell commands, and call external APIs. They make thousands of decisions per minute inside the same directory tree where your SSH keys, environment files, and browser cookies live.
Traditional permission models collapse under that speed. You cannot have a human approve every file read, every subprocess spawn, and every network request. That approval chain turns a five-minute refactoring job into an hour of babysitting. Yet giving an agent blanket access to your home directory is not much safer than handing your laptop to a stranger.
The only sane starting point is to treat the agent as hostile by default, then prove safety through structure rather than hope.
Apple’s container system is engineered for exactly that mindset.
When Isolation Becomes the Point
Each Apple container runs inside its own lightweight VM with its own kernel. In the Docker world, that is heresy. You lose memory deduplication. You lose the speed of a shared kernel. You lose the ability to pack hundreds of workloads onto a single host.
For one untrusted agent, though, a private kernel is a fortress. If the agent escapes its user space, it still slams into a boundary that is not your host kernel. That is not waste. That is the feature you are paying for with those extra megabytes.
Apple extends this boundary through mcpbridge. Many coding agents speak to tools using the Model Context Protocol, or MCP. Apple intercepts those commands and translates them into XPC, the same cross-process framework that enforces fine-grained permissions across macOS and iOS. The agent cannot simply poke at your file system or network. Every tool call has to pass through Apple’s strict permission model first.
Then there is the split in compute. The heavy AI models themselves stay on the host Mac, running on the Neural Engine. The container does not waste RAM on model weights or inference engines. It only houses the agent’s tools and scratch space. The expensive work happens where the hardware is strongest; the risky work happens inside the cage.
This architecture echoes the philosophy behind Apple’s Private Cloud Compute initiative. Do not ask the user to trust you blindly. Prove the boundary with the structure of the system itself.