# Why We Moved Our Coding Agents to the Cloud

https://instabox.sh/blog/why-we-moved-our-coding-agents-to-the-cloud.md

2026-10-18 · Tony Chang · Engineering

Our weekly GitHub contributions went from ~300 to ~1,200 in five months. ADEs gave us the first jump. Moving agents to cloud microVMs gave us the second.

At InsForge, our weekly GitHub contributions have quadrupled since May, from ~300 to ~1,200.

ADEs gave us the first jump. Instead of juggling a few agents in terminals, we started running many in parallel with tools like [Cmux](https://cmux.com/), [Orca](https://www.onorca.dev/), and [Herdr](https://herdr.dev/).

But as the agents got better at running long tasks on their own, our laptops became the bottleneck. So in July we kept our ADEs and moved the agents themselves to the cloud. That was the second jump.

![GitHub contribution graph: 8,402 contributions in the last year, darkest from August onward](https://instabox.sh/blog/images/2026-10-18-why-we-moved-our-coding-agents-to-the-cloud/contributions-graph-a.webp)
![GitHub contribution graph: 9,549 contributions in the last year, darkest from July onward](https://instabox.sh/blog/images/2026-10-18-why-we-moved-our-coding-agents-to-the-cloud/contributions-graph-b.webp)
![GitHub contribution graph: 11,955 contributions in the last year, darkest from May onward](https://instabox.sh/blog/images/2026-10-18-why-we-moved-our-coding-agents-to-the-cloud/contributions-graph-c.webp)

![InsForge team GitHub contributions per week in 2026: about 300 a week before ADEs, about 580 a week after starting ADEs in May, and about 1,220 a week after moving agents to the cloud in July](https://instabox.sh/blog/images/2026-10-18-why-we-moved-our-coding-agents-to-the-cloud/weekly-contributions-2026.webp)

## First jump: from one agent to many

Early this year, most of our agent work started with a spec. We'd spend half an hour writing one, often with skills like [Superpowers](https://github.com/obra/superpowers), then hand it to [Claude Code](https://www.anthropic.com/claude-code) and watch it go. Writing the spec was the real work. The agent was more like a very fast typist.

That worked, but it meant each of us could only drive three agents at a time. The obvious fix was to run more of them. When we tried, we hit a problem we didn't expect: the terminal.

A terminal is a fine place to run one agent. It's a bad place to run five. You can't see what each one is doing without switching to it. You can't tell which one is done and which one is stuck. And if you want Claude Code and [Codex](https://openai.com/codex/) working side by side, you end up juggling windows.

So the bottleneck wasn't the agents. It was us, trying to keep track of them.

That's what ADEs fix. They put every session in one place, show you what each agent is doing, and make it easy to move between them. It sounds like a small thing, but it isn't. Once you can see all your agents at once, you run more of them, because you're no longer afraid of losing track. Our weekly contributions went from about 300 to about 580.

## Then the agents got better

In June and July, Fable 5 and GPT-5.6 came out. The agents could now run for an hour or more on their own. They'd break a task into pieces and spin up sub-agents to handle them. We stopped writing long specs, because we didn't need them anymore. A few sentences was usually enough.

It felt like going from managing a few assistants to running a small army. But all these agents ran on our laptops, and it turned out our laptops weren't built for this. There were three problems.

The first problem was resources. Every agent wants its own share of memory, CPU, and disk, and on a laptop they all draw from the same pool. With three agents running, my MacBook Pro was already using 16GB of its 24GB of memory. At five, it froze and crashed.

The second problem was that the agents shared one development environment. Worktrees keep each agent's code separate, but everything else is still shared: ports, local services, the machine's global setup. So we kept hitting small collisions, like two agents trying to run a dev server on the same port. None of these were hard to fix. But fixing them over and over was a tax on every parallel run.

The third problem was that our laptops were a single point of failure. Small things could interrupt our work: the battery died, the Wi-Fi dropped, the power went out in the apartment, or the screen locked itself. None of these happened often, but when one did, it stopped every agent at once.

## Second jump: from laptops to the cloud

When we looked at the three problems together, we noticed they had the same cause. They all came from running every agent on one shared machine. Which meant the fix wasn't a bigger laptop. It was to stop sharing. If each agent had its own isolated runtime, it would get its own memory and CPU, its own environment, and nothing would break when a laptop went to sleep.

That's what cloud coding agents are, and the ADEs we were already using support them. So in July we started moving our agents to the cloud. But it's harder than it sounds. We had two more things to figure out.

The first was what kind of runtime each agent should get. We gave each one a persistent Linux machine: its own computer, with its own files it can read and write. The reason was simple. An agent does its best work in the same kind of environment a developer has. Our agents run Docker. They test their work in a headless Chromium. If you want an agent to do everything you do on your laptop, you have to give it something like a laptop.

The second was setup. Every agent session needs its own machine, and every new machine starts out empty. So before an agent can do anything, someone has to set it up. You install all the packages and dependencies the project needs. You log in to GitHub so the agent can pull and push. You sign in to Claude Code and Codex so it can use your subscriptions. Every developer knows what that's like. It's the first afternoon with a new laptop, and we'd be doing it every time we started an agent.

Is there a way to do all this just once? It turns out there is. A full VM emulates an entire computer, so it's heavy to snapshot and slow to restore. A microVM strips out most of that, which makes snapshots cheap and fast. We used [Firecracker](https://firecracker-microvm.github.io/), which [supports snapshots natively](https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md), so the control plane we built on top of it was simple. We booted one microVM, set it up exactly the way we wanted, and took a snapshot.

Now when we start a cloud agent session, the control plane provisions a new instance from that snapshot. It comes with all our packages, shortcuts, and logins already in place, and it's ready in under two seconds. Setup went from something we did every time to something we did once.

## Now: ADEs on our laptops, agents in the cloud

These days, when we have a new task, we start an agent from our ADE, hand it the task, and move on to the next one. Each agent works on its own computer in the cloud, set up just like ours. It can run Docker, start a dev server, and test its work in a browser without getting in the way of the other agents. And it keeps running when we close our laptops.

On average, each of us now runs about ten agents at a time. At the start of the year, it was three. Since July, our weekly contributions have gone from about 580 to about 1,200.

If your agents only run for a few minutes at a time, a laptop is probably fine. But the models keep getting better, and the runs keep getting longer. Once your agents can work for an hour on their own, you'll want more of them going at once, and that's when the laptop starts to get in the way. When that happens, it's time to move your agents to the cloud.