[quickbeard]

What

In src/lib/model-limits.ts:

• adds zai-org/GLM-5.3-Flash at 262,144 tokens, the same window as MiniMax/MiniMax-M3
• removes zai-org/GLM-4.7-cc

The table now carries only the models whose window differs from the default.

Why

Without a table entry GLM-5.3-Flash resolved to DEFAULT_LIMITS (the safe 200K fallback), so every agent CoDev configures for it was told the wrong window — an understated context gauge and auto-compaction firing about 62K tokens early.

The GLM-4.7-cc entry's 200000 restated DEFAULT_WINDOW exactly, so removing it changes nothing: limitsFor returns the same { context: 200000, trigger: 180000 } through the default tier and all four writers emit identical config. The module's own comment already said an entry restating the default is one more thing to keep in sync.

One entry covers every command

install, config, model, and the launch-time key refresh all write through the four writers in configure.ts, and every one of them resolves its numbers from limitsFor — none holds a window constant of its own. So the table entry is the whole change; there is no per-command list of models to keep in sync.

What each agent ends up with for GLM-5.3-Flash:

agent	knob	value
Codex	model_context_window / model_auto_compact_token_limit	262144 / 235930
OpenCode + CoDev Code	limit.context / limit.input − global reserved	262144 / 222144 (declaredInput's clamp binds, as it does for M3)
Continue	contextLength / maxTokens	262144 / 65536
Claude Code	CLAUDE_CODE_AUTO_COMPACT_WINDOW / CLAUDE_AUTOCOMPACT_PCT_OVERRIDE	200000 / 80 — its own hard ceiling, unchanged and unchangeable

Assumption to confirm

The 262,144 window is taken from "configure it like MiniMax-M3" — M3 is capped there by the deployment's resources rather than by the model. If the gateway actually serves GLM-5.3-Flash with a different window, say so and I'll change the one number. Guessing too high is the direction that hurts (a session can run past the real ceiling and 400 mid-chat). It can also be overridden without a release: the moment an admin sets max_input_tokens on the model in LiteLLM, fetchModelWindows caches it in auth.json and the remote tier outranks this table.

Tests

Several tests used zai-org/GLM-4.7-cc as a stand-in for "a model on the 200K window". Each now uses DEFAULT_LIMITS or an unlisted id instead, so it still covers the default-window branch it was written for rather than silently retesting the table:

• model-limits.test.ts — the remote-tier and Claude-ceiling cases
• configure.test.ts — the Claude ceiling, the Codex per-model window, the OpenCode two-models-one-config trigger split, and the Continue per-model window

The Codex case also gained an unlisted-model assertion, so "pins each model's own window, not a shared constant" still exercises two different windows now that both table entries are 262144.

Also in here

AGENTS.md's "Context windows and auto-compaction" section still described the pre-#259 shape: explicit per-model triggers, an atob-encoded M3_ID, and DEFAULT_LIMITS at 200K/160K. It is the doc that tells the next person how to add a table entry, so it is corrected to the current shape (windows only, uniform 90% trigger, plain ids) and now says that the table has a twin in codev-code packages/codev-gateway/src/model-limits.ts that has to move with it.

Companion PR

quickbeard/codev-code#350 makes both changes to CoDev Code's own copy of the table (its gateway sign-in configures itself without going through the hub). Land both, or a model gets different windows depending on which flow wrote the config.

Testing

• pnpm typecheck — clean
• pnpm test — 76 files, 1432 pass / 2 skipped
• pnpm check — no fixes applied
• pnpm build && node dist/index.js --version — 0.5.19

🤖 Generated with Claude Code