fix(translator): emit max_completion_tokens for gpt-5/o-series in *-to-openai request builders

[AVK-Git-giddy]

Problem

OpenAI's Chat Completions API rejects max_tokens for gpt-5.x and hyphenated o-series models:

400 invalid_request_error / unsupported_parameter
"Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead."

The claude→openai request builder emits max_tokens unconditionally (open-sse/translator/request/claude-to-openai.js:22-24), and gemini→openai + antigravity→openai do the same. The GitHub executor already maps the param at its own layer (requiresMaxCompletionTokens, /gpt-5|o[134]-/i), but the native openai api-key provider goes through the default executor, which never touches token params — so every Claude-format request (Claude Code, etc.) routed to an openai/gpt-5.x model dies at the provider with the 400 above. We hit this in production routing Claude-format traffic to BYOK gpt-5 keys (observed live 2026-08-31).

Fix

• Hoist the exact match the GitHub executor uses into translator/formats/maxTokens.js as requiresMaxCompletionTokens, next to adjustMaxTokens.
• In the three *-to-openai request builders (claude-to-openai.js, gemini-to-openai.js, antigravity-to-openai.js), emit the adjusted budget as max_completion_tokens when the model matches, max_tokens otherwise.

Requests are born with the right param for every executor, and no downstream path regresses:

• executors/github.js maps only when transformed.max_tokens !== undefined → clean no-op on the new field.
• translator/request/openai-responses.js already prefers max_completion_tokens when mapping to max_output_tokens.
• executors/opencode.js normalizes either field to max_output_tokens; codex.js / grok-cli.js delete both; qoder.js reads both.
• handlers/chatCore/requestDetail.js OPTIONAL_PARAMS already lists both; nothing in open-sse/handlers/ reads .max_tokens post-translation.

The GitHub executor's private copy of the regex is left untouched to keep the diff minimal — happy to point it at the shared helper here if you prefer.

Tests

New tests/unit/to-openai-max-completion-tokens.test.js: the predicate plus each builder × (gpt-5.x, o3-mini, legacy gpt-4o) — 9/9 pass. The full tests/ suite has a byte-identical failure set with and without this change (the failures on a fresh clone of master are credential/environment-bound, none related).

Related

• Issues: OpenAI [400]: Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tok #560, Bug: max_tokens not supported for newer OpenAI models (gpt-5.4-nano, gpt-5.4-mini, etc.) #1745, [Docker] Bug max_token vs max_completion_tokens with openai #2830, Bug: max_tokens is incompatible with openai/gpt-5.4-mini #3587.
• Complementary to fix: translate max_tokens to max_completion_tokens for openai-compatible providers (closes #560) #664 / fix: rename max_tokens to max_completion_tokens for newer OpenAI models #1828 / fix: convert max_tokens to max_completion_tokens for gpt-5+ models (#1745) #2134 / fix(openai): support max_completion_tokens and forced streaming #3165, which add the mapping in executors/default.js. That layer is still the right place to catch passthrough OpenAI-format ingress (deliberately not touched here); this PR fixes translated ingress at the source so it holds for every executor.
• Deeper follow-up worth considering: for gpt-5.x, Chat Completions refuses requests combining function tools with reasoning_effort outright (OpenAI's error directs to /v1/responses). The native openai provider may want Responses-endpoint escalation the way executors/github.js already does it (supportsResponsesEndpoint + the openai-responses translators; cf. fix(openai): fallback to responses for gpt-5/codex #1797) — that would fix the whole class rather than one parameter name. Happy to open a separate issue with repro details if useful.

🤖 Generated with Claude Code