Skip to content

Expose configurable WebSocket message-size limits for Responses and Realtime transports #3644

@maxpetrusenkoagent

Description

@maxpetrusenkoagent

Please read this first

  • Have you read the docs? Yes: README, docs/models/index.md, docs/realtime/guide.md, docs/release.md, and the current GitHub release notes.
  • Have you searched for related issues? Yes. I searched repo-local open/closed issues and PRs plus broader GitHub searches; duplicate-search details are below.

Describe the feature

Please expose a configurable WebSocket message-size limit for both OpenAI Responses WebSocket transport and the Realtime WebSocket transport.

Right now both code paths hard-code max_size=None when calling websockets.connect, which disables the websockets library's incoming-message size limit. The SDK exposes keepalive knobs (ping_interval, ping_timeout, and for Realtime handshake_timeout), but not the message-size bound.

This matters for long-lived agent processes that run behind proxies or inside containers with explicit memory budgets. In our use case, we run agent operators over long sessions and want a way to bound resource usage without forking or monkeypatching the SDK. We do not necessarily need the default behavior to change; an opt-in config field would be enough.

Evidence inspected:

  • src/agents/models/openai_responses.py
    • OpenAIResponsesWebSocketOptions currently documents only ping_interval and ping_timeout.
    • _open_websocket_connection() passes "max_size": None to websockets.asyncio.client.connect.
  • src/agents/realtime/openai_realtime.py
    • TransportConfig currently documents ping_interval, ping_timeout, and handshake_timeout.
    • _create_websocket_connection() passes "max_size": None # Allow any size of message to websockets.connect.
  • tests/models/test_openai_responses.py has test_websocket_model_open_websocket_connection_disables_message_size_limit, which locks in max_size is None for the Responses WebSocket path.
  • docs/models/index.md shows responses_websocket_options={"ping_interval": 20.0, "ping_timeout": 60.0} as the low-level Responses WebSocket config surface.
  • docs/realtime/guide.md documents Realtime WebSocket as a long-lived connection and lists custom url, headers, and auth options, but does not expose a message-size/resource-limit control.
  • The upstream websockets docs for the asyncio client document max_size as the maximum incoming message size in bytes, with None disabling the limit.

Expected behavior:

Applications should be able to configure the incoming WebSocket message-size limit without replacing the SDK transport. For example:

  • responses_websocket_options={"max_size": 8 * 1024 * 1024, ...}
  • OpenAIRealtimeWebSocketModel(transport_config={"max_size": 8 * 1024 * 1024, ...})

Suggested implementation shape:

  • Add optional max_size: int | None to OpenAIResponsesWebSocketOptions.
  • Add optional max_size: int | None to Realtime TransportConfig.
  • Keep today's default behavior if you want full backwards compatibility, but pass the configured value through when present.
  • Add tests showing the configured value reaches websockets.connect in both transport paths.
  • Update the docs to mention that None disables the library limit and finite integers bound incoming message size.

Duplicate search performed:

Repo-local exact searches returned no covering issue/PR:

  • websocket max_size → 0 open, 0 closed
  • "max_size" websocket → 0 open, 0 closed
  • "Allow any size of message" → 0 open, 0 closed
  • "disables message size limit" → 0 open, 0 closed
  • "ResponsesWebSocketOptions" max_size → 0 open, 0 closed
  • "TransportConfig" max_size realtime → 0 open, 0 closed
  • "websocket message size" → 0 open, 0 closed
  • "resource limit" websocket realtime → 0 open, 0 closed
  • OOM websocket realtime → 0 open, 0 closed

Related but not covering:

Broader GitHub searches were also run for websocket and max_size across open and closed issues/PRs to avoid missing generic prior art.

Willing to contribute a small PR if this config shape is acceptable.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions