Responses API: invalid_request_error - 'function_call' was provided without its required 'reasoning' item

API Bugs
1

Using the Responses API, and switching from o3-mini to o4-mini has introduced a consistent error when using custom tools.

Every time I include an input array with a function_call and function_call_output, I get an invalid_request_error that Item of type 'function_call' was provided without its required 'reasoning' item.

This seems similar to the error reported here: How to solve "BadRequestError: 400 Item 'rs_ ... ' of type 'reasoning' was provided without its required following item" error in Responses API - #7 by alpengeist

The only way I’ve found to fix it is by including an extra reasoning input before function_call and function_call_output with the ID and (empty) summary set.

I can’t see this documented anywhere - is this an intentional requirement ? Or an API bug ?

2 Likes
2

Same here. I also notice that if you end up with a reasoning item as the last input item (not followed by a function call), you will get this error:

{
    "message": "Item 'rs_123' of type 'reasoning' was provided without its required following item.",
    "type": "invalid_request_error",
    "param": "input"
}
3

I just ran into this as well (With o3). What is also confusing to me is that response.output[0] is ‘reasoning’ [1] is a tool_call AND yet the status is ‘completed’ which seems wrong to me as well.

I am glad i pushed true with updating my code to work, because I had some prompting issues that no matter what I could not get 4.1 or 4o to do right. And o3 did it right away!

4

Then there is some undescribed API reference if you expand input message types of responses about a dozen layers deep: encrypted reasoning. Then this reasoning item that you cannot read yourself seems like something you can pass back. But no option to enable or disable receiving it in events. Yet, the API reference there in parallel still refers to passing a reasoning ID also as required. Which will fail if store is false. And if necessary for context quality and not just massive token consumption, is not present on Chat Completions.

A real cluster** of difference between specification, documentation, API - and services being broken by the ID validation.

5

I believe you. I’m glad I don’t have to deal with those encrypted reasonings for now :slight_smile: