- Forward temperature and top_p through OpenAI-compatible chat and responses gateway paths.
- Return OpenAI-compatible 400 errors for invalid sampling params and provider validation failures instead of collapsing them to 500s.
- Add regression coverage and changelog credit.
Co-authored-by: lellansin <lellansin@gmail.com>
Summary:
- The branch adds Chat Completions token-cap fields to the Gateway request type, forwards them as agent stream parameters, and documents/tests the behavior.
- Reproducibility: yes. Source inspection gives a high-confidence current-main path: send `max_completion_toke ... tokens` to `/v1/chat/completions` and observe that the current handler never sets `streamParams.maxTokens`.
Automerge notes:
- PR branch already contained follow-up commit before automerge: fix(gateway): wire max_completion_tokens/max_tokens through openai-http
Validation:
- ClawSweeper review passed for head a9c39f7d4a.
- Required merge gates passed before the squash merge.
Prepared head SHA: a9c39f7d4a
Review: https://github.com/openclaw/openclaw/pull/81013#issuecomment-4430303959
Co-authored-by: Bingsen <dingheng.huang@urbanic.com>
Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com>
fix(gateway): remove unnecessary type assertion in buildAgentPrompt
fix(gateway): reject unsupported forced tool_choice modes
tool_choice=required and named function tool_choice are now rejected
with invalid_request_error until hard enforcement is implemented
at the agent runtime layer. Only auto and none remain supported.
docs: update Chat Completions tool_choice contract to match rejection behavior
Only auto and none are currently accepted; required and named
function tool_choice are rejected until hard enforcement exists.
* feat(gateway): add auth rate-limiting & brute-force protection
Add a per-IP sliding-window rate limiter to Gateway authentication
endpoints (HTTP, WebSocket upgrade, and WS message-level auth).
When gateway.auth.rateLimit is configured, failed auth attempts are
tracked per client IP. Once the threshold is exceeded within the
sliding window, further attempts are blocked with HTTP 429 + Retry-After
until the lockout period expires. Loopback addresses are exempt by
default so local CLI sessions are never locked out.
The limiter is only created when explicitly configured (undefined
otherwise), keeping the feature fully opt-in and backward-compatible.
* fix(gateway): isolate auth rate-limit scopes and normalize 429 responses
---------
Co-authored-by: buerbaumer <buerbaumer@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
