Skip to main content

Cloudflare Agents SDK 0.33.0 Changes Pi Session APIs and Recovery

2 min read

Cloudflare’s Pi 1.5 integration batches persistence and changes session APIs. Existing Pi 1.5 conversations cannot be reopened by Pi 1.4.

Cloudflare Agents SDK 0.33.0 Changes Pi Session APIs and Recovery

Saving every answer fragment can create more storage work than the answer itself suggests.

Cloudflare announced Pi 1.5 support in Agents SDK 0.33.0 on November 3. The release note describes batched persistence, session API changes and a compatibility boundary for saved conversations.

Streaming stays visible while saves are grouped

Cloudflare says Pi accumulates output fragments before writing a group to storage. Each update is saved within a second. People can still see incoming text immediately. Under the default settings, a crash can lose about one second of streamed progress.

The company reports fewer storage transactions and improved throughput in its SQLite benchmarks. Those measurements reflect the tested configurations; we haven’t run the release or reproduced the results.

Several session calls change

Earlier API or behaviorPi 1.5 change
session.events()Use session.watch() for transcript updates and live state.
A run ends without an answersession.continue() can start another run without a new user message.
retry() and parkedThese are removed; tasks that exceed their restart limit end.
Tool rounds in new sessionsdefaults.maxTurns can cap the number of rounds.
Migration summary from Cloudflare’s release note and package changelog.

A continuation has conditions. Cloudflare’s example checks the earlier operation result before continuing after a model error. The session must be idle; a conversation that already ends in an answer does not need another run.

Conversation compatibility changes rollback planning

Pi 1.4 cannot reopen a conversation already used by Pi 1.5, according to Cloudflare. After adopting the new format, deployment fixes should use a compatible version rather than reverting to Pi 1.4.

This creates two separate recovery questions. Can the service recover recent streamed output after a crash? Can the previous software version read the conversation afterward? Reducing storage writes answers neither question by itself.

Include a restart in the evaluation

A useful later trial could record a long streamed tool call, interrupt the process, and observe the recovered transcript. Keep the configured persistence interval with the result. Test software compatibility in a separate copy of the conversation data.

These are proposed checks. We have not upgraded a production agent or measured data loss. Read the Agents SDK changelog before changing a deployment. Our production AI controls guide covers separate operational boundaries.

Leave a comment

Your email address will not be published. Required fields are marked *