Summary: Cloudflare introduced Project Think in April 2026 as an experimental next generation of its Agents SDK, using Durable Objects for zero-cost hibernation, recoverable fibers, persistent memory, codemode, and capability-scoped execution. The design targets one-agent-per-customer economics, but the API remains a changing preview rather than a production contract.
Cloudflare brought out Project Think in April 2026, billing it as its Agents SDK’s next generation. The wager is not a smarter model, but moving four proven agent abilities — reading files, writing code, executing it, remembering what was learned — into an economics only serverless offers: staying resident, hibernating, surviving a crash, and costing nothing while idle. Below: how the mechanics work, where the numbers land, and what is still missing.
The scaling math doesn’t work: agents map one-to-one
Pi, OpenClaw, Claude Code, and Codex demonstrated one thing: once an LLM can handle files, author code, run it, and retain lessons learned, it becomes a general-purpose assistant — put to work on calendars, dataset analysis, even tax returns. Cloudflare’s own team lives with these agents daily and keeps hitting the same walls. Such an agent lives only on a laptop or a pricey VPS, keeps charging while idle, and needs its dependencies and secrets managed by hand.
The mismatch is structural. One instance of a classic application hosts crowds of users; an agent serves exactly one. Put a hundred million knowledge workers through that model at even light concurrency and tens of millions of sessions must be live at once — a bill today’s per-container pricing cannot cover.
The actor model: permanently resident, free while at rest
Cloudflare’s fix is the actor model built on Durable Objects. Each agent becomes an addressable entity holding its own SQLite database, drawing no compute while hibernated. An arriving event — an HTTP request, a WebSocket message, a scheduled alarm, or an inbound email — makes the platform restore its state, handle the event, and let it sleep again.
The arithmetic is blunt: under containers, 10,000 agents busy 1% of the time demand 10,000 always-on instances; under Durable Objects, about 100 are awake at any instant. One more agent thus costs nearly nothing, and the principle turns from “one expensive agent per power user” into “one agent per customer, per task.”
| VMs / Containers | Durable Objects | |
|---|---|---|
| Cost while idle | On all the time, billed in full | Zero during hibernation |
| State | Needs an external database | SQLite built in |
| Waking and recovery | Something you build (process managers, health checks) | Wakes on events; state outlives platform restarts |
| Unit of scale | Capacity provisioned ahead of time | One per agent, marginal cost near zero |
Durable execution: fibers make crashes recoverable pauses
A deploy, a platform restart, or a resource cap can interrupt at the worst moment, and multi-turn loops outlast the 30 seconds a single LLM call may take. runFiber() makes the call durable: entered in SQLite before the function body runs, checkpointed by stash() whenever needed, brought back by onFiberRecovered after a restart. keepAlive() and keepAliveWhile() stop in-flight work from being evicted. For a job measured in hours: start the work, save its job ID, hibernate, wake on the callback.
Sub-agents, tree-structured sessions, and memory that outlives hibernation
Through Facets, a sub-agent is a child Durable Object placed next to its parent, with its own SQLite and execution context; nothing is shared implicitly. Because the RPC layer is typed, a mismatch surfaces at compile time rather than at runtime, and Promise.all lets an orchestrator run several sub-agents at once.
Conversations go through the experimental Session API. Messages form a tree, since each carries a parent_id; that buys three things — forking to try alternative paths, compaction that destroys nothing, and full-text search over the history with FTS5. That layer also backs the storage of the Think base class.
Over the long run, memory runs on context blocks. The model gets a memory block tagged with how much of its budget is in use and can rewrite it with set_context; it survives hibernation, and pairing it with withCachedPrompt() lowers the cost of repeated prompts.
MEMORY [42%, 462/1100 tokens]
Preferences: reply in Traditional Chinese, attach minimal runnable examples
Project: deploys to Cloudflare Workers, tests run under Buncodemode: the agent writes code instead of chaining tool calls
Tool-calling as normally done has an expensive shape: each call goes out, its result returns through the context window, the next call goes out — cost climbing linearly with the number of tools. codemode inverts it: models are stronger when they write a program that drives the system, so the LLM produces one program and the whole task runs in a sandbox in a single shot. The Cloudflare API MCP server needs only two tools, search() and execute(), which describe the entire API in about 1,000 tokens, where one tool per endpoint would take roughly 1.17 million — a 99.9% reduction.
The capability model and the five-rung execution ladder
Once models write code, where does it run? Dynamic Workers handle that: each is a V8 isolate coming up in milliseconds within a few megabytes — by Cloudflare’s numbers roughly 100x quicker to start than a container, and as much as 100x more memory-efficient. Security is expressed as capabilities: a worker starts with next to no ambient authority (globalOutbound: null, no network), and bindings hand authority over one resource at a time. The design question shifts: instead of “how do we stop it”, ask “what exactly should it be able to do.”
Ascending, those pieces form the execution ladder: Tier 0, the workspace on SQLite and R2 (@cloudflare/shell, useful by itself); Tier 1, the network-free Dynamic Worker (codemode); Tier 2, npm added (@cloudflare/worker-bundler bundles with esbuild); Tier 3, a headless browser; Tier 4, the full Sandbox, able to handle git clone, npm test, and cargo build. Each rung buys more capability, and more control over it.
The Think base class and extensions the agent writes itself
Assembling primitives is optional: extend Think directly by overriding getModel() in a minimal subclass, and npx wrangler deploy leaves you with a streaming chat agent — Moonshot’s Kimi K2.5 is the model the official blog example picks. Beneath it sits the same protocol the existing AIChatAgent speaks; the positioning is what differs. The existing route goes through AIChatAdapter, a protocol adapter of roughly 15 lines, and leaves the model in your hands. Think is opinionated: tree-shaped sessions, operations that destroy nothing, and sub-agent RPC come with it. Either it is the top-level agent, or a parent drives it as a sub-agent through chat().
More striking is what happens at runtime, when the agent writes its own extension: it composes a new tool in sandboxed TypeScript, declares the network plus workspace permissions it needs, after which ExtensionManager bundles it into a Dynamic Worker the agent can then call — kept in DO storage, intact through hibernation. This kind of progress comes from code rather than from fine-tuning.
Status and limits: an experimental preview, not a promise
As it stands, Cloudflare’s docs file Project Think under experimental preview: the ideas function now, the API surface has settled but keeps changing, and nothing in it should be read as a production contract set in stone. The npm package is @cloudflare/think, while the Agents SDK beneath it already runs inside thousands of production agents. When citing, note one detail: the model in the blog’s example is Kimi K2.5, whereas the Think docs page goes with Kimi K2.6, so each belongs to its source. The economics and the security model are what a builder should really carry away — the API surface can wait for preview to end.