Request and response message models should be separated to avoid applying output-only requirements to request payloads

Summary

The current schema appears to reuse the same Message model for both request and response payloads.

This causes output-specific message content variants (such as output_text) to become valid request content while still carrying response-oriented required properties such as annotations and logprobs.

As a result, request validation inherits requirements that appear to belong to response objects rather than client-authored request objects.

Problem

The specification currently allows a message content item of type output_text to appear within a message that is sent back to the service.

However, output_text is defined as a response-oriented structure with required metadata fields:

required:
  - type
  - text
  - annotations
  - logprobs

This creates an ambiguity:

Is output_text intended to be a response-only content type?
Or is it intended to be reusable when a client sends prior conversation history back to the service?

If the latter is true, output-side requirements are being imposed on request payloads.

Root Cause

The issue appears to originate at the message level, not the individual content type level.

A single Message model is serving two different purposes:

Messages produced by the service.
Messages supplied by the client.

These two scenarios have different validation requirements.

Response messages may legitimately require fields that are generated by the service.

Request messages should only require information that a client can reasonably provide.

Suggested Resolution

Introduce separate message models, for example:

InputMessage
OutputMessage

with independent content unions.

for example

InputMessage
  content:
    - input_text
    - input_image
    - input_file
    ...

OutputMessage
  content:
    - output_text
    - refusal
    - reasoning
    ...

This would prevent response-only requirements from leaking into request validation while making the intended lifecycle of each message type explicit.

Benefits

• Clear separation between request and response contracts.
• No ambiguity regarding which content variants are legal in requests.
• Reduced need for special-case validation exceptions.
• More accurate SDK and validator generation.
• Better support for conversation round-tripping scenarios.

Expected Outcome

Request validation should be driven by request-specific message types, while response validation should be driven by response-specific message types.

The same message model should not need to simultaneously represent both client-authored input and service-generated output, because those objects have fundamentally different validation requirements.

Start by locating the shared Message model and its request and response content unions in the OpenAPI schema. Compare the output_text required fields, including annotations and logprobs, with the information clients can provide in request payloads. Done means request and response validation use distinct message contracts without response-only requirements leaking into requests.