openai-python 3.15.0 ships prompt-cache prewarming and managed WebSocket sessions

OpenAI shipped openai-python 3.15.0 on September 18, and the changelog reads less like a version bump than a thesis statement about where the company thinks agent workloads are going. Five features landed under the api scope: agent session model settings (#3882), audio-mini model choices (#3886), compaction progress events (#3866), managed Responses WebSocket sessions (#3887), and prompt-cache prewarming (#3888). One bug fix preserves chat stream moderation results (#3864). The rest is chores and a documentation cleanup.

Any single item here is unremarkable. Taken together, they describe an SDK that is being reshaped for conversations that stay open for minutes or hours rather than requests that return in a second. That is a meaningful shift in how OpenAI wants developers to build, and it is worth reading carefully because the Python client is the reference implementation for nearly every other OpenAI SDK.

Prewarming is the tell

Prompt-cache prewarming is the most interesting line in the release. Caching has been available on the OpenAI API for a while, but it has always been reactive: you send a request, the system notices a shared prefix, and subsequent calls get a discount and a latency win. Prewarming flips that. You tell the API ahead of time what prefix you intend to reuse, and the cache is populated before the first real call arrives.

For anyone running a production agent, this matters more than it sounds. Long system prompts, tool definitions, and retrieved context are the expensive part of a request. If the cache is cold when the first user hits your endpoint, you pay full prefill cost on the critical path. Prewarming moves that cost off the request. It is the kind of feature that only shows up when a provider has decided that persistent, reused context is the normal case rather than the exception.

There is a real cost question hiding here, and OpenAI has not answered it in the changelog. Prewarmed cache entries occupy GPU memory whether or not traffic arrives to use them. If a developer prewarms aggressively and traffic does not materialize, someone is paying for idle KV cache. Whether that someone is OpenAI or the customer is the open question, and the release notes do not say. Watch the pricing page, not the GitHub tag.

Managed WebSockets and the session model

The managed Responses WebSocket sessions feature (#3887) is the second piece of the same story. The Responses API is OpenAI’s newer interface, positioned alongside Chat Completions for applications that want server-side state. WebSocket transport means the connection stays open and both sides can push. Combine that with agent session model settings (#3882), which let a developer configure model behavior at the session level rather than per call, and you get a coherent picture: OpenAI is selling sessions, not requests.

That has consequences for infrastructure. WebSocket connections are cheap individually and expensive in aggregate. A provider that encourages every client to hold a long-lived socket is committing to a connection-management problem that looks more like a chat platform than a REST API. The SIP call ID clarification in the chores list (#3885) is a small hint that voice is already part of this surface. The audio-mini model choices (#3886) reinforce it. OpenAI is not just serving text agents; it is serving agents that talk.

Compaction progress events (#3866) round out the picture. Compaction is the process of summarizing or trimming context when a conversation outgrows the window. Until now, that was opaque. Exposing progress events means developers can show users what is happening during a long-running session, or route around a slow compaction step. It is a small feature with an outsized effect on perceived reliability.

OpenAI is selling sessions, not requests, and the SDK is being rewritten to match.

What the moderation fix quietly says

The one bug fix in 3.15.0 preserves chat stream moderation results (#3864). Moderation on streaming responses is genuinely hard. When tokens arrive incrementally, a moderation decision that lands late has to either retract output the user already saw or be dropped. The fact that results were being lost in the stream is a reminder that safety plumbing in streaming systems is fragile, and that the fix is a patch rather than a redesign. Anyone building on streaming chat should read the linked issue and check whether their own pipeline handles late moderation signals correctly.

What this means for builders

Three practical readings.

First, if you are running agents with large static prefixes, prewarming is worth testing as soon as it is documented. The latency win on a cold start can be the difference between a responsive product and one that feels broken on the first request after a deploy.

Second, if you are choosing between Chat Completions and Responses for a new project, this release tilts the scales. Session-level model settings, managed WebSockets, and compaction events are Responses-side features. Chat Completions is not going away, but the investment is clearly elsewhere.

Third, watch the connection model. Long-lived WebSockets change your deployment topology. Load balancers, autoscaling, and idle timeouts all behave differently when every client holds an open socket. If OpenAI is nudging the ecosystem toward persistent sessions, the operational burden lands on application teams.

The open questions are pricing and parity. Prewarming has a cost that is not published. WebSocket session limits are not documented in the release. And the other SDKs, including openai-node and the community-maintained clients, will lag this release by days or weeks. The Python package is the leading indicator; the rest of the ecosystem follows.

For now, the tag is live, the commits are signed, and the direction is clear. OpenAI is building for agents that stay connected, and it is rebuilding the client library to match.