Summary

Describe the problem and fix in 2–5 bullets:

• Problem: When using third-party OpenAI-compatible APIs (like Alibaba Cloud Bailian, DeepSeek, GLM, etc) with the openai-completions API type and compat.supportsTools: true, tool calling fails natively. The model receives an invalid payload and outputs raw Markdown blocks instead (e.g. bash exec --command...).
• Why it matters: This breaks proper tool execution and prevents agents from effectively completing actions when using perfectly capable, cheaper compatible LLMs.
• What changed:
  • Identified that the underlying @mariozechner/pi-ai library natively injects "strict": false into all tool schemas by default due to newer OpenAI API constraints.
  • Updated the normalizeModelCompat interceptor in src/agents/model-compat.ts to automatically default to supportsStrictMode: false for all non-native openai-completions endpoints.
  • Explicit configuration opt-ins (e.g. compat.supportsStrictMode: true) are now preserved, allowing an escape hatch for true API native proxies masquerading under vanity URLs.
  • Added unit tests in src/agents/model-compat.test.ts to assert that non-native proxies (like DashScope, proxy URLs, etc) natively drop the "strict" schema wrapper, while preserving explicit true overrides.
• What did NOT change (scope boundary): Native OpenAI and Azure API interactions remain completely unchanged. The @mariozechner/pi-ai upstream payload generator behavior remains unmodified.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes openai-completions API type does not support tool calling with third-party OpenAI-compatible APIs #41328
• Related PR fix: Disable strict mode tools for non-native openai-completions compatible APIs #41457

User-visible / Behavior Changes

Users configuring third-party OpenAI-compatible providers in their openclaw.json (such as DashScope, MoonShot, DeepSeek APIs) with compat.supportsTools: true will now see the models effectively utilizing configured agent tools correctly via the native tool_calls parameter finish reasons instead of plaintext.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux / macOS / Windows
• Runtime/container: Node.js 22.x+
• Model/provider: openai-completions via bailian (Alibaba DashScope) / qwen3-coder-plus
• Integration/channel (if any): Local OpenClaw CLI
• Relevant config (redacted): Base provider configured to hit https://coding.dashscope.aliyuncs.com/v1 with compat.supportsTools: true.

Steps

1. Configure an OpenAI-compatible provider targeting a third-party gateway with tools enabled.
2. Run an agent execution using tools, e.g., openclaw agent --agent main --local -m "Run echo test".
3. Inspect the streaming result behavior.

Expected

• The model issues a native tool_call chunk to securely invoke the system command instead of outputting markdown text.

Actual

• Prior to this PR, API providers rejected the LLM structure JSON payload due to the custom schema key (strict: false) sent by pi-ai and defaulted back to treating tools purely as string context.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

(Note: Unit assertions were added into src/agents/model-compat.test.ts successfully validating flag fallback propagation).

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Traced CLI output payload overrides on a local testing script bridging @mariozechner/pi-ai, demonstrating that omitting strict successfully forces the compatible API to accept tool mappings.
• Edge cases checked: Asserted that api.openai.com native domains maintain strict: false schema logic correctly. Explicitly verified that test cases asserting compat.supportsStrictMode: true overrides are correctly preserved.
• What you did not verify: Did not end-to-end execute LLM prompts against a live Bailian API key since I only tested the payload generation locally.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert this specific PR commit.
• Known bad symptoms reviewers should watch for: Native OpenAI structured outputs unexpectedly missing from core provider calls if the domain resolver intercepts it improperly (ex. custom enterprise vanity URLs acting directly as OpenAI).

Risks and Mitigations

• Risk: A consumer deploying a native Azure/OpenAI instance internally behind a custom Vanity URL might unexpectedly lose tool strict schema rendering if their baseUrl is unrecognized.
  • Mitigation: Users can explicitly provide "compat": { "supportsStrictMode": true } inside their custom configuration to force overrides back on. This PR explicitly implemented checking for this escape-hatch to make it safe.