Cloudflare Says It Can't Fit One Container Per Agent

Cloudflare shipped @cloudflare/computer on August 3, saying no hyperscaler has enough compute to give every agent its own container.

That capacity problem is why about 90% of agent commands route into V8 isolates instead of full Linux containers, per the company's engineering post. Each agent gets a virtual computer, and commands only escalate to a container when a job needs npm or a native binary.

A SQLite-backed virtual filesystem stays synced across both runtimes, with container access running through FUSE mounts. It can seed from object storage or a source repo. The tool is MIT-licensed, live on npm as an early preview, and sitting at 786 stars.

That's a direct challenge to eighteen months of agent-infra pitches built on the assumption that a container or micro-VM is the right unit of isolation. Cloudflare operates the fleet, and it's saying that model doesn't scale.

Two other posts from the same week back the same bet. Workers picked up a connect(socket) handler for inbound TCP, routing to gRPC servers in Durable Object Containers across 330+ edge locations. The named use cases are real-time voice and AI dictation, still in private beta with no public date.

Separately, dropping the KV cache from BF16 to FP8 pushed Kimi K2.6's in-memory context from about 686,000 tokens to 1.37 million. Concurrency rose from 32 requests to 64, hitting 2,192 tokens per second at roughly 30% less cost per token. INT4 weights shrank GLM 5.2's checkpoint from 705GB to 421GB with accuracy within 0.8 points.

Mastra made a similar bet the same day, launching managed sandboxes and filesystems for its platform. Billing folds into existing CPU time and egress rather than arriving as a separate infrastructure charge, per the announcement.