@eiriktsarpalis, can you help review this? Thanks.

@stephentoub
Just had a case in some production code where o4-mini (as an Azure deployment) was not consistent in giving structured output (using GetResponseAsync < T > for request generation) and sometimes responded with:

{"type":"object","properties":{"field1":"foo","field2":true}}

instead of :

{"field1":"foo","field2":true}

which caused it to not deserialize as expected into the response type object.

When setting "strictJsonSchema" to true via ChatOptions the response is consistently returned correctly and GetResponseAsync < T > working as expected.

For developer convenience I think it should arguably default to strict, as figuring out that an AdditionalProperties needs to be set in ChatOptions is going to be difficult for a lot of developers. But I am not sure about the ergonomics of having these ChatOptions have defaults in such a manner. Just wanted to share the observations and fix. I realize this is a model issue and not a framework issue, but it might be useful.

I think it should arguably default to strict

We tried that and had to revert. OpenAI has strict rules for schemas that are allowed to be used with strict, and a bunch of schemas folks use (especially coming from arbitrary places with MCP) blow up. We've added in some transforms to help minimize the pain, such that we detect some violations and reconfigure the schema, but it's only a bandaid.