What happened
Cloudflare’s agents@0.30.0 release, published October 22, adds support for Pi 1.4 in agents/harness/pi. The release says to update the Pi packages @earendil-works/pi-durable, pi-ai, and pi-agent-core to approximately version 1.4.0 (~1.4.0) and install @earendil-works/chord alongside them. This is not a transparent in-place compatibility change: Pi 1.4 migrates session storage to a schema Pi 1.3 cannot open, so a deployment cannot roll back past the upgrade. Cloudflare says existing objects need no separate migration step, and wake jobs left by earlier releases are handed over to the new wake job on first start.
The headline operational change is that PiHarness passes an onWake callback to the harness factory. A factory should pass that callback to Harness.open; the release says this lets a Durable Object hibernate while Pi tasks sleep instead of keeping the object in memory. Omitting onWake does not prevent the harness from working, but produces a warning and means the object stays in memory during Pi task sleeps. The release also asks users to make the factory safe to run more than once, because PiHarness now invokes it again when Pi reopens after a storage error.
The release changes task recovery and visibility. Tasks stopped by Pi’s restart limit appear as parked in pending(), and retry() runs them again. The Pi durable changelog is identified as the place to review associated breaking changes, including removal of TaskRuntime.sleep(), a new sleeping task status, and a restart limit that parks a crash-looping task after five restarts. PiHarness wakes from Pi’s wake() with one job per object, so a parked task no longer keeps the Durable Object awake. If a step fails, the wake job remains and retries with backoff up to 10 minutes; a memory-limit reset during the wait counts against the alarm memory-limit breaker.
The changelog also addresses lifecycle and storage failure edges. Pi reopens after a storage error rather than failing every call until the object restarts. Lifecycle no longer keeps evicted Durable Objects in memory when startup leaves a promise pending, and it arms a fallback alarm when startup fails while jobs are queued. pi-ai reports cut-off or idle model streams in language Pi treats as transient, allowing Pi to retry the turn. Users who create Pi’s registry at module scope are told to move it into the class or factory: Pi keeps harnesses subscribed until they close, and an evicted object that never closes a module-level registry can retain its harness in memory.
What the archive adds
This is a new version of a continuing Cloudflare Agents SDK thread, not a restatement: the 0.29.0 note covered Pi 1.3 compatibility for web search and related tools; 0.30.0 moves the harness to Pi 1.4 and adds recovery and hibernation behavior. An earlier Telegram post described Pi 1.0 as a stable, extensible agent harness, but it is not linked here because no public URL was supplied.
Trend signal
The release supports harness architecture outlives model choice: this update is principally about how the harness handles sleeping tasks, storage errors, retries, and lifecycle boundaries around Pi, rather than a new model capability. The release does not establish that the same design is becoming standard across the wider ecosystem.
Why now
The release is the next step after Cloudflare’s 0.29.0 Pi 1.3 compatibility update, published two days earlier, according to the supplied archive material. That sequencing makes the Pi version transition particularly relevant for maintainers who recently upgraded: the new version adds behavior, but its storage-schema change removes the option to return to Pi 1.3 after deployment.
Why it matters
For teams running Pi-backed agents on Durable Objects, sleep handling affects both execution behavior and resource use: forwarding onWake allows an object to hibernate during task waits rather than remain in memory. More importantly, the storage migration makes release management a compatibility decision. Teams should validate Pi 1.4’s breaking changes, the new parked status, and their retry behavior before deploying, then plan recovery without assuming an easy downgrade path.
The additional recovery paths can reduce the operational impact of storage errors, failed steps, and crash loops, but the release does not quantify memory savings or reliability improvements. It gives implementers concrete configuration and lifecycle details to check, rather than evidence that every deployment will benefit equally.
Limits and uncertainty
The release describes intended behavior and implementation changes, but supplies no benchmark for memory reduction, uptime, task completion rates, or the frequency of the failures being addressed. It does not specify a price or an adoption requirement beyond the listed package versions and installation of @earendil-works/chord. The exact effects of Pi 1.4’s breaking changes are delegated to its changelog; teams need to review that source before upgrading. The migration means rollback to Pi 1.3 is unavailable, but the release does not detail a forward recovery plan for a deployment that encounters problems after migration.
Skill to build now
Before upgrading, trace every Pi harness factory and verify it forwards onWake into Harness.open; check that the factory can safely run again after a storage error. In a staging deployment, exercise a sleeping task, a failed step, and a task parked at the five-restart limit, then confirm pending() and retry() behave as expected. Also search for module-scope registries and add explicit handling for the new parked status before rollout.
Reader takeaway
Agents SDK 0.30.0 makes Pi-backed Durable Objects more capable of sleeping and recovering, but the move to Pi 1.4 crosses an irreversible storage-compatibility boundary with Pi 1.3. Treat the release as a migration: update the factory and registry patterns, account for parked tasks, and validate the new behavior before deploying.