---
title: Why ChatGPT Work uses microVMs and Cloudflare OS uses Durable Objects
canonical: "https://agenticup.dev/posts/chatgpt-work-microvm-vs-durable-objects/"
pubDate: "2026-08-06T00:00:00.000Z"
description: "ChatGPT Work runs agents on full Linux microVMs. Cloudflare OS runs them on V8 isolate Durable Objects. Same problem, opposite runtimes. The choice is about what kind of machine your agent needs to be."
tags: [agent-architecture, cloudflare, durable-objects, microvm, agent-runtime, production-ai]
---

**TL;DR:** ChatGPT Work and Cloudflare OS solve the same problem, an agent workspace with persistent state, and pick opposite runtimes. Work gives each agent a full Linux microVM with its own kernel, 8 CPUs, and 20GB of RAM, because its agents install packages and drive a browser. Cloudflare OS runs agents on V8 isolate Durable Objects that cold-start in milliseconds, because its agents write typed server code that runs on demand. The difference is what kind of machine your agent needs to be.

> **Key takeaways:**
> - ChatGPT Work uses microVMs because its agents need a real OS to install, run, and build things.
> - Cloudflare OS uses Durable Objects, V8 isolates, because its agents write bound server code that runs on a managed runtime.
> - A V8 isolate is a sandbox for code. A microVM is a sandbox for a whole computer. That is the whole trade-off.
> - Isolates win on cold start and latency, milliseconds. MicroVMs win on throughput for long-running parallel work.
> - Pick the runtime that matches what your agent produces: code that runs, or a machine that does things.

## What is the problem both are solving?

Two of the biggest agent platforms shipped within weeks of each other. ChatGPT Work launched on 9 July 2026. Cloudflare OS went open source on 5 August 2026. Both are agent workspaces. Both give an agent persistent state, tools, and a place to do knowledge work. Both face the same architectural question: what runs the agent?

The answer they chose is not the same. That is the interesting part.

This is not a review of either product. It is a map of a single decision, the runtime substrate, and why two serious teams landed on opposite sides of it. If you are building agents that touch real systems, this decision shapes everything downstream, from cost to security to what your agent is even capable of.

## What does an agent runtime need to do?

Start with what runs the agent, not what the agent is. An agent is a loop: read a goal, call a tool, observe the result, decide the next step. The runtime is the thing that executes that loop and holds its state.

That creates a requirement most people skip: an agent runtime is not a request handler. A request handler runs once and returns. An agent runs for hours, holds a working directory, installs dependencies, talks to services, and produces artifacts. It needs somewhere to keep that working state between turns, and it needs to be able to run real work, not only respond to HTTP calls.

That is why the runtime choice matters. It decides whether your agent can install a package, whether it boots in milliseconds or seconds, whether it is one thread or eight cores, and how hard it is to isolate from everything else on the machine.

## Why does ChatGPT Work run on microVMs?

ChatGPT Work's agent is a knowledge worker that needs a real computer. It connects to Slack, email, Drive, and calendars. It gathers context and produces finished work. It can create a working directory, install dependencies, run Python to analyze data, keep a database, and build files. On the desktop app in local mode, it operates your actual machine with full computer use.

That capability set is the argument for a microVM. You cannot install a package inside a V8 isolate. You cannot run a Python process or keep a PostgreSQL database inside a JavaScript runtime. If the agent must install, run, and build real things, it needs an OS.

So OpenAI gave each task [an isolated microVM](https://www.latent.space/p/unpacking-chatgpt-work). Pro accounts get 8 CPUs, 20GB of RAM, and a 64GB disk. The workspace is synchronized to persistent storage and restored onto isolated microVMs as needed. The underlying machine can change, but the working state carries over.

A microVM is a real Linux virtual machine. It has its own guest kernel, its own userspace, and hardware-virtualized isolation. It is the heavy option, and Work pays the weight deliberately, because the agent acts like a machine, not like code.

## Why does Cloudflare OS run on Durable Objects?

Cloudflare OS solves the same problem differently. Its agents write code. When you ask a workspace to build an app, the agent produces two parts: client code that renders the UI in a browser frame, and server code that stores state and implements behavior. That server code is [a Worker](https://blog.cloudflare.com/cloudflare-os/).

The server loads on demand as a Dynamic Worker and instantiates as a Durable Object Facet, a feature Cloudflare built for this. The facet gives the app its own SQLite database. Dynamic Workers use lightweight V8 isolates, so every app has its own isolated runtime without a dedicated server or container sitting around.

Cloudflare is explicit about the trade-off in the launch post: Dynamic Workers use V8 isolates, so every app can have its own isolated runtime without needing a dedicated server or container. They chose the code-sandbox model. The agent's output is an app, and the app runs on Workers.

The CIO post confirms they started closer to the container side and moved. The first internal version ran the harness in a container. The open-source release is built on Workers and Durable Objects.

## What is the actual difference between an isolate and a microVM?

A V8 isolate is the same runtime that runs a Cloudflare Worker. It is not a virtual machine. It is a sandboxed JavaScript runtime that shares the host OS kernel and process, but isolates your code's heap, globals, and execution. When a Durable Object hibernates, the runtime discards the in-memory JS heap and keeps the SQLite storage. Cold start is re-spinning the isolate.

A microVM is a real virtual machine. It boots a guest Linux kernel, its own userspace, hardware-virtualized. When Work boots your Pro computer, it is booting an OS. You can install packages, run any language, keep a database.

That is the whole distinction, and it is worth stating plainly:

- A V8 isolate is a sandbox for code. It contains code inside a runtime.
- A microVM is a sandbox for a whole computer. It contains an entire operating system.

Work needs a computer, so it uses a microVM. Cloudflare OS's agents write code that runs on a managed runtime, so it uses isolates.

## What does each choice buy and cost?

Here is the honest trade-off table. Isolates are thin, fast, and natively sandboxed, but they can only run what the runtime can run. MicroVMs are heavy and slower to boot, but they can run anything a Linux box can.

| | V8 isolate (Durable Object) | MicroVM (ChatGPT Work) |
|---------:|----------------------------:|-----------------------:|
| What runs | JavaScript and WASM code | Full Linux OS and any binary |
| Sandbox | Language level, inside the runtime | OS level, separate kernel |
| Cold start | Milliseconds | Tens to hundreds of milliseconds |
| Footprint | Megabytes | Hundreds of megabytes and up |
| Concurrency | Single-threaded, serialized | Multi-core, parallel processes |
| Can install software | No | Yes |
| Persistence unit | SQLite or KV you write to | Whole filesystem |

The speed question has a split answer. An isolate wins on request latency and cold start, milliseconds versus tens to hundreds of milliseconds. That is why Workers feel instant. A microVM wins on throughput for long-running CPU and IO work, because it has multiple cores and can run many processes in parallel instead of one thing at a time.

The subtle part: the thing that makes isolates fast, being thin and single-threaded, is the thing that makes them useless as a general agent runtime. The thing that makes a microVM capable, having a real OS, is why it boots slower than a Worker. You cannot get an agent that installs packages and cold-starts in a millisecond. It is a trade-off, not a bug.

## What does this mean for your own agent?

The runtime choice is not a style preference. It is a consequence of what your agent produces.

If your agent needs to install software, run arbitrary binaries, drive a real browser, or keep a long-lived database, you need a microVM or a container. ChatGPT Work chose microVMs because its agents do exactly that. The cost is cold-start time and footprint, and you pay it because you cannot get that capability any other way.

If your agent writes code that runs on a managed runtime, you can use isolates. Cloudflare OS chose V8 isolates because its agents produce Workers, and Workers are the natural home for that output. The benefit is millisecond cold starts and native sandboxing, agents that start with no access and get typed bindings when you grant them.

Most production agents are not one or the other. A coding agent that runs a test suite needs a real OS to execute the tests. An agent that drafts a document and calls a few APIs only needs to run its own logic. The runtime should match the heaviest thing the agent has to do, and no heavier.

If you are building on Cloudflare and your agent writes code, the Durable Object path is worth a hard look. It gives you per-app SQLite, native isolation, and no idle cost. If your agent must act on a real machine, reach for a microVM and accept the weight. The mistake is reaching for a microVM because it feels more powerful when your agent only writes code, or reaching for an isolate when your agent has to run a test suite.

## FAQ

> **Why does ChatGPT Work use microVMs?**
> Because Work's agents need a real computer. They install packages, run Python, keep databases, and drive a browser. That requires a full OS. OpenAI gives each task an isolated microVM, a real Linux virtual machine with its own kernel. Pro accounts get 8 CPUs, 20GB of RAM, and a 64GB disk.
>
> **Why does Cloudflare OS use Durable Objects instead of microVMs?**
> Because Cloudflare OS agents write typed, bound server code that runs on demand. That code runs in a Dynamic Worker, a V8 isolate, instantiated as a Durable Object Facet with its own SQLite database. It does not need an OS, so it does not pay the microVM weight. The platform was built to treat apps as Workers.
>
> **What is the difference between a V8 isolate and a microVM?**
> A V8 isolate is a language-level sandbox for code: it isolates your JavaScript heap and globals inside a shared runtime, no separate kernel, single-threaded, cold-starts in milliseconds. A microVM is an OS-level sandbox for a whole computer: a separate guest Linux kernel, hardware-virtualized, multi-core, but it boots in tens to hundreds of milliseconds and uses hundreds of megabytes.
>
> **Which is faster, an isolate or a microVM?**
> It depends on what you measure. An isolate wins on request latency and cold start, milliseconds versus tens to hundreds of milliseconds. A microVM wins on throughput for long-running CPU and IO work, because it has multiple cores and can run many processes in parallel instead of one thing at a time.
>
> **How do I choose between them for my own agent?**
> If your agent needs to install software, run arbitrary binaries, or drive a real browser, you need a microVM. If your agent writes code that runs on a managed runtime, like a Worker, you can use isolates and get millisecond cold starts and native sandboxing. The trade-off is capability versus weight.

## Related Posts

- [The Agent Access Model: how Cloudflare OS guards your agents](/posts/agent-access-model-cloudflare-os/). The security model built on those Durable Objects, and why Cloudflare chose isolates over microVMs for app output.
- [Cloudflare's Flue agent harness and why it matters](/posts/cloudflare-flue-agent-harness-stack/). Cloudflare's three-layer agent stack. Code Mode runs LLM-generated TypeScript in under 10ms isolates.
- [Project Think: the durable execution pattern](/posts/project-think-durable-execution/). Why Durable Objects give agents crash-recoverable state, the actor-model foundation Cloudflare OS builds on.
- [Coding agents need continuity, not memory](/posts/coding-agents-need-continuity-not-memory/). What persistent working state means for an agent, the reason the runtime matters.

---

This article was published on Agentic Up (https://agenticup.dev): practical guides for developers and founders building with AI agents. Reach me at hello@agenticup.dev