Multi-turn Responses API with Reasoning

[logan-markewich]

Typically, if I was using the responses API in python, I would add all output items from the responses API into some ongoing history list.

response = client.responses.create(
    model="gpt-5",
    tools=tools,
    input=input_list,
)

# Save function call outputs for subsequent requests
input_list += response.output

This ensures critical fields like reasoning stay in model input and allow caching to work.

However, none of the examples of the responses API really show how to do this, and I'm hitting a lot of type compability issues between InputItem and OutputItem, and its causing the model history to drop important fields like reasoning.

The existing examples of the responses API only show manually constructing function call items and appending to the history list, but it'd be much nicer if there was a way to do something like history.extend(response.output.into()) to convert vec[OutputItem] into vec[InputItem]

[logan-markewich]

To work around this, I have a fun convert function

fn output_item_to_item(output_item: &OutputItem) -> Result<Item> {
    match output_item {
        OutputItem::Message(msg) => Ok(Item::Message(MessageItem::Output(msg.clone()))),
        OutputItem::FileSearchCall(call) => Ok(Item::FileSearchCall(call.clone())),
        OutputItem::FunctionCall(call) => Ok(Item::FunctionCall(call.clone())),
        OutputItem::WebSearchCall(call) => Ok(Item::WebSearchCall(call.clone())),
        OutputItem::ComputerCall(call) => Ok(Item::ComputerCall(call.clone())),
        OutputItem::Reasoning(reasoning) => Ok(Item::Reasoning(reasoning.clone())),
        OutputItem::ImageGenerationCall(call) => Ok(Item::ImageGenerationCall(call.clone())),
        OutputItem::CodeInterpreterCall(call) => Ok(Item::CodeInterpreterCall(call.clone())),
        OutputItem::LocalShellCall(call) => Ok(Item::LocalShellCall(call.clone())),
        OutputItem::McpCall(call) => Ok(Item::McpCall(call.clone())),
        OutputItem::McpListTools(tools) => Ok(Item::McpListTools(tools.clone())),
        OutputItem::McpApprovalRequest(req) => Ok(Item::McpApprovalRequest(req.clone())),
        OutputItem::CustomToolCall(call) => Ok(Item::CustomToolCall(call.clone())),
        // Handle output types that don't directly map to Item variants
        OutputItem::ShellCall(_) | OutputItem::ShellCallOutput(_) |
        OutputItem::ApplyPatchCall(_) | OutputItem::ApplyPatchCallOutput(_) => {
            Err(anyhow::anyhow!("OutputItem variant cannot be converted to Item: {:?}", output_item))
        }
    }
}

[64bit]

Thank you for sharing.

Is there a complete Python example to have a look?

What do you think about OutputItem not mapping 100% to Item? Because of error return in your workaround?

[logan-markewich]

Here's the complete example from OpenAI + Python
https://platform.openai.com/docs/guides/function-calling#function-tool-example

RE not mapping 100%, yea its a good point. Not 100% how best to handle that. In my workaround a better idea is maybe skipping instead of raising an error