ModelHTTPError caused by OpenAI client: Item of type 'function_call' was provided without its required 'reasoning' item

[lukekh]

Initial Checks

• I confirm that I'm using the latest version of Pydantic AI
• I confirm that I searched for my issue in https://github.com/pydantic/pydantic-ai/issues before opening this issue

Description

For starters, I think this is an issue with the underlying OpenAI client (potentially specific to gpt-5-mini e.g. this issue on mastra-ai), but it's causing me headaches.

I am getting this ModelHTTPError:

pydantic_ai.exceptions.ModelHTTPError: status_code: 400, model_name: gpt-5-mini, body: {'message': "Item 'fc_07f6eeb33dcce30d0068f9013ddefc8197aebff46ad603c528' of type 'function_call' was provided without its required 'reasoning' item: 'rs_07f6eeb33dcce30d0068f9013469b8819788dc43b3e5223aaf'.", 'type': 'invalid_request_error', 'param': 'input', 'code': None}

It's hard to get around and grinds my code to a halt. It seems to be fairly temperamental too, only occurring every now and again.

I have the settings

OpenAIResponsesModelSettings(
    openai_previous_response_id="auto",
    openai_truncation="auto",
    parallel_tool_calls=True,
    openai_send_reasoning_ids=False,
    openai_reasoning_effort="medium",
)

enabled and originally I had thought setting openai_send_reasoning_ids=False had fixed it, but alas!

Example Code

Python, Pydantic AI & LLM client version

Python 3.11.13, pydantic-ai==1.2.1, Azure OpenAI with gpt-5-mini

[DouweM]

@lukekh Do you have a history processor that may be dropping thinking parts, by any chance?

I'm surprised setting openai_send_reasoning_ids=False didn't prevent this, since we read it here:

pydantic-ai/pydantic_ai_slim/pydantic_ai/models/openai.py

Lines 1321 to 1323 in f5cc9e3

	send_item_ids = model_settings.get(
	'openai_send_reasoning_ids', profile.openai_supports_encrypted_reasoning_content
	)

And check it here:

pydantic-ai/pydantic_ai_slim/pydantic_ai/models/openai.py

Lines 1393 to 1400 in f5cc9e3

	param = responses.ResponseFunctionToolCallParam(
	name=item.tool_name,
	arguments=item.args_as_json_str(),
	call_id=call_id,
	type='function_call',
	)
	if id and send_item_ids: # pragma: no branch
	param['id'] = id

So we shouldn't be passing an id for it to complain about at all... If you could capture the HTTP request that'd be very useful.

[lukekh]

Yeah, I really think it's something funky happening with the OpenAI client because the call ids don't even match the ones I see in the logfire spans... If you have a look at the mastra issue I linked you'll see it seems to be deeper than pydantic-ai.

If you could capture the HTTP request that'd be very useful

Would I be able to find this in the logfire spans?

Edit:

Here's the most relevant issue I can find in the openai-python repo

[DouweM]

call ids don't even match the ones I see in the logfire spans

@lukekh That's expected as the Responses API now returns an id for each part, separate from the tool_call_id.

The problem in the Mastra and openai-python issues seems to be that the reasoning item following the function call, or the text message following the reasoning item, is actually missing from the history sent back to the API, which now requires the input to match verbatim the previous output if any IDs are included. So the solution is to make extra sure that all parts are sent back verbatim. I went through quite some effort to make sure we do that, but since history processing or other subtle bugs can mess it up I added the openai_send_reasoning_ids escape hatch to not send IDs at all. So I'm quite confused why that setting isn't working, and we need to figure out under what circumstances we're not sending the parts back verbatim.

Would I be able to find this in the logfire spans?

Are you capturing httpx requests? https://ai.pydantic.dev/logfire/#monitoring-http-requests

[lukekh]

Ah, nope. I'm adding the http instrumentation now. I had the Starlette instrumentation for the AG-UI agent server I'm running and thought that should do it, but I still couldn't see any of the requests to our Azure OpenAI deployment.

I've found the bug has gone away since setting parallel_tool_calls=False and removing `openai_reasoning_effort="medium". I'll have a play around with both of those again to see if I can isolate it to a single one of those settings and update you with the requests I get from adding http instrumentation if we see the bug again.