API 400 error on OpenAI-compatible providers caused by strict tool schema property

[myk1yt]

Problem (one or two sentences)

Users experience HTTP 400 errors when using OpenAI-compatible API providers (such as Upstage Solar, DeepSeek, or custom proxies) because Zoo Code automatically injects "strict": true into tool function definitions.

Context (who is affected and when)

This happens to anyone using a custom OpenAI-compatible provider (custom openAiBaseUrl) in Code mode when tools are enabled. Third-party providers that haven't implemented OpenAI's August 2024 Structured Outputs feature reject the request with:

"Invalid value: 'true'. The value 'true' isn't supported yet. For now, please use 'false' for this setting." (param: tools[0]. function.strict)   

Desired behavior (conceptual, not technical)

Zoo Code should handle tool definitions flexibly so that third-party OpenAI-compatible providers without Structured Outputs support can accept tool requests seamlessly without throwing HTTP 400 errors.

Constraints / preferences (optional)

Maintain full support for official OpenAI Structured Outputs when using official OpenAI models (api.openai.com), while gracefully omitting or setting "strict": false for third-party OpenAI-compatible endpoints.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

No response

Acceptance criteria (optional)

Given a user configured with a custom OpenAI-compatible provider (e.g. Upstage Solar)                                                
When the user sends a message in Code mode (with tools enabled)                                                                      
Then the API request should succeed with HTTP 200 OK                                                                                 
And tool function schemas should not force strict: true on unsupported providers                                                     
But official OpenAI endpoints should still retain full Structured Outputs functionality     

Proposed approach (optional)

In convertToolsForOpenAI, default strict to false or omit strict when target endpoint is a custom/third-party OpenAI-compatible provider, or make strict tool enforcement configurable per model/provider info.

Trade-offs / risks (optional)

None. According to official OpenAI specifications, the strict property is optional and defaults to false. Setting strict: false or omitting it for non-OpenAI endpoints carries zero risk and maximizes compatibility across all providers.