OpenAI Responses

OpenAI Responses

ProxAI uses the protocol name openai_responses for the OpenAI Responses API.

Protocol value

openai_responses

Request path

/v1/responses

Main code areas

src/protocol/openai/responses/wiresrc/protocol/openai/responses/requestsrc/protocol/openai/responses/responsesrc/provider/openai/responses

Conversion targets

pass-through selfopenai_chat_completionsanthropic_messages

Request model

At runtime, ingress parses the inbound body and produces PreparedOpenaiResponsesRequest. The protocol-layer lightweight projection is RequestProjection, located in src/protocol/openai/responses/request/projection.rs.

RequestProjection keeps the fields needed for routing, logging, and diagnostics, for example:

• model
• instructions
• stream / stream_options
• tools / tool_choice / parallel_tool_calls
• reasoning
• text
• max_output_tokens
• previous_response_id
• prompt_cache_key

It intentionally does not include the full input. input may be large and contains private prompts; downstream code must not depend on the original prompt content through the projection. The JSON actually forwarded upstream still comes from the normalized payload.

The wire model for request input is represented by InputParam, InputItem, Item, InputMessage, and related types:

enum InputParam {
    Text(String),
    Items(Vec<InputItem>),
}

enum InputItem {
    ItemReference(ItemReference),
    Item(Item),
    EasyMessage(EasyInputMessage),
}

EasyInputMessage and InputMessage support roles such as user, system, and developer. ProxAI’s Responses ingress performs the project-specific system-message normalization so that upstreams which reject the Responses-style system message shape keep working.

System-message normalization

ProxAI moves system text from input[] items into top-level instructions. This is the specific compatibility fix that motivated the proxy.

Non-streaming response

The complete Responses API response is represented by Response:

struct Response {
    id: String,
    object: String,
    model: String,
    status: Status,
    output: Vec<OutputItem>,
    usage: Option<ResponseUsage>,
    error: Option<ErrorObject>,
    ...
}

The output body is OutputItem:

enum OutputItem {
    Message(OutputMessage),
    FunctionCall(FunctionToolCall),
    FunctionCallOutput(FunctionToolCallOutputResource),
    Reasoning(Reasoning),
    // hosted tool items, MCP items, etc.
}

Each item has a stable id that matters for streaming reconstruction, multi-turn references, and cross-protocol translation.

Streaming

Responses streaming is event-oriented. Events describe lifecycle changes such as:

• response.created
• response.output_item.added
• response.output_text.delta / response.function_call_arguments.delta
• response.output_text.done / response.function_call_arguments.done
• response.output_item.done
• response.completed (terminal) / response.incomplete (terminal)

For the user-facing terminal-event expectations, see Streaming Behavior. For identifier and event-granularity rules, see Protocol Conversion.