Skip to content

fix(openclaw): clamp GPT-5.4 output tokens - #986

Open
kywch wants to merge 3 commits into
mainfrom
fix/openclaw-gpt54-max-tokens
Open

fix(openclaw): clamp GPT-5.4 output tokens#986
kywch wants to merge 3 commits into
mainfrom
fix/openclaw-gpt54-max-tokens

Conversation

@kywch

@kywch kywch commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator

Summary

Clamp OpenClaw GPT-5.4 output tokens to the provider limit.

Root cause

OpenClaw sent max_tokens=171802 while GPT-5.4 accepts at most 128000. The ACP path uses internal alias benchflow-openai-gpt-5.4, so raw gpt-5.4 matching alone misses live requests.

Changes

  • Cap raw and ACP-alias GPT-5.4 IDs at 128000.
  • Replace missing, malformed, or oversized configured values.
  • Preserve explicit numeric values at or below the limit.

Scope

OpenClaw + GPT-5.4 only. No global model cap, routing change, or OpenClaw runtime-pin change. #977 is adjacent only.

Validation

  • 47 focused tests passed.
  • git diff --check passed.

@kywch
kywch deployed to pypi-internal-preview August 14, 2026 02:01 — with GitHub Actions Active
@kywch
kywch force-pushed the fix/openclaw-gpt54-max-tokens branch from 5f1efe1 to aab3705 Compare August 14, 2026 02:08
@kywch
kywch deployed to pypi-internal-preview August 14, 2026 02:08 — with GitHub Actions Active
@kywch
kywch force-pushed the fix/openclaw-gpt54-max-tokens branch from aab3705 to 3210f5c Compare August 14, 2026 02:08
@kywch
kywch deployed to pypi-internal-preview August 14, 2026 02:08 — with GitHub Actions Active
@kywch
kywch marked this pull request as ready for review August 14, 2026 02:26
@kywch
kywch deployed to pypi-internal-preview August 14, 2026 02:26 — with GitHub Actions Active
@Galius5136

Copy link
Copy Markdown

I think there is one proxy-alias path still uncovered here. I checked this on the current PR head. These two spellings resolve to the same upstream model (openai/gpt-5.4), but produce different proxy aliases: gpt-5.4 -> benchflow-gpt-5.4, while openai/gpt-5.4 -> benchflow-openai-gpt-5.4.

With the current _MODEL_MAX_TOKENS table, _default_max_tokens(safe_model_alias("gpt-5.4")) returns None, while _default_max_tokens(safe_model_alias("openai/gpt-5.4")) returns 128000. So if session/set_model receives the proxy alias derived from a bare --model gpt-5.4, the clamp is skipped even though both spellings resolve to the same openai/gpt-5.4 upstream model.

I also couldn't find a test exercising the new _default_max_tokens logic. A small regression test that derives the alias through safe_model_alias() for both spellings would pin this without hardcoding the alias-generation behavior.

@kywch
kywch deployed to pypi-internal-preview August 14, 2026 19:24 — with GitHub Actions Active
@kywch
kywch deployed to pypi-internal-preview August 14, 2026 19:32 — with GitHub Actions Active
@kywch

kywch commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator Author

@Galius5136 thanks for looking into it! I made it more general and added a small test.

@Galius5136

Copy link
Copy Markdown

@kywch confirmed, both spellings now hit the cap:

_default_max_tokens(safe_model_alias("gpt-5.4")) -> 128000

_default_max_tokens(safe_model_alias("openai/gpt-5.4")) -> 128000

The new parametrized test also fails on 3210f5c4 for the bare gpt-5.4 case and passes on def35f88, so it does pin the regression rather than just restating the fix.

Thanks for the quick turnaround!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants