OpenAI Python SDK v3.36.0 Released: Vertex AI Access for Responses API, Major WebSocket Stability Improvements

The official OpenAI Python SDK has released version v3.36.0. This update follows two main threads: enterprise-grade deployment and real-time communication. On one hand, it adds Vertex AI support to the Responses API; on the other, it focuses on fixing multiple edge cases in Realtime WebSocket connections related to recovery, cancellation, and cleanup. Judging by the commit numbers and PR count, this is more of a "stability polish" aimed at production environments than a large-scale rollout of new capabilities.

Core Feature Updates: Vertex AI and API Type Extensions

The most notable change in this release is adding Vertex AI support to the Responses API (#4139). This means teams using Google Cloud Vertex AI as their model hosting channel can now complete the full lifecycle of the Responses interface through the Python SDK without relying on an additional adapter layer. The commit message also specifically mentions "preserve Vertex API root for response lifecycle" (#4140), indicating that the team also addressed the issue of the Vertex endpoint root path being overwritten during the response lifecycle—a detail that only real integrators would encounter.

At the API type level, v3.36.0 adds a usage count for 30-minute cache writes (#4111) and a compaction trigger ID (#4122), the latter being directly valuable to developers using context compaction capabilities. It also adds authorization management for custom voices (#4135) and prepares a native synchronous WebSocket option type (#4118).

Vertex AI is a one-stop machine learning platform provided by Google Cloud. In addition to training and deploying custom models, it also hosts third-party models such as Gemini and provides OpenAI-compatible inference endpoints. Previously, developers who wanted to call models hosted on Vertex AI through the OpenAI Python SDK often had to rewrite the base_url, construct project and region paths themselves, or use an intermediate proxy layer for protocol conversion. With the Responses API now directly supporting Vertex AI, the SDK can internally recognize the endpoint structure and authentication method for this channel. Developers only need to pass parameters such as project ID and region according to the official conventions to reuse the same Responses calling code, significantly reducing the cost of integrating multi-cloud models.

Responses API is a newer interface form from OpenAI compared to Chat Completions. It centers on the "response" object and natively supports tool calls, built-in tools (such as web search and file retrieval), multi-turn state continuation, and server-side session management, returning a structured sequence of output items in a single request. Compared with the message-array-centric design of Chat Completions, the Responses API is closer to agent-style workflows and also carries new capabilities such as context compaction and cached billing. Therefore, adding Vertex AI support for it is not just adding another channel, but enabling enterprises to use this more modern interaction model on their chosen cloud platforms.

Realtime and WebSocket: A Batch of Hard-to-Reproduce Issues Fixed Together

The Bug Fixes list is almost entirely occupied by WebSocket-related entries, revealing that the Realtime capability still has many edge cases in production use that need safeguards. Specifically, these include: cleanup of failed WebSocket connection attempts, respecting native options, ending synchronous WebSocket recovery on interruption, respecting Translation receives with timeouts during terminal cleanup, preserving WebSocket close state across recovery and cancellation scenarios, and respecting native options for the legacy beta socket (#4121, #4129, #4132, #4117, #4120).

Two other fixes deserve separate mention: accepting normalized batch responses in strict mode (#4106), and preserving declared aliases during Pydantic v1 validation (#4119). The latter is clearly meaningful for existing codebases still using Pydantic v1 and is a typical incremental fix that does not break compatibility.

Realtime API is OpenAI's interface for low-latency voice and multimodal interaction. Unlike regular HTTP requests, it establishes long-lived connections based on WebSocket, with the server continuously pushing events (such as audio chunks, transcription results, and interruption signals) while the client also sends events over the same connection. This bidirectional, stateful long connection means that scenarios such as connection establishment failure, recovery after session interruption, cancellation operations, and terminal cleanup all involve complex state machines. If a state is not correctly preserved or released, issues such as lost close state, connection leaks, or stuck recovery flows can occur—problems that are hard to reproduce. This is exactly why the fixes in this release focus on the three types of edge cases: recovery, cancellation, and cleanup.

Documentation and Miscellaneous: Python Code Generation Migration Enters Planning Phase

The Chores and Documentation sections reveal the next step in the SDK's internal engineering: the team has recorded a migration plan for Python-generated code (#4114, #4116) and restored the Castiron reporting script, supporting the next checkpoint in trusted reporters. These changes are invisible to ordinary users, but for the team maintaining SDK consistency over the long term, they are preparatory actions for redrawing the boundary between generated code and handwritten code.

Pydantic is a widely used data validation library in the Python ecosystem, and the OpenAI SDK relies on it for type validation of request parameters and response bodies. Pydantic v2 underwent a major refactor in performance and API, while v1 is still depended on by a large number of existing projects, so the SDK needs to be compatible with both major versions. Field aliases are a common Pydantic feature that allows Python attribute names to differ from JSON field names on the wire—for example, mapping fields like max_tokens that do not follow Python naming conventions to canonical attributes. If alias information is lost during validation, the field names in the serialized request body will be incorrect, causing the server to reject the request. The fix "preserve declared aliases during Pydantic v1 validation" targets exactly this compatibility detail.

Upgrade Recommendations

If your project meets any of the following conditions, it is recommended to upgrade as soon as possible: you are calling the Responses API through Vertex AI; you use Realtime WebSocket and have encountered lost close state after connection recovery, or connections not being properly released after cancellation; or you still rely on Pydantic v1 for request validation. If your use case is concentrated on standard Chat Completions and does not involve real-time connections, the benefits of this upgrade are relatively limited, and you can follow the regular dependency update cadence.

One-line Summary

OpenAI Python SDK v3.36.0 adds Vertex AI support and focuses on fixing Realtime WebSocket edge cases.

Paragraph Summary

The official OpenAI Python SDK has released v3.36.0, with updates centered on two main threads: enterprise-grade deployment and real-time communication. The core change is adding Vertex AI support to the Responses API and fixing the issue where the Vertex endpoint root path was overwritten during the response lifecycle, enabling teams using Google Cloud-hosted models to complete the full call chain without an additional adapter layer. At the API type level, it adds a usage count for 30-minute cache writes, a compaction trigger ID, custom voice authorization management, and prepares a native synchronous WebSocket option type. The Bug Fixes are almost entirely focused on Realtime WebSocket, covering scenarios such as cleanup of failed connection attempts, ending recovery on interruption, receives with timeouts during terminal cleanup, and preserving close state across recovery and cancellation. It also fixes normalized batch responses in strict mode and Pydantic v1 alias preservation. The documentation records a Python code generation migration plan, which is an internal engineering preparatory action.