openai-python 3.50.0 and openai-node 7.56.0: reasoning input transformations (input_transformations) on Responses

openai-python v3.50.0 and openai-node v7.56.0 were released within a minute of each other on 2026-11-12 (python GitHub release 19:26:07Z, node 19:26:48Z), and their feature entries point at the same change: landing "reasoning input transformations on responses" on the Responses API response object - a new optional array, input_transformations, that reports in input order which reasoning inputs the server withheld and never delivered to the model. Every fact in this article was checked on release day against the PR diffs and the v3.50.0 / v7.56.0 tag sources, with an adjacent-version baseline (v3.49.0 / v7.55.0) confirming the field is genuinely new. A note on the verification channel: developers.openai.com returned 403 to this site throughout this batch's working window, so current-state claims about the docs domain are anchored to the successful fetch of 2026-11-12.

1. Versions and registry timeline

The two release-notes feature titles differ but describe one change: python says api: expose reasoning input transformations on responses, node says api: type reasoning input transformations on responses - "expose" versus "type", matching the pydantic response model on one side and the TypeScript interface on the other.

2. The change itself: Response.input_transformations

The new field hangs off the Response object (stable and beta shapes). At the OpenAPI layer (api_reference/openapi.transformed.yml, committed with the PRs), two schemas are added:

• InputRemovalReason: a string enum with five values - organization_mismatch, end_user_mismatch, model_mismatch, prefix_mismatch, turn_boundary;
• ReasoningInputTransformation: an object with four required fields - type (fixed reasoning), id (The original reasoning item ID.), action (fixed removed), and reason (a reference to InputRemovalReason). The beta side gets BetaInputRemovalReason and BetaReasoningInputTransformation twins of identical shape.

The new array field on the response object, quoted verbatim from the OpenAPI source:

input_transformations:
  type: array
  description: Reasoning inputs withheld from the model, in input order.
  items:
    $ref: '#/components/schemas/ReasoningInputTransformation'

The description is a single sentence: Reasoning inputs withheld from the model, in input order. None of the three surfaces - OpenAPI schema, python class, node interface - describes the five reason values individually. Literal translations (organization mismatch / end-user mismatch / model mismatch / prefix mismatch / turn boundary) are for searchability only; this article does not infer their semantics. What triggers a withhold, and when the field is omitted, are likewise not stated anywhere in this release's checkable sources.

3. Python side: the InputTransformation class and field (v3.50.0 tag, verbatim)

class InputTransformation(BaseModel):
    id: str
    """The original reasoning item ID."""

    action: Literal["removed"]

    reason: Literal["organization_mismatch", "end_user_mismatch", "model_mismatch", "prefix_mismatch", "turn_boundary"]

    type: Literal["reasoning"]

One optional field on each of Response and BetaResponse (same tag, verbatim):

input_transformations: Optional[List[InputTransformation]] = None
"""Reasoning inputs withheld from the model, in input order."""

InputTransformation is also added to the module __all__ export list (one added entry in each of the two export lists visible in the diff). Both action and type are single-value Literals - the only action value currently is removed, and the only object type is reasoning. That is the type-level fact and nothing more.

4. Node side: the InputTransformation interface (v7.56.0 tag, verbatim)

export interface InputTransformation {
  /**
   * The original reasoning item ID.
   */
  id: string;

  action: 'removed';

  reason:
    | 'organization_mismatch'
    | 'end_user_mismatch'
    | 'model_mismatch'
    | 'prefix_mismatch'
    | 'turn_boundary';

  type: 'reasoning';
}

The field side (identical in the stable and beta responses.ts files, under the Response and BetaResponse namespaces respectively):

/**
 * Reasoning inputs withheld from the model, in input order.
 */
input_transformations?: Array<Response.InputTransformation>;

5. Scope and baseline: response-side types only, stable and beta both

The diff's file list is the scope boundary: python touches only src/openai/types/responses/response.py and src/openai/types/beta/beta_response.py; node touches only src/resources/responses/responses.ts and src/resources/beta/responses/responses.ts; everything else is api_reference/openapi.transformed.yml, castiron codegen statistics, and generated-files.json hashes. Zero request-side or param-side type changes - input_transformations is a readable field on the response object, not a new parameter.

Counting method: grep -c 'InputTransformation\|input_transformations' against the same-path files at each tag (raw.githubusercontent.com), measured by this site on 2026-11-13. Zero-to-present across adjacent versions confirms the feature is new in this pair (the comparison covers the immediately preceding version only).

6. The rest of the release, and how this was verified

• Docs: one commit per package, "simplify review handoff instructions" (python #4266, node #3142) - repository collaboration docs, unrelated to the API.
• Dependencies: python #4261 bumps the CI action astral-sh/setup-uv from 10.3.0 to 10.3.3; node #3127 and #3131 are dev-dependency bumps in two ecosystem-tests directories (@cloudflare/workers-types, webpack) - all in deps / deps-dev territory, no runtime dependency changes.
• Verification method: release objects and PR diffs fetched through an authenticated gh api channel (the anonymous GitHub API quota was exhausted during this batch); type facts checked line by line against the v3.50.0 / v7.56.0 tag files, with the baseline taken from the same-path files at v3.49.0 / v7.55.0.

7. Common mistakes and troubleshooting

• Looking for it among request parameters: input_transformations lives on the response object; the batch's diffs changed no request types, so there is no matching input item to construct.
• Assuming the five reasons are officially explained: for now there are only enum literals. Wait for official documentation before writing migration logic against the literal translations in this article.
• Wrong versions: the field requires openai-python >= 3.50.0 / openai-node >= 7.56.0; the type layer of v3.49.0 / v7.55.0 has zero occurrences, so the field is not there to read.
• Beta versus stable naming: the OpenAPI schema names carry a Beta prefix on the beta side (BetaReasoningInputTransformation / BetaInputRemovalReason); the python class name is identical in both shapes (InputTransformation, defined separately in response.py and beta_response.py); the node interfaces nest under the Response and BetaResponse namespaces.

Next steps

• The previous SDK pair (3.49.0 / 7.55.0): openai-python 3.49.0 and openai-node 7.55.0: typed async function tools for the Agents API.
• Existing agent session settings - compaction, review, spend controls: openai-python 3.42.0 and openai-node 7.46/7.47: agent compaction and review settings, external keys, SIP DTMF.
• Every OpenAI release node on one timeline: OpenAI Models Release Notes (2026, Living Document).