OpenAI-compatible GPT-5.x models still send max_tokens on AI SDK fallback path

Description

OpenAI-compatible providers can still send max_tokens for GPT-5-family models on the default AI SDK runtime path. OpenAI-compatible gateways that forward to OpenAI reject these requests with:

Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.

This blocks GPT-5.4 / GPT-5.5 usage through OpenAI-compatible providers even with a minimal opencode configuration and no MCP/tools/plugins enabled.

This looks related to prior max_tokens / max_completion_tokens issues, but the remaining failure path is specifically the default AI SDK fallback path for non-native providers.

Impact

• Affected: @ai-sdk/openai-compatible providers whose model id is in the GPT-5 family, e.g. gpt-5.4, gpt-5.5.
• Symptom: upstream 400 from OpenAI-compatible gateway.
• User-visible result: provider request fails before the model can answer.
• Severity: high for users routing GPT-5.x through LiteLLM / OpenAI-compatible gateways.

Minimal config shape

Sanitized example:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "proxy/gpt-5.5",
  "provider": {
    "proxy": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://example.invalid/v1",
        "apiKey": "REDACTED"
      },
      "models": {
        "gpt-5.5": {
          "name": "GPT-5.5",
          "id": "gpt-5.5",
          "tool_call": true,
          "modalities": { "input": ["text", "image"], "output": ["text"] },
          "limit": { "context": 1050000, "output": 128000 }
        }
      }
    }
  },
  "plugin": [],
  "mcp": {},
  "lsp": {},
  "skills": [],
  "permission": { "*": "deny" }
}

Reproduction

1. Configure an OpenAI-compatible provider that exposes gpt-5.5 or gpt-5.4.
2. Disable plugins/MCP/extra tools to rule out tool-count issues.
3. Start a session using proxy/gpt-5.5.
4. Send any prompt.

Actual result

The upstream gateway rejects the request:

{
  "error": {
    "code": "unsupported_parameter",
    "message": "Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.",
    "param": "max_tokens",
    "type": "invalid_request_error"
  }
}

Expected result

opencode should not send max_tokens for GPT-5-family models when using an OpenAI-compatible provider that forwards to OpenAI. It should either:

• use max_completion_tokens, if supported by the provider SDK path, or
• omit the max-output cap for those models on @ai-sdk/openai-compatible, letting the upstream model default apply.

Root cause hypothesis

The native LLM path can be patched independently, but this bug still appears when opencode falls back to AI SDK for non-native providers.

Relevant runtime path:

• packages/opencode/src/session/llm.ts logs/selects llm.runtime=ai-sdk for non-native providers.
• The AI SDK path calls streamText({ maxOutputTokens: prepared.params.maxOutputTokens, ... }).
• With @ai-sdk/openai-compatible, AI SDK serializes that as max_tokens.
• OpenAI GPT-5-family models reject max_tokens and require max_completion_tokens.

A local mitigation that fixed the issue was to clear maxOutputTokens during request preparation when:

model.api.npm === "@ai-sdk/openai-compatible"
&& /(?:^|\/)gpt-5(?:[.-]|$)/.test(model.api.id)
&& !model.api.id.includes("gpt-5-chat")

This prevents AI SDK from emitting max_tokens for GPT-5.x OpenAI-compatible routes.

Suggested regression coverage

A regression test can cover request preparation for an OpenAI-compatible gpt-5.5 model and assert:

prepared.params.maxOutputTokens === undefined

This catches the default AI SDK fallback path, which is distinct from native @opencode-ai/llm request body construction.

Privacy note

All provider URLs, API keys, local paths, account names, and logs in this report have been redacted or replaced with generic placeholders.