Cloudflare Bets Durable Objects and Dynamic Workers Can Power Cheaper Agents

Sunil Pai called Anthropic’s cloud-managed agents “dope” because they treat long-running agents as something developers should be able to build and deploy on a platform. He framed the launch as a useful signal: Anthropic is preparing for software that does not simply look like “the next CRUD API.”

His immediate reaction was also competitive. Looking at Anthropic’s approach, he said, made him think Cloudflare could do something better with Workers and Durable Objects.

The case rested on two Cloudflare primitives. Durable Objects, in Pai’s description, are “stateful serverless programming”: stateful units that can run in the background at large scale without provisioning whole virtual machines. Dynamic Workers, announced a few weeks earlier, are Cloudflare’s way to run evaluated code — user-generated or LLM-generated — in a controlled environment with “zero startup time.” Developers can expose only selected APIs and control outgoing traffic; the default pattern Cloudflare recommends, he said, is to cancel all outgoing traffic and use only the endpoints explicitly exposed.

Together, those primitives give agents both durable state and constrained execution. The agent does not just call a long list of static tools. It can generate code, run that code inside an isolate, and operate against a large surface area without repeated model round trips.

The clearest example was Cloudflare’s MCP server, built by Pai’s colleague Matt Carey. Cloudflare’s API has 2,600 endpoints. Exposing each endpoint as its own tool, Pai said, would be unworkable: “If you expose a tool for each one of them, you’re screwed.” Cloudflare instead reduced the interface to two tool calls: search and execute.

In that model, the agent submits code. For search, it can submit JavaScript that searches the entire OpenAPI JSON. For execution, it can submit code that performs the operation. Pai’s example was a compound administrative request: find all Workers, find the DNS records they are used in, and if a name starts with the letter Z, apply DDoS protection.

The significance of the example is not just that the interface is smaller. It changes where the work happens. Rather than asking the model to choose among thousands of predeclared tools or bounce through many calls, Cloudflare gives the agent a constrained execution environment where it can write the glue code needed to operate the API surface in one step. Pai said the result can be type-checked, run inside an isolate, and executed without “back and forth with the LLM.”

“Turns out LLMs are great at running code,” he said. That line captured the architecture he was pointing toward: not agents as callers of every possible button, but agents as writers of small, sandboxed programs.

The hosts pressed on the design of Claude managed agents: the separation between the agent harness and the execution environment, and whether that pattern might become standardized. Sunil Pai liked the separation. He said Anthropic was “preparing for a world of software that hasn’t existed in the past,” where the thing being built cannot be assumed to fit older application shapes.

The harness, in this framing, is the intelligence and capability layer: the part that mediates what the model can do, what it can access, and how it operates. The execution environment still needs to be sandboxed, but Pai’s interest was in the fact that platforms are now designing for software whose final form is unknown.

Asked whether there will be a unified layer around this, Pai was cautious. He said no one has yet built “the React” for agent software.

That analogy carried specific weight. Pai recalled React’s arrival in 2013 as something that initially annoyed people because it looked so different. Describing a component tree with XML seemed alien enough, he said, that people walked out of the introduction saying Facebook hated JavaScript. But React went on to shape later frameworks and remains large.

Pai thinks the agent world is in the pre-React phase. Everyone is building a harness; everyone has an opinion about what shape the harness should take. What has not yet appeared, in his view, is the original abstraction that is reproducible across languages, companies, and infrastructure.

One proposed candidate was “skills”: plain-English instruction bundles that can travel between systems and scale because they are written in English. Pai was open to the possibility. If the future of software turned out to be markdown files, he said, that would be “beautiful”: instantly accessible, multilanguage, and able to bridge worlds.

But he raised the obvious pressure on that design. If skills must become more and more specific, at some point they start to look like code. The counterpoint from the hosts was that skills can bundle code as well, which makes them less purely textual than the first description suggests.

Pai did not dismiss skills. He left the question unsettled. The larger claim was that the field has not yet found its durable cross-platform programming model for agents. Current harnesses may be useful, but they may also be local experiments before a more general abstraction arrives.

Sunil Pai’s story about Vercel began as an argument for candor in a small industry. He described software as “a forest of revolving doors”: friends, competitors, previous jobs, and future jobs all overlap. That is why, in his view, it is important to stay friendly and direct with people even when companies compete.

He emphasized that Cloudflare uses and respects Vercel’s work. He said Cloudflare loves Vercel’s AI SDK, that a portion of his agents SDK is built on top of it, and that Cloudflare believes it has built a strong back end for it. He also described personal relationships with people at Vercel, including plans to get a beer with Nico.

The incident involved a Vercel Labs project called Just Bash, which Pai described as “a pure implementation of Bash in JavaScript.” He liked it and wanted to make parts of it work with Cloudflare. In what he described as a normal 2026 workflow, he pointed Opus at the project, went to lunch, and returned to about 5,000 lines of generated code.

His stated plan was to publish the rough work, go home, polish it, and then send a pull request on Monday with an issue description — the way he said he interacts with open-source repositories generally.

Instead, he woke up to direct messages from Cloudflare management asking whether he had checked Twitter. According to Pai, Vercel’s CTO was criticizing the work publicly, and the framing became “Cloudflare did this” rather than “one person made a side project.” Pai said his immediate reaction was alarm: he saw a CTO of a large company attacking something he had treated as an informal experiment.

His response, as he described it, was earnest. He said he had wanted to talk, had come back and napped, and that the context was not hostile. He also noted that a talk he gave at JSConf España was later online and included warm comments about Vercel, Just Bash, and Vercel’s sandbox project.

The internet reaction then moved in the other direction. Pai said many people stood up for him, arguing that he was not the kind of person who would act maliciously. He spent the next 24 hours “awash in this love.”

The anecdote mattered because it set up the dispute over open-source norms. A fork, port, or rough compatibility experiment can be meant as admiration, curiosity, or normal maintenance. Under company logos and social feeds, the same act can be read as competitive aggression. Pai’s point was not only that Twitter amplifies drama; it was that public platforms can strip away the social context that makes open-source experimentation legible.

The discussion of “slop forks” moved from the Vercel story to a broader defense of forking. Sunil Pai said plainly that he loves slop forks. His view is that forking is a sign of prestige and respect in his culture, not an insult.

He tied that culture to React’s growth and to the mechanics of open source itself: one button, no money changing hands, people taking work and adapting it. When someone tells him his agents SDK is bad and they think they can build something better, he said his answer is: “Bro, go for it.” If the motive is love of the game, everyone wins.

The hosts brought up a more recent example: a leaked Claude Code repository that someone forked and rewrote in Python. Pai said people tagged him in those threads asking whether it was him; he said it was not. He also distinguished ordinary forking from derivative work that can violate copyright. In that case, he said, lawyers appeared to view the Python rewrite as still derivative.

That boundary mattered. Pai was not saying any copy of any code is acceptable. He was defending the norm of taking open work, adapting it, porting it, and learning from it — while acknowledging that leaked proprietary code is different.

The hosts suggested that slop forks may become more important because they let teams own their dependencies. Instead of being exposed to a dependency failure, a team could vendor a library and maintain its own rough fork. Pai agreed completely. Before NPM and modern package managers, he said, software often moved through Usenet or email: people took code, changed it, and shared something back. The cycles are now shorter, but forking remains fundamental.

The comparison to current agentic coding was revealing. The hosts noted that “build versus buy” has changed: a team might ask whether to use a microservice or “vibe code” a replica. But that framing often omits the middle path: see prior work, fork it, adapt it, and simplify it. Pai’s defense of forking was a defense of that middle path.

Sunil Pai’s enthusiasm for forking sits alongside a more pessimistic view of maintaining popular repositories. He said open-source repos have become “adversarial grounds.” On the agents SDK, Pai said contributions had been shut down and only issues were being allowed at the time of the discussion.

His reason was partly practical and partly security-related. If a user writes a long issue describing a problem, Pai said, he can take a resolution and paste it into Opus himself. He would rather spend his own tokens than accept untrusted contributions, because he trusts his own ability to ask questions and manage the process.

More broadly, he said maintainers are increasingly afraid of gaining popularity because popularity attracts abuse. He had spoken to four or five open-source maintainers at the event who said the situation was bad. The worst cases, in his view, are fake security reports: they look extremely valid, but when examined, they do not make sense.

A host connected this to a talk earlier that morning from Peter of OpenClaw, saying that this kind of issue was the “number one source of attacks right now.” The concern, as the host framed it, was that if someone compromised OpenClaw, “you get access to everyone,” which he described as remote code execution.

That created a tension in Pai’s position. He wants more forking, more experimentation, and more openness in how people adapt software. But he also described a maintenance environment in which accepting outside work has become risky enough that a project may close contributions and force interaction through issues only.

The result is not a simple anti-open-source argument. It is a picture of open source under pressure: forking remains essential, but the repository itself has become a contested boundary.

Sunil Pai’s closing advice was less about platforms and more about taste. In a world where many ideas can now be made to work because “the clanker” can help implement them, he urged developers not to spend their energy on incremental improvements.

His instruction was to be original. Build “sci-fi stuff.” Build things for your family. Use the agents SDK if it helps. Do not build only because the project might become a large enterprise deal.

The edge of the advice was that infrastructure and LLMs should almost fail under the weight of the idea. Pai wants people to try projects that strain the current tools, because that is how the next step change becomes visible. If the existing infrastructure handles the idea too comfortably, it may not be strange enough.

He was explicit about what he does not want: another agent framework. “Nobody needs it,” he said, before joking that people should use his agents SDK instead.