Add support for new parameters accepted by GPT-5

[mattcorey]

GPT-5 and it's related models support a few new parameters that need to be added to the SDK:

• A new 'minimal' option for Reasoning Effort
• A new 'verbosity' parameter
• Free-form function calling
• Context Free Grammar

Details can be found here: https://cookbook.openai.com/examples/gpt-5/gpt-5_new_params_and_tools

[lzell]

Partially closed by: #203

[richarddas]

Although the OAI API Reference docs include "minimal" as a value, the API returns an error when passing minimal

Currently supported values are minimal, low, medium, and high

And the OAI Getting Started With Reasoning does not mention "minimal":

Specify low, medium, or high for this parameter, where low favors speed and economical token usage, and high favors more complete reasoning. The default value is medium, which is a balance between speed and reasoning accuracy.

[mattcorey]

The '.minimal' value is only usable with the 'gpt-5' series models - if you use this value with 'gpt-5', 'gpt-5-mini' or 'gpt-5-nano', it will work. Using this value with other models will fail.

Even with those models, if you use the 'web_search_preview' tool, it stops working (this was a sad discovery 😢).

This is, unfortunately, the way OpenAI's API's work these days - they present a nice, simple, unified API, but the individual models all support only different subsets of the possible parameters.

[richarddas]

I'm pretty sure I was working with the model set to gpt-5 and that's when I got the error from the API saying that 'minimal' wasn't a recognised value.

Regarding the web search, yes I just discovered this: I wanted to try to see if "web_search" would work instead of "web_search_preview" (which says tool is not available?

[mattcorey]

I questioned it myself, and re-tested before posting that, and found that '.minimal' effort does work with each of the gpt-5 models - the 'low' effort often takes ~5 seconds or so to 'think' with each response, while minimal is less than a second.

Not sure about just using "web_search" - is that a valid option? When I first worked with the Web Search tool, only 'web_search_preview' was available

[lzell]

Thank you for confirming the behavior @mattcorey

[joethephish]

GPT-5.1 has a new reasoning mode: none for low-latency interactions. By default, GPT-5.1 reasoning is set to none.

https://platform.openai.com/docs/guides/latest-model?reasoning-effort-mode=responses

It must be hard staying on top of the rate of change of these APIs! Makes me wonder whether it's worth AIProxy adding the ability to pass a dictionary of additional arbitrary key-values so that we can use new features immediately before they're added with explicit type in the AIProxy SDK?

[lzell]

@joethephish That's interesting and definitely possible. It couldn't hurt to open up such an interface.

The other angle is to make the lib easier to contribute to, so when someone needs a new reasoning level, for example, they can easily add the case to the enum in the right spot.

I think one way to do this is get rid of the concept of the "request body" entirely (or hide it), and instead have the various services define the full range of controls on there service methods. E.g.

openAIService.createChatCompletion(
   model: ...
   messages: ...
   frequencyPenalty: ...
   etc.
)

Maybe the one level of indirection is making folks less likely to dig in and add the new control they need? Thinking out loud. I have been surprised that folks seem reluctant to add the things they need. Maybe part of the problem is just not knowing how to contribute to a library or test the change?

The current README is gigantic, which works well for github's ToC search feature searching on a specific provider, but does make it a lot harder to find the 'how to contribute' section.

I also wonder how well known github's ToC search feature even is. It's so handy, but when I'm chatting with customers in the support chat I need to share how to use it.

[joethephish]

Oh wow, no, I'd never seen this ToC search on GitHub! That's pretty cool.

Yeah for me I hadn't even considered contributing to the library since I wouldn't know where to start, and I wouldn't want to risk forking it locally and deal with merges etc.

From my point of view, AIProxy works best when it feels like you're communicating directly with the model provider itself, so anything that can be done to reduce friction along the way the better: such as reducing the amount you have to learn about the wrapped API calls (I'd really rather not have to learn about AIProxy's implementation details... sorry!), and then waiting for updates to support new features from the model provider...