OpenAIResponses seems broken to a level that makes me think nobody is actually using it.

[dkuettel]

Hi,

I'm trying to work with llamaindex's OpenAIResponses (a FunctionCallingLLM against the responses API). It didn't work out of the box with missing/wrong fields in the jsons that are sent out. Then I went and looked at the code and it doesn't give a lot of confidence that it's solid. Is anynone using it with success?

There seem to be many things wrong when it comes to the response api's strict settings, with missing additionalProperties = False all over, and then the transformation from llama index's internal history to the response api's history is wrong too especially when it comes to tool calls and tool results.

Is anybody seeing this? I don't understand how anyone could use it except for very simple cases, text only, no tools or anything.

Cheers.

[yudin-s]

I would treat this as two separate problems: schema correctness and transcript correctness.

For the Responses API path, the first thing I would check is the exact tool schema that LlamaIndex sends after adapter conversion. Strict tool schemas need closed objects, so every object level should have additionalProperties: false, not only the top level. If that is missing after conversion, the model/tool call layer can fail in ways that look unrelated to your original Pydantic/function schema.

The second thing is the tool-call history shape. Responses-style tool calls are very sensitive to preserving the call id and the order of tool call -> tool result -> next model input. If an adapter transforms old chat history into a shape that loses the response/tool ids, follow-up calls can break even if the first call works.

My debugging path would be:

1. Run the same model with a text-only prompt through OpenAIResponses.
2. Add one tiny tool with a fully closed JSON schema.
3. Log the raw request payload before it goes to OpenAI.
4. Compare it with the raw Responses API example payload.

If step 2 fails, it is probably a schema conversion bug. If step 2 works but multi-turn tools fail, it is probably the history/tool-result transform. In production I would stay on the Chat Completions adapter or the plain OpenAI LLM wrapper until the Responses adapter is solid for tool-heavy flows.

[smqd19]

We've encountered similar issues with OpenAIResponses and FunctionCallingLLM in our production environment. Specifically, we faced problems with missing additionalProperties = False and incorrect history transformation, which caused issues with tool calls and results.

• Our implementation involved fine-tuning LLMs with LoRA and QLoRA, and we had to modify the OpenAIResponses class to accommodate our specific use case.
• To address the history transformation issue, we implemented a custom history converter that handled tool calls and results correctly.
• We recommend checking the Pydantic models used in OpenAIResponses to ensure they match the expected response API schema.
  For example, you can use Pydantic's BaseModel to define your own models with extra set to "forbid" to enforce strict schema validation:

from pydantic import BaseModel

class CustomResponse(BaseModel):
    class Config:
        extra = "forbid"

This approach helped us resolve similar issues and improve the overall reliability of our LLM-based system.

[dkuettel]

ok thanks to both for the feedback. primarily I wasnt sure if im just totally off with my assessment. I'm also gonna roll my own little adapter then.