openai-compatible adapter sends max_tokens to GPT-5/o-series reasoning models that require max_completion_tokens #25096

Summary

The bundled @ai-sdk/openai-compatible provider hardcodes max_tokens in chat-completions requests. OpenAI's reasoning-model family (GPT-5.x, o1, o3, o4) rejects this and demands max_completion_tokens instead. Result: any reasoning model behind an OpenAI-compatible proxy returns 503 BadRequest from the upstream API, but opencode swallows the error and the user sees a silent timeout / hung session.

Environment

• opencode 1.14.30 (curl install, macOS)
• Provider: OpenAI-compatible proxy (in our case "IU Unified Endpoint" exposing /openai/v1)
• Affected models tested: gpt-5-nano, gpt-5.4-mini, gpt-5.5, gpt-5.5-pro

Reproduce

~/.config/opencode/opencode.json:

{
  "provider": {
    "p": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://your-openai-compatible-proxy/openai/v1",
        "apiKey": "{env:API_KEY}"
      },
      "models": { "gpt-5.4-mini": {"name": "GPT-5.4 mini"} }
    }
  }
}

Run:

echo "Say HELLO" | opencode run --model p/gpt-5.4-mini --dangerously-skip-permissions

Result: hangs, no output. With --print-logs --log-level INFO you can see:

ERROR ... AI_APICallError ... statusCode=503 ...
"responseBody":"... Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead."

Workaround

Use the native @ai-sdk/openai adapter (which knows the reasoning-model param convention) instead of openai-compatible:

"p": {
  "npm": "@ai-sdk/openai",
  "options": {
    "baseURL": "https://your-openai-compatible-proxy/openai/v1",
    "apiKey": "{env:API_KEY}"
  },
  ...
}

This works perfectly for the same proxy + same models. So the proxy itself is fine; the problem is purely in how openai-compatible builds the request body.

Suggested fix

Two options:

1. Auto-detect reasoning models in openai-compatible by model-id prefix (gpt-5*, o1*, o3*, o4*) and switch the param to max_completion_tokens. Brittle but matches what @ai-sdk/openai already does.

2. Expose a per-provider config flag like "reasoning_models": ["gpt-5*"] or "max_tokens_param": "max_completion_tokens" so users can configure the proxy explicitly.

Option 1 is more "just works" for users; option 2 is more explicit. Maybe both — auto-detect with override.

Why this matters

Many corporate / EU proxies expose OpenAI's reasoning models through an openai-compatible gateway. As more providers ship reasoning-only models, this will affect more users. The silent-timeout failure mode is also rough: users have no idea why their agent is hanging until they enable debug logs.

Related

• Same silent-hang failure mode as OpenCode v1.0.25 Hangs Indefinitely with LM Studio + Qwen Models Due to Empty tool_calls Array #4255, opencode run hangs forever with OpenAI-compatible local provider (DMR + Qwen3) even though direct curl works #12893 (empty tool_calls: [] from openai-compatible proxies) — different cause, similar UX.

Happy to PR if there's preference on option 1 vs 2.