Your agent needs a computer, not a container — introducing @cloudflare/computer

The most capable agents have something simple in common: they are given their own computer to work with.

Coding agents work this way. You give them a filesystem, a shell, tools, packages, and the ability to run code. They inspect the environment, make changes, test their work, and keep going. The computer gives the model a familiar way to act on the world. At Cloudflare, we’re working hard to provide the right primitives on which to build the most capable agents.

Today we’re introducing an early preview of @cloudflare/computer. The @cloudflare/computer package provides an agent runtime where the details and mechanics of what code runs in an isolate, a container sandbox, or a web browser are handled by the platform. Each agent gets a computer, the runtime optimizes for efficiency, and scalability.

We believe that in order to meet the growing demand for compute required by agentic systems we need to look to solutions beyond traditional containerization. 

Changing how agents are built

We’ve seen a subtle evolution of this story over the past six months. At the start of the year, spinning up a container and running an agent inside of it was the norm. In recent months, we’ve Continue reading

Cloudflare Workers and Containers now support inbound TCP connections and gRPC

AI is changing how people interact with computers, and voice is becoming an increasingly important part of that shift. Real-time assistants, AI-powered dictation, and other voice interfaces need low-latency communication between clients, models, and supporting services. Many developers use gRPC, a Remote Procedure Call (RPC) framework built on HTTP/2 and TCP, for this infrastructure.

Ever since Workers launched in 2017, we’ve been expanding their capabilities, including adding the ability to open outbound TCP connections and a JavaScript-native RPC system built on Cap’n Proto. And so as part of Agents Week, we’re extending Workers in the other direction, supporting inbound TCP connections and adding new ways to run gRPC applications on Cloudflare.

Today, we’re announcing:

  • connect(socket) — a new handler in the Workers runtime that lets your Worker directly accept an inbound TCP socket provided by Spectrum (Cloudflare’s ingress proxy for non-HTTP traffic)
  • Full-duplex, bi-directional gRPC from Cloudflare Containers — forward the socket from your Worker to your gRPC server running in a container
  • Workers can serve unary and server-streaming gRPC APIs and call gRPC servers — you write your code using gRPC-web, and Cloudflare automatically converts incoming and outgoing requests to gRPC

We’re introducing this in private beta — Continue reading

Introducing the Billable Usage API: programmatic cost visibility for Cloudflare

Agents Week is about the shift already underway: agents write code, deploy Workers, and provision infrastructure on your behalf. That shift changes what you need to see. If a program is spending money in your Cloudflare account, you need to know what it's spending; throughout the day, per product, in a shape another program can consume. The dashboard is the right answer for humans. It's not the right answer for automation.

So we're launching a new Billable Usage API for self-serve accounts: a single endpoint that returns your account's usage and cost, broken down by product and by service period. It covers every usage-based Cloudflare product on the account, including Workers, R2, D1, Workers AI, Vectorize, Images, and Stream, all with one call. And if you already work in a FinOps toolchain, the column names should look familiar.

You'll get back an HTTP 200 OK with Content-Type: application/json and the usage rows in the response body. Today, usage and cost data are updated daily while we work towards providing more real time data. 

What comes back

Each row in the response is one charge period for one product on your account.

Smaller, faster, safer: running Kimi and GLM at scale

Workers AI runs inference for some of the best open models in the world on GPUs in Cloudflare data centers close to your users. Two of the most capable, and most demanding, are Moonshot's Kimi K-series and Z.ai's GLM. They are large, long-context, mixture-of-experts models, and they are wonderful to use. They are also very hard to serve efficiently because of memory constraints.

We've written before about how we serve large models on Workers AI and about separating the prefill and decode phases of inference to get more out of each GPU. This post looks at three techniques we layer on top of that to fit these models into memory and keep them fast: quantizing the KV cache, compressing the model weights, and, because both of those pack more requests onto shared hardware, protecting the cache those requests share. These optimizations enable us to support more customers at lower costs, with no change in model accuracy.

All our experiments and production traffic are running and benchmarked with SGLang, an open-source inference serving framework. We found that SGLang offers the best performance in the market, and we work closely with the SGLang team to upstream patches and new Continue reading

Workers RPC now works across Python and JavaScript

Two years ago, we introduced Workers RPC, built on Cap’n Proto RPC. This made it possible for Workers to call other Workers and Durable Objects’ methods, return live objects and call their methods, return functions, streams and get all the benefits of a Remote Procedure Call (RPC) system, without defining schemas or adding any dependencies. We called it “JavaScript-native RPC” because it made using RPC feel native to the language.

Last year, we made this work between web browsers and servers, and introduced Cap’n Web.

Now we’re taking it cross-language.

Normally, getting programs written in different languages to talk to each other is complicated: developers usually have to build custom APIs or adopt language-agnostic serialization formats like protobuf, so the two systems can understand each other. The RPC system built into Workers is able to translate across JavaScript and Python without any additional work.

You can now call methods defined in a Python Worker from a JavaScript Worker and vice versa. You can share objects across Python and JavaScript, and call methods on a Python object from TypeScript. It all just works.

If you define a method add() in a Worker written in TypeScript:

…you can simply call Continue reading

Welcome to Agents Week

This week is Agents Week.

As we started thinking about and planning the week, we wrestled with a broader question of what it means to support this new era of agents and what a purpose-built foundation for agents actually looks like.  Which brought us to a simpler framing: what is an Agent Cloud? 

We quickly realized however, that our framing was wrong. Not because it’s the wrong question to ask, but because of who we were asking — ourselves, instead of our agents. It’s no longer about us and what we think, but about what agents need. 

That, in a nutshell, is what Agents Week is about. 

The cloud we have today, and the web it sits on, were built for people. Every layer assumes a human is watching: pages designed to hold your attention, dashboards to click through, interfaces tuned for how we read and decide. But agents don't work that way. They don't get distracted, tired or fatigued…  and they have their own needs around speed, structure, and access.

An Agent Cloud has to do two things at once. It has to set us up for an agent-native future, where the primitives are built Continue reading

Worth Reading 080126


The honest target is goodput, meaning requests per second that actually met your latency targets. Count anything else and you are counting cold plates.

 


I find it strange that as a software industry, we put in so much effort to make our systems efficient to design, build, and scale with DevOps practices, cloud native architectures, event-driven functions, optimized databases and storage, and resource-sipping Lean IT — then we threw it all out the window when Big AI came along.

 


If there is one universal law in internet infrastructure, it is that no good intention goes unpunished by the practical realities of legacy software maintenance.

 


This Article updates and expands on 2012 research on encryption and globalization, analyzing what the authors call “Round 3” of the Going Dark Debate: the current controversies over end-to-end encryption (E2EE).

 


Using our unique position on the Internet, we took an investigative look at one of the well-known mandatory attributes in BGP, the ORIGIN attribute.

An API for MoQ: provision your own isolated relays

Last year, we enabled Media over QUIC (MoQ) on every Cloudflare server and opened the network for anyone to test. It provided a global MoQ endpoint, but not the isolation and access controls needed to run an application.

Today, we’re adding those isolation and access controls. The new MoQ provisioning API lets you create an isolated relay for your application and issue separate credentials for publishers and subscribers. The relays you create are available across Cloudflare’s network within seconds, with no servers to deploy, size, or load balance.
Cloudflare now supports the draft-14 and draft-16 versions of the MoQ Transport protocol with authentication support.

You can create relays through the API and the Cloudflare dashboard. They are completely free to use during beta.

A QUIC recap on MoQ

MoQ (originally short for Media over QUIC) is a new open protocol under development at the Internet Engineering Task Force (IETF), the standards body that also standardized HTTP, TLS, and QUIC. It is being developed in the open and will become a free public standard (an RFC) that anyone can implement. No single company owns it.

MoQ is a publish/subscribe system. A publisher sends out streams of data that have names, and Continue reading

IETF 126 in Space

The IETF does not launch rockets, or design spacecraft, or even work on radio systems and spectrum assignment, but it has been engaged in the standardisation of communications protocols used to communicate with these spacecraft. Here's a few topics that were presented at IETF 126.

DNS is infrastructure. It’s time to manage it that way.

Attackers aren’t always the reason for DNS failures — they can often be something much more routine. For example, the failure could result from regular domain management operations at the registrar level, as one Cloudflare 1.1.1.1 2025 DNS global outage last summer that lasted for 62 minutes. It occurred not because of a cyberattack, but a misconfiguration in their systems.  Anthony Eden, founder and CEO of DNSimple Beyond routing traffic, domains carry business value, intellectual property, and brand identity for enterprises, which is why those enterprises spend large sums on them. Those domains breathe inside the vendor dashboard — whether a registrar’s or a DNS host — and multiple stakeholders manage them manually, often leaving no record of who changed what.  When asked about the management gap, DNSimple — a developer-focused domain management automation and DNS hosting company — tells The New Stack, “Most engineers who are working at companies are already required to use tools like Terraform or Ansible to control all of their other services. So that means deploying servers and managing storage Continue reading

1 2 3 … 3,891