Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Agents SDK v0.33.0 uses Pi 1.5 through PiHarness; Pi Durable remains experimental, and its APIs may change between minor versions.
- Streaming content is persisted in batches within about a second by default. A crash can lose roughly the latest second of progress; setting settings.progress.persistWithinMs to 0 adds a storage write for each update.
- session.continue() starts a new run from the existing transcript; recovery replays only tools explicitly marked replay:safe.
- Pi 1.4 cannot read conversations that have run on Pi 1.5. After upgrading, roll forward to fix issues instead of reverting to Pi 1.4.
Confirm the version and compatibility boundary
Cloudflare Agents SDK v0.33.0 upgrades PiHarness to Pi 1.5. Compatibility is tied to the Pi minor version: Cloudflare lists the optional Pi peer packages at ~1.5.0, and each Agents SDK release supports one Pi minor. Pi Durable is experimental, so its APIs can change between minor versions. Check the release's upgrade guidance against the dependency versions your package manager resolves.
Replace callers of session.events() with session.watch(); retry() and the parked status have been removed. session.watch() shows recent transcript entries and live state, including a streaming answer, running tools, and why the prior run ended unanswered. The view is in memory; reopen the session after an object restart.
Evaluate fewer writes against the persistence window
Pi 1.5 stores streamed answers and tool output in batches instead of writing on every update. Cloudflare reports about 27 times fewer storage transactions for long answers and 5.7 times fewer for turns with parallel tools in its SQLite benchmarks, with CPU use down by about a quarter. Updates remain visible immediately, but the default persistence window is about one second, so a crash may leave roughly the latest second of streamed progress unsaved.
Setting settings.progress.persistWithinMs to 0 stores each update at the cost of more writes. The figures above are Cloudflare measurements of specific SQLite workloads, not performance or cost promises for another application. Choose the persistence window based on whether your task can tolerate losing the latest second of progress.
Check the result before continuing an unanswered run
For long tasks, submit() returns a receipt after storing input durably and before the model runs; wait() returns the result by operationId. After a model error or turn limit, check the original with session.wait(operationId) and fix the cause of the interruption. Continue only for an unanswered, idle session using session.continue({ operationId: `${operationId}:continue` }), then wait for receipt.operationId.
session.continue() starts a new run from the existing transcript without appending a user message. It is rejected while the session is busy. If the transcript already ends with an answer, the result is unanswered with reason nothing_to_answer. Continuation is not an unconditional retry button, and it does not prove that an earlier external tool had no side effect.
Separate harness recovery from repeating side effects
After a storage error, PiHarness reopens Pi and reruns the harness factory, which must be safe to execute more than once. Recovery replays only tools marked replay:safe; other interrupted tools return an interruption to the model. That mark is the application's replay policy, not proof an external side effect is safe to repeat.
For charging, resource creation, messaging, or other side effects, use external idempotency keys or check the original result before starting another operation. Do not resubmit the same business action merely because a run returned no answer. Do not treat session.continue(), storage recovery, and invoking a tool again as the same operation.
Treat the upgrade as a conversation-format change
Pi 1.4 cannot read conversation data written by Pi 1.5. Once a conversation has run on Pi 1.5, reverting to an Agents SDK version that uses Pi 1.4 can make that conversation unreadable. Cloudflare's guidance is to roll forward after an upgrade rather than roll back to Pi 1.4. Validate caller updates, tool replay rules, and recovery paths before allowing the new version to process conversations that must be retained.
This guide reflects Cloudflare's November 3, 2026 changelog and current Pi documentation. No installation, upgrade, or runtime recovery was performed. The sources do not guarantee account, plan, price, or regional availability; check the current official upgrade guidance for the version you deploy.
Sources
Frequently Asked Questions
Are queued inputs discarded after a failed run?
The default settings.afterFailedRun is keep: queued inputs remain and wait() keeps waiting. A later submit() processes the retained inputs in their original order before the new input; reset() can also restart retained work. The object can hibernate in the meantime, so retention does not mean completion. Fix the failure before choosing how to resume.
Does abort() immediately stop a running tool?
Not always. abort() waits for the session to become idle. If a tool ignores the abort signal, the session stays busy until the tool returns. Aborting the signal passed to wait() only stops waiting; it does not cancel background work. Check external results before repeating an operation with side effects.