Cloudflare has released @cloudflare/computer, a runtime for agents that dynamically chooses between fast isolates and full Linux containers, and has launched “Agents Week”: a series of posts on how cloud infrastructure must change when clients are autonomous agents, not human browsers.

Why it matters to you. If you’re deploying agents in production, where and how they run matters as much as the model you choose. An agent that needs to browse the web requires a browser in a full Linux container. One that processes text quickly is better off in an isolate (a lightweight execution environment that starts in milliseconds). Today you manage this choice manually, building infrastructure around it. @cloudflare/computer puts a runtime in the middle: you declare what you need and it routes to the right environment.

This ties into a thread we’ve been following. As we reported in July, the MCP protocol became stateless to scale better. Now Cloudflare is doing the same thing at the execution level: the runtime environment becomes orchestratable, not fixed.

The week’s second post covers inference: how to serve Kimi and GLM on GPU without running out of memory, using KV cache quantization (the memory where the model stores conversation context) and weight compression. Details that affect costs for those running agents at scale.

If you want to follow along. Agents Week posts and @cloudflare/computer documentation are on Cloudflare’s blog.

In detail

Cloudflare Workers has existed since 2017 as a platform for running code at the network edge. The model is the isolate: a sandboxed execution environment that starts in milliseconds and uses very little memory because it doesn’t boot a full operating system. It’s perfect for responding to an HTTP request, transforming JSON, serving a page.

Agents have a different problem. An agent that browses the web needs a browser, and a browser needs an operating system. An agent that writes and processes files needs a real filesystem. Isolates aren’t enough. Full Linux containers solve this, but they start in seconds instead of milliseconds and consume more resources. Until now, anyone deploying agents on Cloudflare had to pick one path and build everything around that choice.

@cloudflare/computer puts a runtime in the middle that decides automatically. The agent declares what it needs (a browser, a filesystem, network access) and the runtime routes it to the right environment. If the task is lightweight, it goes to isolate. If a browser is needed, it goes to a container. The transition is transparent to the agent, which always sees “a computer” as its execution environment.

Agents Week expands the argument. Cloudflare contends that cloud infrastructure was designed for a world where humans with browsers make requests: rate limiting calibrated to human traffic, storage built for user sessions, security based on cookies and CORS. Agents break these assumptions. They make requests at high speed, maintain state for hours, access resources in ways current security patterns don’t cover. A new set of primitives is needed.

The week’s second post goes one level deeper: how to serve frontier models like Kimi and GLM on GPU without exhausting memory. Cloudflare applies quantization to the KV cache (where the model stores conversation context) and compression to model weights, with integrity checks to verify compression hasn’t corrupted results. For those running agents that consume many tokens, inference costs are decided here too, not just by the model’s price tag.

Limits of what we know. The blog posts describe the architecture, but details on pricing, SLAs, and general availability of @cloudflare/computer aren’t yet clear from the published material. Agents Week is ongoing: more posts may add operational information in the coming days. For anyone evaluating the platform for production agents, the runtime is interesting conceptually but should be tested against your actual load before making a decision.