Cloudflare's Dynamic Workers Rehabilitate eval()

Every JavaScript developer has been told the same thing since roughly the Clinton administration: never use eval(). It executes arbitrary strings as code. It's a security hole. It is, simply, not done. Sunil Pai and Matt Carrie from Cloudflare's agents team walked into an AI Engineer conference session and made the case that we've been leaving an entire branch of the technology tree unexplored because of that rule—and that they've now built the infrastructure to safely go back and explore it.

The core argument they're making is architectural. Not "here's a cool library" but "here's a different way to think about what a compute primitive even is."

Start with the state problem

To understand what Cloudflare is pitching, you need to appreciate how annoying statelessness is. The standard serverless model—write a function, accept a request, return a response, die—is elegant and scalable. It's also deeply inconvenient the moment your application needs to remember anything. Want a hit counter? Your counter resets to zero on every cold start. Want to stream a long LLM response and survive a browser refresh midway through? Now you're bolting on a database, replication logic, sticky sessions, and a small prayer.

Durable Objects (yes, the name is terrible; Pai acknowledges this immediately) are Cloudflare's answer to that. The idea: for a given ID, a single class instance spins up once, and every subsequent request—every WebSocket connection, every background task—lands in that same place. Pai describes it as "stateful serverless, which is the most confusing thing, because servers are stateful." The confusion is real, but the capability is legit: you get the scaling properties of serverless with the memory properties of a server that doesn't forget who it's talking to.

The latency numbers they cite are striking. Fifteen milliseconds in London. For reference, 60 frames per second works out to about 16.6ms per frame. Carrie's point is that at 15ms, you're operating inside a single animation frame—which is why collaborative tools like TLDraw, built on this tech, can sync drawing across multiple phones in what feels like perfect real time.

It's a genuine capability claim, and it shapes everything that follows, because Durable Objects turn out to be a natural fit for AI agents: they're addressable, persistent, they hibernate when idle, and they can run background jobs on schedules without any incoming request to trigger them. Pai's scheduling example—"every Friday at 9pm, go through my Git history and compile something for my manager, and mess up the spellings so it looks like I wrote it"—is a joke, but the underlying point is real. Persistent, scheduled, stateful compute is exactly what agentic workloads need.

The resumability argument

One of the more concrete benefits Carrie walks through is resumable streaming. Ask an LLM for something long. Hit refresh. In a standard serverless setup, you've lost the stream—you'd need to reconstruct it from state stored somewhere else, which means database writes, session handling, the whole distributed systems shebang. With Durable Objects, you reconnect to the same instance and it just... continues. "Here's the beginning of the stream, and I'm going to keep giving you bytes."

That same persistence gives you multi-tab sync and multi-device sync essentially for free. Carrie makes an observation worth sitting with: "Why can I not share a link to my ChatGPT chat with you and both of us work in the same conversation?" The answer, he suggests, is that building that feature requires significant distributed systems work that the existing primitives make painful. Durable Objects make it a default rather than an engineering project.

This reframes the product pitch slightly. Cloudflare isn't just offering cheaper Lambda equivalents—they're arguing that the architectural model itself removes whole categories of distributed systems complexity from user code. Whether you believe that depends on how much you trust any vendor's abstraction to hold under real production load. The "make it Cloudflare's problem" framing is honest about the tradeoff: you get simplicity in exchange for genuine platform dependency.

The eval++ idea

Here's where it gets philosophically interesting. Cloudflare's new Dynamic Workers primitive lets you take a string of code—generated by an LLM, submitted by a user, whatever—and run it in a sandboxed isolate on demand. No deployment step. No VM overhead. Just: here is code as text, run it now.

As Pai puts it: "For the last 30 years they've told you never to use eval in code. In fact, on Cloudflare Workers, eval doesn't exist—it's dangerous. But we took it and Dynamic Workers are like eval++."

The security model they describe flips the usual approach. Traditional sandboxes start from a full environment—a VM, a container—and try to restrict outward from there. Dynamic Workers start from nothing. The isolate has no fetch, no APIs, no environment variables, no file system access. You grant capabilities explicitly from the outside: only these endpoints, only outgoing requests to this specific domain, nothing else. The default is zero access; everything is opt-in.

Carrie mentions he was at MCP Dev Summit recently and encountered two simultaneous reactions to this idea: a startup founder insisting no enterprise would ever allow running generated code in production, immediately followed by someone from Lockheed Martin saying they love it. That gap—between people who see the risk and people who see the capability—is probably the most honest summary of where Dynamic Workers sits right now. The technology is new. The security claims are Cloudflare's own. Independent validation takes time.

What this enables (and what it's replacing)

Pai uses generative UI as a concrete example. A lot of current LLM-powered UI work involves generating JSON that then gets transformed into rendered components—a pattern sometimes called JSON Bender. The question he poses is direct: why generate a JSON schema when you could generate actual React, and render that directly? The answer has historically been that rendering untrusted code server-side is scary. Dynamic Workers are explicitly positioned as the primitive that makes "just generate the code" safe enough to consider.

The MCP (Model Context Protocol) angle is also worth flagging. When MCP launched, it required stateful connections between client and server—exactly what most serverless infrastructure handles poorly. Carrie and Pai say they jumped on Durable Objects for MCP servers early, and they've since hosted MCP integrations for PayPal, Sentry, Linear, Intercom, and others. The upcoming talk Pai teases goes further: collapsing all 2,600 of Cloudflare's own API endpoints into a single ~1,000-token MCP tool using "code mode"—the Dynamic Workers approach of generating and running code at query time rather than pre-defining every possible action as a static tool.

That's a genuinely interesting design challenge. The alternative—exposing thousands of endpoints as individual MCP tools—creates a token budget problem that grows with API surface area. Generating code to call the right endpoints on demand is a different architecture, and it's one that becomes viable specifically because you can run that generated code safely.

The vendor lock-in question Pai raises himself

Pai mentions, somewhat preemptively, that the features Durable Objects provide are "unique capabilities—some might call it vendor lock-in, some might call it innovation." He doesn't resolve the tension, which is fair. The honest version of the concern: Durable Objects are a Cloudflare-specific abstraction. The resumable streaming, the multi-tab sync, the background scheduling—all of this is easier because you're inside Cloudflare's infrastructure. The moment you want to run on AWS or GCP, you're rebuilding those primitives yourself or finding equivalents.

For some use cases, that tradeoff is clearly worth it. For others—regulated industries, organizations with existing cloud commitments, anyone who's been burned by platform lock-in before—it's a real consideration. The fact that Cloudflare's new CMS (which they mention running fully on Workers and Durable Objects) is designed to deploy on other platforms too suggests they're aware of the concern and working around the edges of it.

The thing being announced is already shipping

Toward the end of the session, Carrie and Pai essentially confirm they're building a full coding agent harness on Workers—persistent, stateful, resumable, multi-client, with Dynamic Workers for sandboxed code execution. They describe it in future tense but then clarify: "We're building it just so we're clear... we hope to ship it imminently."

The vision they sketch—an agent with a heartbeat, a virtual file system, connections to external services, and the ability to generate and run its own extensions in sandboxed isolates—maps pretty closely to what people mean when they talk about "open cloud" style agents. Whether Cloudflare's specific implementation of that vision is the right one remains an open question. But the underlying bet—that persistent, stateful, capability-gated compute is the right primitive for autonomous agents—is worth watching closely.

Thirty years of "don't use eval" is a long time to leave a branch of the tech tree unexplored. The question now is whether the sandbox is actually as secure as Cloudflare says it is, or whether we're about to find out why the rule existed in the first place.

---

By Yuki Okonkwo, AI & Machine Learning Correspondent, Buzzrag