What happens
Sessions on @cf/zai-org/glm-5.2 grow past the window the backend actually serves, then every turn fails. Gateway logs show a long run of rejections for one session, all on that model:
The estimated number of input and maximum output tokens (44xxxx) exceeded this model context window limit (262144)
Requested token count exceeds the model's maximum context length of 256000 tokens
MODEL_CONTEXT_WINDOW_OVERRIDES in packages/agent/src/gateway-models.ts declares the model at 1_000_000, and it is applied as Math.max(gatewayValue, override), so it also overrides what the gateway advertises. Nothing stops the transcript before the backend rejects it.
Why it is worse than a plain rejection
Once GLM rejects the turn, the SDK retries under FALLBACK_MODEL (claude-opus-4-8) with the same assembled body. That body was built for a non-thinking model, so it carries a clear_thinking_20251015 context-management edit with thinking off, which Anthropic hard-rejects:
API Error: 400 `clear_thinking_20251015` strategy requires `thinking` to be enabled or adaptive
That is the error the user actually sees, on every message, with no hint that the real problem is an oversized transcript. PostHog/posthog#73838 makes the gateway strip the orphaned edit so the fallback can succeed, but the session still should not have reached 400k+ tokens on a 256k model.
Suggested fix
Set the override to what the backend serves (or drop it and let the gateway's advertised value stand), and confirm the value used by the Modal-served GLM backend before picking a number. Worth checking separately whether the context window the harness reports actually gates compaction, or only the context meter - if it is only the meter, the overflow needs a different lever.
What happens
Sessions on
@cf/zai-org/glm-5.2grow past the window the backend actually serves, then every turn fails. Gateway logs show a long run of rejections for one session, all on that model:MODEL_CONTEXT_WINDOW_OVERRIDESinpackages/agent/src/gateway-models.tsdeclares the model at1_000_000, and it is applied asMath.max(gatewayValue, override), so it also overrides what the gateway advertises. Nothing stops the transcript before the backend rejects it.Why it is worse than a plain rejection
Once GLM rejects the turn, the SDK retries under
FALLBACK_MODEL(claude-opus-4-8) with the same assembled body. That body was built for a non-thinking model, so it carries aclear_thinking_20251015context-management edit with thinking off, which Anthropic hard-rejects:That is the error the user actually sees, on every message, with no hint that the real problem is an oversized transcript. PostHog/posthog#73838 makes the gateway strip the orphaned edit so the fallback can succeed, but the session still should not have reached 400k+ tokens on a 256k model.
Suggested fix
Set the override to what the backend serves (or drop it and let the gateway's advertised value stand), and confirm the value used by the Modal-served GLM backend before picking a number. Worth checking separately whether the context window the harness reports actually gates compaction, or only the context meter - if it is only the meter, the overflow needs a different lever.