In April 2026, Cloudflare introduced Project Think as the next generation of its Agents SDK. The thesis is not a stronger model; it is moving the four capabilities coding agents have already proven — read files, write code, execute it, remember what was learned — into a serverless economic model: agents that can stay resident, hibernate, survive crashes, and cost nothing while idle. For teams evaluating agent infrastructure, here is how the mechanisms, the quantitative anchors, and the current limits fit together.
The scaling math is broken: agents are one-to-one
Tools like Pi, OpenClaw, Claude Code, and Codex proved a simple point: give an LLM the ability to read files, write code, execute it, and remember what it learned, and you get a general-purpose assistant — people use them to manage calendars, analyze datasets, even file taxes. But the Cloudflare team, who run these agents daily, keep hitting the same walls: they only run on laptops or expensive VPS, they bill even when idle, and dependencies and secrets require manual management.
The structural problem sits deeper. Traditional applications serve many users from one instance; agents are one-to-one. A hundred million knowledge workers, even at modest concurrency, mean tens of millions of simultaneous sessions. At current per-container costs, the math simply does not close.
The actor model: always resident, zero cost at rest
Project Think’s answer is the actor model on Durable Objects: every agent is an addressable entity with its own SQLite database. Hibernated, it consumes zero compute; when an event arrives — an HTTP request, a WebSocket message, a scheduled alarm, an inbound email — the platform wakes it, loads its state, handles the event, and puts it back to sleep.
The quantitative contrast is direct: 10,000 agents each active 1% of the time need 10,000 always-on instances in a container world; on Durable Objects, only about 100 are alive at any moment. The marginal cost of a new agent approaches zero, and the architecture shifts from “one expensive agent per power user” to “one agent per customer, per task.”
| VMs / Containers | Durable Objects | |
|---|---|---|
| Idle cost | Always on, full price | Zero while hibernated |
| State | External database required | Built-in SQLite |
| Wake and recovery | You build it (process managers, health checks) | Event-driven wake, state survives platform restarts |
| Unit of scale | Pre-provisioned capacity | One per agent, marginal cost near zero |
Durable execution: fibers turn crashes into recoverable pauses
A single LLM call can take 30 seconds; multi-turn agent loops run much longer, and a deploy, platform restart, or resource limit can land at any point. runFiber() turns the function call into a durable operation: registered in SQLite before execution starts, checkpointable at any moment via stash(), and recovered after a restart by onFiberRecovered. keepAlive() and keepAliveWhile() keep active work from being evicted. For tasks measured in hours, the right pattern is to start the work, persist the job ID, hibernate, and wake on callback.
Sub-agents, tree-shaped sessions, and memory that survives hibernation
Sub-agents are child Durable Objects colocated with the parent via Facets: each has its own isolated SQLite and execution context, with no implicit data sharing. RPC is typed, so misuse fails at compile time, and an orchestrator can drive several sub-agents in parallel with Promise.all.
Conversations are managed by the experimental Session API: messages are stored as a tree (each carries a parent_id), which enables forking to explore alternative paths, non-destructive compaction, and full-text search over history via FTS5; it also serves as the storage layer for the Think base class.
Long-term memory uses context blocks: the model sees a memory block annotated with utilization and budget, can update it actively with set_context, persists across hibernation, and pairs with withCachedPrompt() to cut repeated cost.
MEMORY [42%, 462/1100 tokens]
Preferences: reply in Traditional Chinese, attach minimal runnable examples
Project: deploys to Cloudflare Workers, tests run under Buncodemode: let the agent write code instead of playing tool calls
The shape of conventional tool-calling is wasteful: the model calls a tool, pulls the result back through the context window, then calls the next one — linear inflation as the tool surface grows. The insight behind codemode is that models are better at writing a program that operates the system: the LLM emits a single program and runs the whole task in a sandbox at once. The Cloudflare API MCP server exposes just two tools, search() and execute(), describing the entire API in roughly 1,000 tokens, versus roughly 1.17 million tokens for the naive tool-per-endpoint layout — a 99.9% reduction.
The capability model and the five-tier execution ladder
If models write code, the first question is where that code runs. Dynamic Workers are the answer: a V8 isolate that starts in milliseconds with a few megabytes of memory — roughly 100x faster than a container and up to 100x more memory-efficient, per Cloudflare’s numbers. The security design is a capability model: start with almost no ambient authority (globalOutbound: null, no network), then grant capabilities explicitly, resource by resource, through bindings. The question flips from “how do we stop it” to “what exactly should it be able to do.”
Stacked upward, that becomes the execution ladder: Tier 0 is the workspace on SQLite and R2 (@cloudflare/shell, useful on its own); Tier 1 is the network-free Dynamic Worker (codemode); Tier 2 adds npm (@cloudflare/worker-bundler bundles with esbuild); Tier 3 is a headless browser; Tier 4 is the full Sandbox, able to run git clone, npm test, and cargo build. Capability accrues tier by tier, and so does risk control.
The Think base class and self-written extensions
Builders who would rather not assemble primitives can extend Think directly: a minimal subclass only overrides getModel(), and after npx wrangler deploy you have a streaming chat agent — the official blog example uses Moonshot’s Kimi K2.5. Think shares the same underlying protocol as the existing AIChatAgent, but the positioning differs: the existing path uses AIChatAdapter, a roughly 15-line protocol adapter where you manage the model yourself; Think is an opinionated framework with tree-shaped sessions, non-destructive operations, and built-in sub-agent RPC. Think works as a top-level agent or as a sub-agent driven by a parent through chat().
More striking are runtime self-written extensions: the agent writes a new tool in sandboxed TypeScript, declares the network and workspace permissions it needs, and ExtensionManager packages and loads it into a Dynamic Worker as a callable tool — stored in DO storage and preserved across hibernation. Self-improvement happens through code, not fine-tuning.
Status and limits: a preview, not a promise
Cloudflare’s docs currently label Project Think an experimental preview: the concepts work today, the API surface is stable but will keep evolving, and none of this should be treated as a frozen production contract. The package is @cloudflare/think on npm, and the underlying Agents SDK already powers thousands of production agents. One detail worth noting when citing: the blog’s example model is Kimi K2.5, while the Think docs page uses Kimi K2.6 — attribute each to its source. What a builder should actually take away is the economics and the security design; the API surface can wait until it graduates from preview.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.