openai-python v3.20.0 ships agent sessions and WebSocket snapshot opt-in

OpenAI’s Python SDK shipped v3.20.0 on September 28, and the headline items are two new API surfaces: Agents credential and session options (#3967) and Cyber access programs added to Responses (#3956). The full release notes list four features, six bug fixes, and six documentation chores. There is no model launch here. There is something more useful: a map of where OpenAI’s client library is being asked to do work it was not built for a year ago.

Start with the WebSocket work, because that is where the volume is. Two features and four bug fixes in this release touch the streaming transport. The features are responses: opt in to incremental WebSocket text and tool snapshots (#3973) and responses: preserve detailed WebSocket accumulator snapshots (#3981). The fixes read like a list of ways a long-lived socket connection can betray you: live: avoid hangs at fractional transcript grouping deadlines (#3970), live: keep query parameters out of WebSocket endpoint paths (#3972), live: preserve caller queues and prevent uncertain WebSocket replay (#3980), realtime: preserve base URL queries in WebSocket upgrades (#3971), and realtime: retain configured queues without replaying attempted sends (#3978).

Read that list twice. “Uncertain WebSocket replay” is not a phrasing you invent for a demo. It is a phrasing you invent after a customer’s agent re-sent a tool call it was not sure had landed, and the tool ran twice. “Fractional transcript grouping deadlines” is not a phrasing you invent for a chat box. It is a phrasing you invent when a live audio session has to decide, to the millisecond, whether a fragment of speech belongs to the current turn or the next one. OpenAI is hardening the client for stateful, long-running, bidirectional sessions. The changelog is a confession about what production agent traffic actually looks like.

What “Agents credential and session options” implies

The Agents change is the one to watch, and the release notes give us almost nothing: a title, an issue number, a commit hash. No prose. That is normal for this repo, and it is also the point. The SDK now carries first-class credential and session options under an “Agents” namespace. Credentials plus sessions is the vocabulary of delegated authority: an agent that acts on a user’s behalf, for a bounded period, against a scoped set of resources. That is a different security model from an API key in an environment variable.

Tessera cannot verify from the release notes alone what these options do, what the credential lifetime is, or whether they map to a server-side token exchange. {/* TODO: verify Agents credential and session semantics against OpenAI API reference; release notes only name the feature */}. What we can say is that shipping the client-side shape before the public documentation catches up is how OpenAI has handled several surfaces this year: the SDK leads, the docs follow, the blog post arrives last. If you maintain an agent framework, this is the diff to read rather than the announcement to wait for.

The second feature, Cyber access programs in Responses, is stranger and more interesting. “Cyber” as a namespace inside Responses suggests a gated capability, and “access programs” suggests a vetting layer rather than a product tier. Plausible readings: a program for security researchers, a program for offensive-security tooling, or a compliance wrapper for customers in regulated sectors. The release notes do not say. {/* TODO: verify what Cyber access programs gate and who is eligible */}. What is notable is the placement. This is not a separate SDK. It is an option on Responses, which means OpenAI wants the gated capability to flow through the same request path as everything else, with the same streaming and tool-call machinery. Gate the access, unify the transport.

The boring fixes matter more than the features

The TLS fix is the one that will save someone a weekend. client: retry unmapped TLS transport errors (#3982) means the client now retries transport failures it previously classified as unknown and gave up on. If you have ever watched a batch job die at 3 a.m. on a connection reset that the SDK decided was not retryable, this is your fix. It is a one-line-sounding change with an outsized effect on long-running pipelines, and it is the kind of thing that only gets prioritized when enough paying customers hit it.

Then there is the documentation sweep: six chores, all “document X error responses.” Stored chat completions (#3963), Responses not-found (#3959), fine-tuning and model errors (#3964), files and uploads (#3960), batch (#3961), and a general clarification of documented API error responses (#3965). Six error-documentation PRs in one release is not housekeeping. It is a signal that error handling was the top source of developer friction, and that the SDK team is now treating typed, documented failure modes as a feature.

Six error-documentation PRs in one release is not housekeeping. It is a signal that error handling was the top source of developer friction.

What this means for builders

Three practical reads.

First, if you run agents in production, upgrade and read the WebSocket diffs. The replay and queue fixes address exactly the failure mode that makes agent systems untrustworthy: a tool call that may or may not have executed. Preventing uncertain replay is a correctness fix, not a performance fix, and correctness fixes in this area are worth more than latency wins.

Second, treat the Agents namespace as a preview of a security model, not a finished API. Credential and session options in the client usually precede a server-side story about scoped, expiring, auditable agent identity. If you are building multi-tenant agents today, watch how this namespace evolves; it will likely become the sanctioned way to hand an agent limited authority.

Third, budget for the transport. The amount of engineering in this release devoted to WebSocket lifecycle management is a warning. If your agent stack assumes request-response HTTP with a retry wrapper, you are building against a model of the world OpenAI is quietly leaving behind. The future here is a persistent socket, incremental snapshots, and a client that has to reason about what it already sent.

The version number is unremarkable. The distribution of work inside it is not: four features, six fixes, and the majority of both pointed at stateful streaming. OpenAI is not shipping a new capability in v3.20.0. It is admitting, in commit messages, what its customers are actually building.