fix: Inconsistent radix for limit.context on Zhipu GLM models (200K stored as both 200000 and 204800)

[github-actions]

Summary

Normalized Zhipu/Z.AI GLM limit.context to the binary convention used by the platform’s own precise configs and max-token table.

Z.AI marketing docs say 200K / 128K, but first-party machine-readable values use 204800 and 131072 (and max_tokens is already binary: 131072 / 98304 / 32768). Several catalog entries already used binary; others used decimal. This aligns the remaining zhipuai / zai entries.

Changes

Model	limit.context old → new
glm-5.1	200000 / 200_000 → 204800 / 204_800
glm-5-turbo	200000 / 200_000 → 204800 / 204_800
glm-5v-turbo	200000 / 200_000 → 204800 / 204_800
glm-4.7-flash	200_000 → 204_800
glm-4.7-flashx	200_000 → 204_800
glm-4.6v	128000 / 128_000 → 131072 / 131_072

Unchanged (already binary / correct):

• glm-5, glm-4.7, glm-4.6 → 204800
• glm-4.5 series → 131072
• glm-5.2 → 1000000 (docs use decimal 1M / 1000000)
• limit.output values (already binary)

Files: models/zhipuai/* plus inline provider copies under providers/zai/ and providers/zhipuai/.
providers/zai models that only use base_model (glm-5.1, glm-5, glm-5.2) inherit the base-model fix.

Evidence

Claim	Source	What it establishes
200K context = 204800	docs.z.ai/devpack/using5.1	Official OpenClaw config uses "contextWindow": 204800 for glm-5.1, glm-5, glm-4.7
Output caps are binary	docs.z.ai concept-param	max_tokens table: 131072, 98304, 32768, 16384
Documented windows are 200K / 128K / 1M	glm-5.1, glm-4.7, glm-4.6v, glm-5.2	Marketing labels; radix taken from precise configs above
API enforces 204800	earendil-works/pi#3061 (fallback)	Live API error: "maximum context length is 204800 tokens"
128K siblings already binary	Existing catalog glm-4.5*	Already context = 131_072

Note: Cline setup text on the same docs page says “Set Context Window Size to 200000” — rounded UI guidance. Precise OpenClaw JSON uses 204800.

Validation

• Confirmed no remaining 200000 / 128000 context values under models/zhipuai, providers/zai, or providers/zhipuai.
• Did not run bun validate or live API tests.

Review notes

• Chose binary over decimal because official OpenClaw configs and the max_tokens table are binary, and the API error cites 204800.
• Did not change third-party hosts (Vercel, OpenRouter, etc.) — issue scoped to zhipuai / zai.
• Did not fix the broken glm-4.6v-flash symlink (flagged as pre-existing/unrelated).
• No limit.input fields present yet; nothing to recompute for that.

Closes #3738

Automated by the issue fixer: https://github.com/anomalyco/models.dev/actions/runs/30154315832

[rekram1-node]

/oc review this PR

[opencode-agent]

PR Review: fix Zhipu GLM limit.context radix (#3738)

Verdict: Approve — correct fix, well-scoped, evidence checks out.

What looks good

• Binary is the right call. Official OpenClaw config uses contextWindow: 204800 for glm-5.1 / glm-5 / glm-4.7 (docs.z.ai/devpack/using5.1). max_tokens table is already binary (131072 / 98304 / 32768). Cline’s 200000 is rounded UI guidance on the same page — correctly deprioritized.
• Coverage within scope is complete. No remaining 200000 / 128000 under models/zhipuai, providers/zai, or providers/zhipuai.
• Inheritance paths handled:
  • providers/zai glm-5.1 / glm-5 / glm-5.2 → base_model (inherit base fix)
  • Older providers/zhipuai/* → symlinks into providers/zai (pick up zai edits)
  • Real files providers/zhipuai/glm-5.1.toml + glm-5v-turbo.toml updated inline
• Top-of-file source comments match AGENTS.md (sync-safe).
• Per-file number style preserved (204_800 vs 204800).
• Intentionally left alone: glm-5.2 at 1_000_000, outputs, third-party hosts, broken glm-4.6v-flash symlink.

Suggestions (non-blocking)

1. Follow-up: Vercel still has decimal (providers/vercel/models/zai/glm-4.7.toml → 200_000, etc.). Fine for this issue’s scope; worth a separate pass if first-party should be the source of truth.
2. Weaker evidence for glm-4.6v → 131072: marketing only says 128K; no first-party machine value like the 204800 OpenClaw configs. Sibling glm-4.5* + binary max_tokens make it consistent, but it’s inference — fine to keep, just slightly softer than the 200K changes.
3. Process: PR notes bun validate wasn’t run; I couldn’t either (bun missing in this environment). Worth a CI green check before merge.

Not issues

• Full inline providers/zhipuai/glm-5.1.toml (vs base_model) is pre-existing drift, not introduced here.
• Broken glm-4.6v-flash symlink correctly deferred.

Ship it once CI/validate is green.

opencode session  |  github run