Represent Responses API beta variants without `?beta=true` in OpenAPI path keys

openapi.yaml contains Responses API path keys that include a literal query string:

/responses?beta=true
/responses/{response_id}?beta=true
/responses/{response_id}/cancel?beta=true
/responses/{response_id}/input_items?beta=true
/responses/input_tokens?beta=true
/responses/compact?beta=true

OpenAPI’s Paths Object represents relative endpoint paths. Query values are normally represented using in: query parameters rather than being embedded in a path key.

Embedding ?beta=true in the path key creates interoperability problems for OpenAPI tooling and makes stable and beta operations look like separate URL paths rather than variants of the same operation.

Why this matters

Many OpenAPI consumers treat the text following ? as part of the path identifier. This can result in:

• Invalid or unexpected generated URLs.
• Duplicate generated client methods.
• Incorrect routing behavior.
• Broken path-prefix filtering.
• Incorrect matching of path parameters.
• Tools interpreting beta=true as a fixed part of the endpoint.
• Difficulty merging or comparing stable and beta definitions.

It also means that a filter for paths beginning with /responses/ must contain special handling for /responses?beta=true.

Minimal reproduction

import yaml

with open("openapi.yaml", encoding="utf-8") as file:
    spec = yaml.safe_load(file)

paths_with_query_strings = [
    path
    for path in spec.get("paths", {})
    if "?" in path
]

print("\n".join(paths_with_query_strings))

Current behavior

The script returns multiple Responses API entries whose path keys contain ?beta=true.

Expected behavior

Paths Object keys should contain endpoint paths without query strings.

The beta distinction could instead be represented using whichever mechanism best matches the API’s actual behavior, such as:

• A query parameter.
• The existing openai-beta header parameter.
• A vendor extension such as x-beta.
• An OpenAPI Overlay.
• A separate beta specification.
• A generated stable view and a generated beta view.

I am not requesting a particular internal representation, only that standard OpenAPI consumers should not need to interpret a query string embedded in a Paths Object key.

Suggested acceptance criteria

• No key under paths contains ?.
• Stable and beta operation variants remain machine-readable.
• Beta-only request and response schemas remain distinguishable.
• Generated SDK behavior is preserved.
• The resulting document validates with standard OpenAPI 3.1 validators.
• Add a CI check rejecting query strings in Paths Object keys.

Start by inspecting the Responses API entries in openapi.yaml and run the provided Python reproduction to list path keys containing query strings. Determine how stable and beta operation variants are currently represented before choosing a standard-compatible representation. Done means no paths key contains ?, beta schemas remain distinguishable, generated SDK behavior is preserved, the document validates as OpenAPI 3.1, and CI rejects future query strings.