Why Eval++ Is the Next Great Compute Primitive — Sunil Pai & Matt Carey, Cloudflare

Why does a website hit counter work locally, then fail when deployed as a serverless function? That small problem introduces the infrastructure behind Cloudflare’s agent work. Sunil Pai and Matt Carey began building on Durable Objects a little over a year before this discussion. A Durable Object has a database, but it is not simply a database: it combines addressable compute with state. Those distinctive platform capabilities are also an architectural commitment—the same features that enable new designs can create vendor dependence.

Start with a function that receives a request and returns a response. Put a counter outside it and increment the counter for every visit:

let counter = 0;

export default {
  fetch() {
    counter++;
    return new Response(String(counter));
  }
};

This counts requests handled by that particular in-memory instance. Deployment breaks the assumption that every request will see the same memory. An isolate might be reused under traffic, but it can also disappear or be replaced by another instance with its own counter. The problem is unreliable persistence, not that every request necessarily starts from zero.

The conventional repair is to move the counter into a database. Durable Objects change the unit of computation instead: requests and WebSocket connections addressed to a particular ID reach the same logical object. The application can organize its behavior around that identity instead of reconstructing it in unrelated request handlers. This is the sense in which Cloudflare calls the model stateful serverless: serverless deployment and scaling, with an addressable owner for state. Stable identity does not mean that one in-memory instance lives forever.

Pai gives roughly 15 ms latency in London as an example, comparing it with the approximately 16.67 ms available per frame at 60 FPS; he supplies no measurement setup. The practical illustration is tldraw: open a shared drawing on several phones and watch changes appear together. The same properties matter for agents. They need an address, persistent state, background work that is not tied to an incoming request, hibernation, and connections to other services.

The Agents SDK adds an application interface to that execution model. Import from agents, extend its class, schedule work at startup, and expose methods that clients can call. React hooks and plain JavaScript clients connect the frontend to the agent. Pai’s scheduling example is deliberately mundane: every Friday at 9 PM, collect Git history, a wiki, and Notion notes, compile an update for a manager, and introduce spelling mistakes so it sounds like its author. Scheduling makes the agent useful even when nobody has a browser open.

The next layer is production chat behavior. Model calls alone do not provide coordinated tool execution, resumability, or synchronization across tabs. Cloudflare supplies a backend for Vercel’s AI SDK to handle those concerns. Pai’s descriptions of enormous instance counts and the world’s best backend express enthusiasm rather than measured capacity or a comparative evaluation. The recording describes the SDK at that time; current packages separate higher-level chat into @cloudflare/ai-chat.

MCP brought another reason to use stateful infrastructure. Carey describes the difficulty of hosting early remote MCP servers, whose HTTP/SSE transport maintained a receiving connection alongside a separate POST endpoint. That is narrower than saying all MCP required a persistent network connection: the original transport specification also supported stdio and custom transports. Durable Objects were a natural fit for the remote connection model. Carey and Pai name PayPal, Sentry, Twilio, Linear, and Intercom as early examples hosted on this infrastructure. Working on those servers led the team toward Code Mode.

An ordinary Worker is a deployed serverless function. A Dynamic Worker starts from a different input: a string of code supplied to a running parent Worker. That string might come from a customer, a user, or an LLM. The parent loads it into its own isolated Worker and runs it without a separate deployment for each generated program.

The prospect of executing generated code produces sharply different reactions. At MCP Dev Summit, Carey encountered someone insisting that enterprises would never permit code they had not inspected; a Lockheed Martin attendee then approached with enthusiasm for precisely that capability. The disagreement makes the execution boundary central: accepting code is useful only if the host can constrain what it does.

A Dynamic Worker is an isolate, not a VM with a complete operating environment or filesystem. Carey describes on-demand scale reaching billions of isolates, without presenting a capacity test. The more immediate design opportunity is replacing an intermediate language. A product might currently turn form input into JSON, interpret that JSON as a DSL, and finally convert it into code. If the platform can execute untrusted code safely, the user or model can supply the code directly.

The sandbox model begins with restriction, then adds authority from outside. Pai contrasts this with starting from a VM or container and trying to secure everything around it. In the configuration he describes, generated JavaScript has no network access or application APIs until the host grants them. The host could expose four selected APIs, allow requests only to GitHub, or narrow access to a particular path such as github.com/xyz. A policy can itself be code—even a deliberately arbitrary failure rule using Math.random().

Explicit capabilities are stronger design tools than an outbound blocklist alone. Give generated code the operations it needs, while keeping environment variables and credentials outside its reach. Denied network access is a configured policy, not an immutable property of every Dynamic Worker: the host controls which bindings and outbound access it grants. That distinction separates executing a program from giving it the authority of the application that executes it.

The screen shows Cloudflare’s Dynamic Workers sandboxing article as the discussion turns to Code Mode. The proposed MCP demonstration is deferred to the speakers’ separate sessions; this discussion introduces the execution model rather than walking through that implementation.

Carey previews access to 2,600 Cloudflare API endpoints through approximately 1,000 tokens of tool definitions, not 1,000 total tokens for a completed task. The endpoint count is his spoken figure. The core idea of Code Mode is simple: have the model generate code, then execute that code. The details of endpoint discovery and the MCP implementation are left for his separate talk.

For decades, programmers have been warned away from eval, and ordinary eval is unavailable in Cloudflare Workers. Pai calls Dynamic Workers Eval++ because they revisit dynamic execution with a separate isolation boundary and controlled capabilities. His larger claim is that a discouraged branch of programming becomes worth exploring again when execution can be fast, secure, and inexpensive. Those are the product’s proposed advantages, accompanied by an invitation to try it—not comparative results established here. Interfaces can change when users and agents can supply executable programs rather than only fill predefined fields.

An audience member asks for the missing bridge: how do these primitives map onto applications people already build? Carey starts with generative UI. In an approach such as json-render, the model produces JSON that a renderer turns into an interface. His question is why the model cannot instead generate HTML or React directly.

The missing capability is often a place to execute untrusted rendering code. Claude Artifacts provides a familiar example of generated content rendered in a browser. Moving that work onto a server changes the trust boundary: the generated program must not inherit unrestricted access to the server’s resources. Carey proposes Dynamic Workers as the execution environment for that server-side rendering.

The second approach removes the need for JSON merely as a substitute for executable code. It does not remove the need to secure the resulting browser experience.

Pai’s next example uses the stateful side of the architecture. The Agents SDK supplies an execution environment that can work with LangChain, Vercel’s AI SDK, or another agent library. Ask an LLM for a long story, then refresh the page halfway through generation. In a request-bound design, continuing the stream may require separately coordinating storage, replication, and session routing.

With the agent attached to a Durable Object, reconnection has a stable destination:

1. The browser reconnects to the same agent identity.
2. If generation is still running, the backend supplies the beginning of the stream.
3. It continues delivering new bytes as they arrive.

The browser connection can be replaced without making the browser the owner of the generation process. The same arrangement supports multiple tabs, browsers, a phone, and a laptop observing the same work.

This extends the original collaborative-sync use case into a multiplayer agent experience. Pai imagines sharing a conversation link so two people can work with an AI in the same conversation, rather than each interacting with an isolated copy. Cloudflare owns the underlying distributed coordination; the SDK team builds the JavaScript behavior on top. The application developer can spend more effort on what collaborators should do together instead of constructing the synchronization machinery.

The audience then proposes a cloud interface for Claude Code, including the awkward lifecycle of starting a VM, closing an application, and resuming it later. Carey separates the agent loop from its clients. Run the loop in the Agents SDK, then connect a terminal, chat interface, phone, iOS application, or web application to the same persistent backend. Each client sees synchronized state and can resume interaction.

Pai confirms that Cloudflare is building such a harness on Workers and Durable Objects and hopes to ship it imminently. At this point in the recording, it is work in progress. Its intended combination is stateful agents that can start and stop, resumable interactions, and generated code executed on demand.

A lightweight execution core does not have to perform every task itself:

• Containers: Delegate heavier work through Cloudflare’s Sandbox SDK.
• Browsers: Connect browser execution when the task requires it.
• Other providers: Use tools such as Daytona, Browser Use, or Lightpanda where appropriate.

Workers and the Agents SDK become the persistent coordination point connecting these environments. The proposed architecture does not require every execution tool to come from Cloudflare.

A further question makes the agent more autonomous: could a cloud bot receive a voice message, schedule work, and create its own skills? Carey begins with storage. SQLite lives inside the Durable Object, and R2 can hold additional data. He initially describes connecting these pieces as manual work that will soon become easier.

Pai breaks an OpenClaw-style system into concrete ingredients: a heartbeat, a virtual filesystem, connections to services, control over secrets, and extensions. The extension mechanism is generated code executed in a sandbox. He reports implementing extensions that morning. Running the pi coding agent directly on Workers is a further goal under discussion with Mario, not an integration presented as delivered.

The language question follows naturally from a discussion dominated by JavaScript and React. Pai describes JavaScript and Python as first-class infrastructure languages, while acknowledging unfinished Python integration work. Other languages can target WebAssembly. He reports production use of Zig for undisclosed work and says its Wasm bundles are smaller than comparable Go and Rust output, without giving programs, build settings, or sizes. If native execution matters, a container remains an option.

If an LLM writes the code, the execution environment may matter more than whether the language matches the developer’s personal preference. There is still a preparation step for application code, however. Worker Bundler runs inside a Worker, retrieves npm dependencies, handles TypeScript and JSX, and produces executable output. Pai says Cloudflare’s dependency caching reduces exposure to npm downtime.

An audience member returns to the storage ambiguity: what exactly will stop requiring manual wiring? Pai clarifies that @cloudflare/shell is already usable at the time of the discussion. It provides a virtual filesystem layered over Durable Object SQLite, with R2 for larger files. This is not a full Linux environment or POSIX shell. His expectation that the APIs should not break is not a stability guarantee; current package documentation explicitly marks the APIs experimental.

The next application of the execution boundary is EmDash, the CMS Pai says launched the previous week. It runs on Workers and Durable Objects, with plugins executed through Dynamic Workers. WordPress plugin security incidents supply the motivation: extension code should run inside a restricted environment rather than inherit broad application authority.

EmDash’s portability and its plugin isolation are separate claims. The CMS can deploy outside Cloudflare, but the speakers say support for the Dynamic Worker portion on other platforms is still being developed. They also mention vinext, a Next.js implementation running on Vite, and preview more announcements during Agents Week the following week. Those availability and timing statements belong to the recording; Pai describes the broader announcement weeks as a twice-yearly practice.

The closing technical explanation concerns cost. Pai attributes Cloudflare’s low prices to infrastructure decisions made roughly a decade earlier: placing hardware near ISPs rather than relying on massive data centers, buying bandwidth in bulk, and using interconnection agreements to reduce the cost of traffic crossing network boundaries. In his account, free accounts follow from that business structure rather than functioning simply as marketing expenditure.

Pai cites a $5-per-month entry point and anecdotes of multimillion-dollar SaaS businesses built on the platform, without specifying included usage, overages, or total application costs. The economic proposition complements the technical one: persistent coordination and short isolated executions become more useful when developers can afford to apply them broadly.

The practical starting points are the Agents documentation and the Cloudflare Agents repository, where the speakers invite issue reports and agent-assisted feedback. The invitation is to build with the primitives: give work a durable identity, connect clients to that identity, and let generated programs act through capabilities the host deliberately grants.