OpenAI Compatible: setting to disable strict tool schemas (strict: true rejected by strict-unaware proxies) #1827

Activity

1. airouter-dev commented on Sep 27, 2026

   

   airouter-dev

   on Sep 27, 2026

   More actions

   The important distinction here is between the OpenAI wire format and a gateway's structured-tool capability. I would make this a per-connection or per-model capability, rather than a global provider switch.

   A focused implementation/test contract could be:

   • Keep the current strict normalization as the default for OpenAI and strict-capable connections.
   • For an OpenAI-compatible connection with openAiStrictToolSchemas=false, preserve the declared required and additionalProperties fields and send strict: false (or omit the field if that is the gateway's accepted form).
   • Decide this from explicit connection/model configuration, not from the provider name. Two endpoints using the same OpenAI-compatible protocol can have different tool-schema behavior.
   • Cover both a root URL and a URL already ending in /v1; normalize once so the request path cannot become /v1/v1/chat/completions.
   • Add fixtures for strict success, a 400 caused by strict-schema rejection, optional-property preservation, MCP tools remaining non-strict, and a normal non-tool request. Redact keys and request content from diagnostics.

   For an optional external check of the ordinary OpenAI-compatible Chat Completions path, I operate AI Router with the API root https://api.ai-router.dev/v1. This should be treated only as an independent transport/control endpoint; the strict-tool behavior must be tested against the specific account-visible model and must not be assumed from the endpoint name.

   Disclosure: I represent AI Router. I am not requesting a provider-specific branch or default, and I have not verified that AI Router supports this issue's strict: true behavior.
2. easonLiangWorldedtech commented on Sep 27, 2026

   

   easonLiangWorldedtech

   on Sep 27, 2026

   ContributorAuthor

   More actions

   Thanks for the detailed review — most of the contract matches what the fix for this issue implements:

   • Per-connection scope: openAiStrictToolSchemas lives on the OpenAI Compatible connection's own settings (the same configuration that holds the base URL and API key). It is an explicit per-connection value, never inferred from the provider name or the endpoint, and it does not affect any other provider (openai-native, openai-codex, xai, ...). Two endpoints speaking the same OpenAI-compatible protocol can behave differently by configuring the flag independently per connection.
   • Behavior when disabled: with openAiStrictToolSchemas: false, each tool is sent with strict: false and the declared JSON schema passes through untouched — declared required and additionalProperties preserved, no normalization applied. This mirrors the existing precedent for MCP tools. An explicit strict: false is sent rather than omitting the field, since the Chat Completions API accepts both and the explicit form is easier to reason about.
   • Base URL / /v1: the handler passes the configured base URL straight to the OpenAI SDK, which owns request-path joining; the strict flag is orthogonal to the request path, so no /v1/v1/chat/completions doubling is introduced. Base-URL handling already has existing coverage (e.g. the Azure OpenAI base-URL normalization tests).
   • Test contract: the implementation adds fixtures for the strict default (normalized schema on the wire), strict disabled with the declared schema preserved (including optional properties), MCP tools remaining non-strict, a gateway 400 caused by strict-schema rejection propagating with its status preserved, and a normal non-tool request that carries no tools. Error diagnostics are unchanged by this work, so nothing new leaks keys or request content.

   Disclosure noted — thank you for flagging it. No AI-Router-specific branch, default, or endpoint handling goes into this change. https://api.ai-router.dev/v1 can be used to manually verify the ordinary Chat Completions transport path; since strict-tool behavior is account/model-visible, any such check is transport verification only and is not assumed from the endpoint name.
3. edelauna

   closed this as completedin #1828on Oct 7, 2026
4. easonLiangWorldedtech

   added a commit that references this issue on Oct 7, 2026

   fix(api): add openAiStrictToolSchemas setting for OpenAI-compatible g…

   ...

   2baac5e