Gpt-realtime-2 objects in tool calling bug?

API Bugs
1

when upgrading from gpt-realtime-1.5 to gpt-realtime-2, I’m facing issues with my tool calling when passing objects instead of simple types (working fine in 1.5 but not in 2)

is anyone else seeing the same thing?

2

Hi @dbhc,

Do you have a minimal example of the tool schema/object parameter that fails?

It would help to see whether the issue happens with any nested object or only with a specific schema shape. Also useful would be the exact error/response you get and whether it fails when registering the tool or when the model tries to call it.

A small example that works with gpt-realtime-1.5 but fails with gpt-realtime-2 would make this much easier for others to compare.

3

yep yep.

I’ll just copy and paste directly so I don’t mistranslate (it’s in C#)

Descriptor => new(
        "update_data",
        "Pass key-value pairs of data as properties of the 'metadata' object. Keys will be provided in the script.",
        new Dictionary<string, object?>
        {
            ["type"] = "object",
            ["properties"] = new Dictionary<string, object?>
            {
                ["metadata"] = new Dictionary<string, object?>
                {
                    ["type"] = "object",
                    ["description"] = "Key-value pairs of data to update.",
                    ["additionalProperties"] = new Dictionary<string, object?> { ["type"] = "string" }
                }
            },
            ["required"] = new[] { "metadata" }
        });
4

Thanks for sharing the schema, that’s very useful.

I don’t use this exact Realtime/C# setup myself, so I’ll leave the deeper debugging to others who can test it directly.

5

Hi @dbhc. Thanks for reporting this and also to @LarisaHaster for chiming in. We confirmed that this was a server-side issue and it has since been fixed.

If you encounter the issue again, please reply here or create a new topic and include the Realtime session ID and UTC timestamp for the affected turn. If available, please also include the response ID, output item ID, and the relevant raw WebSocket events with send and receive timestamps.

We can then reopen the investigation and correlate the new occurrence with the original traces.