4
1 Comment

AI APIs' signatures are total mess

For this project, I have to provide a visual UI for users to change settings before starting testing. I found there is no any consistency not only among different AI providers (like OpenAI, Anthropic, and others), but among the models of the same provider.

LLMKnights.com AI parameters window.

For example, many modern models by OpenAI don't allow the temperature setting (and it's a pity, I found it very useful), and if you accidentally pass it to the API request, it will fire the exception.

Another black hole is reasoning parameters. Some models support reasoning effort, some don't, and those that do, they all have different set of allowed values.

For example, GPT-5.6 Sol supports a bunch of values: none, low, medium, high, xhigh, and max. But o3-mini allows only low, medium, and high.

The same with reasoning mode.

But the main problem is there NO f**g documentation saying directly and explicitly which model supports which sets of parameters with which set of values.

This is what happened before I discovered all this mess:

LLMKnights.com The work in progress - API throws an exception because of passing a param that should not be passed.

I've found several publicly available JSONs describing models but they lack a lot of data.

posted toAvatar for product LLM Knights
LLM Knights
  1. 1

    This is painfully accurate. I ran into the exact same issue while building an AI-powered app - temperature randomly breaking, reasoning params varying between models, and zero clear docs on what actually works where.

    The worst part is you don't find out until runtime. Your app works perfectly with one model, then you switch to another and suddenly everything throws exceptions.

    I ended up building a small internal wrapper that normalizes these inconsistencies across OpenAI/Anthropic/Gemini/etc. It's been such a time-saver that we productized it as ModelBridge - one OpenAI-compatible API that handles the param mapping so you don't have to maintain a giant switch statement for every model.

    Not here to sell though - just saying I feel your pain. What's your use case? Are you building an app that needs to support multiple models, or are you mostly stuck on one provider?