Codespaces VM Upgrade Doubles Memory and Cuts CPU Costs
GitHub has rolled out a new generation of virtual machines for Codespaces, and the headline change is simple: every VM now ships with twice the RAM and anywhere from 10–30% better CPU performance, thanks to a move to AMD-based hosts. In practice, that means you can often run the same workloads on a machine with half the CPU cores of your previous setup, at roughly half the cost.
The upgrade directly addresses a common pain point with the older VM generation. Memory-intensive workloads—particularly those that run multiple services—frequently had to overprovision CPU cores just to get enough RAM to function. Developers were stuck choosing between expensive larger machines or compromising on performance. The new spec removes that tradeoff for most scenarios.
GitHub’s Own Rollout: Real-World Validation
GitHub built the platform itself using Codespaces, including a large Ruby monolith that demands significant CPU and RAM. The internal developer experience (DX) team used the largest available VMs prior to this change. When the new machine types arrived, they started by switching a few teams with RAM-heavy workflows to machines that kept the same RAM but cut the CPU count in half.
The results were clean: developers remained just as productive, and the cost to GitHub dropped by half. One build process did turn out to be CPU architecture-dependent, but the fix was straightforward—specifying the CPU architecture so QEMU could emulate appropriately. No other negative impacts surfaced, and the rollout quickly expanded to more teams, yielding roughly 50% savings across the board.
Since the AMD machines went live for GitHub’s own use, there have been no reported problems and only positive feedback from users.
Testing Smaller Machines in Your Own Organization
The same cost-saving pattern is available to any organization using Codespaces, and it requires little effort to explore. All Codespaces VMs have already been upgraded, so testing is as simple as having a few developers try working in a smaller machine type than their usual choice. In most cases, no additional configuration changes are needed.
Once you identify the smallest machine that still delivers a good developer experience, you can enforce that choice organization-wide by setting a policy to restrict machine types. That approach locks in cost controls without sacrificing the environments developers need to do their best work. For questions or feedback, the Codespaces Community Discussions are open for input.
