Cloudflare’s Agents SDK upgrades Pi to reduce storage and memory overhead

Cloudflare updated PiHarness to Pi 1.5 in Agents SDK 0.33.0 and described changes to streaming storage, memory use and scheduling.

**Dek:** The November 3 release moves PiHarness to Pi 1.5. Cloudflare reports fewer storage transactions during streaming and higher throughput in a scheduler benchmark with many sessions.

Cloudflare released Agents SDK 0.33.0 on November 3 and upgraded PiHarness to Pi 1.5. The changelog identifies three changes: fewer storage transactions during streaming, lower memory use when streaming large tool calls, and a scheduler that no longer rechecks every conversation on each commit. These changes concern the runtime around the model. Their effect depends on the workload an application gives that runtime. [Cloudflare changelog](https://developers.cloudflare.com/changelog/post/2026-11-03-pi-harness-pi-1-5/)

Where the reported speedup comes from

An agent session can generate a stream of partial results while the application maintains records of the work. Storage transactions and scheduler work can become noticeable when many sessions coexist, even when an individual request seems inexpensive. Cloudflare attributes its higher throughput to the scheduler avoiding work across conversations that do not need to be rechecked. In the company’s SQLite test with 2,048 sessions, a single Pi harness went from 88 to 459 agent runs per second. That result describes a particular harness benchmark. Model latency, tools and application storage can dominate a deployed workload. [Cloudflare changelog](https://developers.cloudflare.com/changelog/post/2026-11-03-pi-harness-pi-1-5/)

The separate memory change is most relevant when a tool call carries a large payload. A developer might see no meaningful difference with simple text prompts and still benefit when several sessions stream large tool arguments. Testing peak memory, transaction volume and completed runs separately can help identify which change matters to the application.

What to verify before rolling out the upgrade

Start with the versioned upgrade instructions and preserve a copy of the previous configuration. Exercise an existing session and a new session, including one tool call with a representative payload. Watch for missing or repeated work after interruption, as well as changes to the order in which a client sees streamed events. A lower write count is useful only if the session history remains suitable for the application’s recovery and reporting requirements. [Cloudflare changelog and upgrade notes](https://developers.cloudflare.com/changelog/post/2026-11-03-pi-harness-pi-1-5/)

A service with a large session count should also compare a quiet run with a burst of concurrent work. The benchmark indicates where the runtime removed overhead. The application’s own traces can show whether that overhead was significant enough to justify changing its capacity or service limits.