openclaw - 💡(How to fix) Fix [Bug]: /v1/chat/completions silently drops max_completion_tokens and max_tokens from inbound request body [1 pull requests]

Summary

The Gateway's inbound OpenAI-compatible Chat Completions endpoint (src/gateway/openai-http.ts, served at /v1/chat/completions) silently drops both max_completion_tokens (OpenAI's current Chat Completions field) and the legacy max_tokens from the request body. Neither value reaches streamParams.maxTokens, so clients that set an explicit per-call cap get the model's full default (model.maxTokens from the catalog) instead.

Reproduce

Against an enabled /v1/chat/completions:

curl -sS http://127.0.0.1:18789/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "openclaw/default",
    "max_completion_tokens": 32,
    "messages": [{"role":"user","content":"count to 100 with explanations"}]
  }'

Expected: the upstream response is capped at 32 completion tokens. Actual: the cap is ignored; the response runs to the model's full default budget.

Same result with max_tokens: 32.

Root cause

coerceRequest() and the request handler in src/gateway/openai-http.ts never read max_completion_tokens or max_tokens from the payload, and buildAgentCommandInput() does not accept a streamParams parameter. The commandInput passed to agentCommandFromIngress therefore omits streamParams, and the transport falls back to model.maxTokens.

Why this is asymmetric with the rest of the stack

• The sibling Responses endpoint already wires the equivalent field correctly: src/gateway/openresponses-http.ts:676-679 parses max_output_tokens into { maxTokens } and forwards it as streamParams.
• Downstream provider transports are already protocol-aware:
  • src/agents/openai-completions-compat.ts:70-87 decides maxTokensField (max_tokens for Mistral/Chutes, max_completion_tokens otherwise) per upstream provider family.
  • src/agents/openai-transport-stream.ts:2338-2345 reads options.maxTokens and emits the correct field name on the wire.

So the gap is only at the inbound parsing/wiring layer of /v1/chat/completions. Once streamParams.maxTokens is populated, the rest of the stack handles the wire field name translation correctly.

Notes on related closed issues

Closed issues #62130, #49173, and #71045 all addressed the outbound direction (OpenClaw → upstream provider). None of them cover the inbound Gateway endpoint silently dropping the client-supplied cap.

Proposed fix

Mirror the Responses endpoint pattern in openai-http.ts:

• Accept both max_completion_tokens and max_tokens from the inbound body (max_completion_tokens wins when both are present, matching OpenAI's current Chat Completions guidance).
• Build streamParams: { maxTokens } when either field is set.
• Thread streamParams through buildAgentCommandInput() into the agentCommandFromIngress call.
• Update docs/gateway/openai-http-api.md to document both fields.

Environment

• Branch: main at d6e63ee3b2 (2026-05-12)
• Surface: /v1/chat/completions (gateway.http.endpoints.chatCompletions.enabled: true)