By Microsoft put Azure Cobalt 200 VMs into early access preview at Build 2026, and the headline “50% faster” undersells what’s actually interesting here. The chip isn’t just a generational refresh — it’s built around the workload pattern that defines AI development in 2026: spin up hundreds of isolated sandboxes, run tools inside them fast, tear them down, repeat. The benchmarks Microsoft published are telling: 42% higher agentic sandbox memory bandwidth and 16% faster sandbox creation. Those numbers matter more than raw CPU throughput if you’re running Antigravity agents, GitHub Copilot automation pipelines, or any other system that lives and dies on how quickly you can provision and kill isolated compute.
What “Agentic Sandbox Benchmarks” Actually Means
Microsoft coined the term “agentic sandbox performance,” which sounds like marketing until you look at what they’re measuring. An agent sandbox is an isolated execution environment — a micro-VM or container — where an AI agent writes and runs code, calls tools, and produces output before the whole thing is discarded. The speed of provisioning that environment, the memory bandwidth available to it, and the throughput of the tools running inside it are the actual performance bottlenecks for modern agent orchestration at scale.
Cobalt 200 is physically designed for this. Every core gets a dedicated 3MB of L2 cache — roughly double what competing chips allocate — which means neighboring sandboxes don’t thrash each other’s cache lines the way they would on a chip built for batch workloads. Add per-core Dynamic Voltage and Frequency Scaling (DVFS) — each of the 132 cores can run at a different power state independently — and you get a chip that lets one hot sandbox run full throttle while 50 idle ones sit at minimal power draw on the same VM. That’s the 16% faster creation and 42% higher bandwidth in hardware terms.
The Architecture Behind the Numbers
Cobalt 200 packs 132 Arm Neoverse V3 cores into a dual-chiplet design on TSMC’s 3nm process. The chiplet approach is new for Azure silicon and enables the 192MB L3 system cache that underpins the memory bandwidth advantage. Core-to-core communication runs over Microsoft’s Azure Genesis Fabric at sub-20 nanosecond latency. Memory encryption is on by default — meaningful if you’re running untrusted agent code.
It shares the Neoverse V3 core with AWS Graviton 5, but the two chips make different design bets. Graviton 5 leans into vectorized throughput for HPC and media workloads. Cobalt 200 optimizes for memory bandwidth and sandbox isolation density — the right call for Microsoft, whose biggest Azure customers are running web services and increasingly agentic AI infrastructure. Third-party benchmarks back this up: Cobalt 200 scores 840 on SPECrate2017intbase (128-core instance) vs Graviton 5’s 780 (96-core), and pushes 1.2 million NGINX requests per second at sub-2ms P99.9 latency.
Performance at a Glance
| Metric | Cobalt 200 vs Cobalt 100 |
|---|---|
| CPU performance (generational) | +50% |
| Agentic sandbox creation speed | +16% |
| Agentic sandbox memory bandwidth | +42% |
| Agentic tool performance | +50% |
| Remote storage IOPS (NVMe) | +20% |
| Network bandwidth | +15% |
Migration: Who Has to Do Work and Who Doesn’t
If you’re already on Cobalt 100 — the Dpsv6 or Epsv6 VM series — migration is binary compatible. Same ARM64 ISA, no recompilation required. Ubuntu and Ubuntu Pro are available at launch, and Canonical confirms that 95%+ of the Ubuntu archive is already built for ARM64. Microsoft’s own workloads — Office, Teams, Azure SQL — are already running on the platform internally.
If you’re coming from x86, you have real work to do, though the situation is better than it was two years ago. ARM-native runtimes ship standard for Python, Rust, .NET, Go, Java, and Node.js. If you have compiled components that haven’t been ported, Microsoft’s Project Strong ARMed offers AI-assisted porting from x64 to ARM64 — it’s not magic, but it handles the tedious parts. The main gotcha: Cobalt 200 VMs don’t support GPU pass-through, so anything requiring an A100 or H100 stays on x86.
Getting Early Access
Early access is gated behind Azure Support — no self-serve preview toggle. The request process routes you to Azure experts who help configure the right VM family for your workload. VM families follow the Cobalt 100 naming pattern: general-purpose (Dpsv-series equivalent) and memory-optimized (Epsv-series equivalent), scaling to 128 vCPUs. GA timeline is “later in 2026.”
If you’re running significant agentic workloads on Azure today — agent orchestration pipelines, CI/CD at scale, LLM serving, or anything involving high sandbox creation rate — Cobalt 200’s early access is worth requesting. The agentic benchmark numbers aren’t theoretical; Microsoft’s own agent infrastructure runs on this. For everyone else, GA will arrive without drama given the seamless Cobalt 100 migration path. You can check the Azure Cobalt VM documentation to understand the current family lineup and start planning.
