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

[winstern1998-commits]

Problem

The limit.context field for Zhipu GLM models is stored with an inconsistent radix across entries that represent the same documented context window.

Zhipu's official docs express context only as 1M / 200K / 128K (no precise integers), except glm-5.2's 1M which is decimal 1,000,000. The registry currently stores the same documented value two different ways:

Documented	Stored as (decimal)	Stored as (binary, ×1024)
200K	200000 (glm-5.1, glm-4.7-flash, glm-4.7-flashx, glm-5v-turbo)	204800 (glm-5, glm-4.6, glm-4.7)
128K	128000 (glm-4.6v)	131072 (glm-4.5 series)

Meanwhile limit.output is consistently binary (131072 / 98304 / 32768 / 16384), confirmed against Zhipu's official max_tokens table: https://docs.z.ai/guides/overview/concept-param

So context and output use different conventions, and context is internally inconsistent.

Impact

Any field derived from context inherits the ambiguity. In particular, limit.input = context - output (the convention used by the registry and by PR #3739 adding limit.input for GLM models) produces values that differ by 4800 (for the 200K group) or 3072 (for the 128K group) depending on which radix is "correct". Downstream tools computing thresholds against these limits get slightly different behavior per model with no clear ground truth.

Ask

Could maintainers confirm, against Zhipu's official spec, whether 200K / 128K context windows should be decimal (200000 / 128000) or binary (204800 / 131072), and normalize the zhipuai (and zai) entries accordingly? Once normalized, the limit.input values from #3739 can be recomputed if needed.

Also noticed

zhipuai/models/glm-4.6v-flash.toml is a broken symlink — it points to ../../zai/models/glm-4.6v-flash.toml, which does not exist in the repo. Pre-existing, unrelated to this issue, but flagging it here for cleanup.