[Bug]: MiniMax "context window exceeds limit (2013)" is terminal on the app runtime — a 92%-full session is bricked, the context_overflow recovery never runs

Start by reading packages/shared/src/llm-error-classifier.ts and the context overflow recovery work in PR #460. Trace where the app runtime builds provider requests and registers contextOverflowRecoveryHook, then compare that path with the CLI/TUI recovery path. Confirm whether the checkpoint request sets max_tokens and whether one forced compaction and resend occur; done means the app session recovers from this rejection or reports a specific remaining failure.

Product or interface

App / mobile client (session metadata reports device_platform: "app"). The bug-report template has no "Mobile app" option, so this is filed under the closest one — please re-tag if it belongs to the desktop app runtime instead.

The symptom is a message-classification / request-construction path, so it should be platform-independent.

Version

• Latest public release at the time of the report: MiniMax Code v0.6.5 (2026-10-09), with main as of 2026-10-21 (i.e. after feat(config): promote M3.1 Flash to the default delivered model (#509)).
• Model in use: MiniMax-M3.1-Flash, variant=thinking, thinking.effort=max.
• The app/daemon runtime that serves these sessions is not part of the public tree, so the exact client build could not be confirmed from the reporter side. It can be supplied on request.

Platform

Not platform-specific (see above) — the failure is in shared request/response handling.

OS version and architecture

Not collected. The report was produced from the client side without access to the host OS metadata; happy to fill in.

Issue area

Agent stuck / slow / repeated loop

Steps to reproduce

1. Use an agent session that has accumulated a large context. In the observed case the session was at 920,573 tokens against a 1,000,000-token context limit (92% occupancy) after a long working session, and the last successful turn completed normally at 14:14:15 local time.
2. Let the session go idle, then send any new message from the app.
3. The turn fails immediately, before any model output, with:

[Error] 400 {"type":"error","error":{"type":"invalid_request_error","message":"invalid params, context window exceeds limit (2013)"},"request_id":"072b8a3180d55889c08e390552667f83"}

4. Send again — a second, different request_id, same error shape. This repeats for every subsequent message, including plain short text with no attachment. Ten consecutive failures over 1 h 38 min, from 14:14 to 15:52.
5. The session cannot be recovered. There is no retry, resend or compaction path that works from the client.

Expected and actual behavior

Expected. Per PR #460, a context_overflow rejection is a deterministic, non-retryable upstream rejection, and PiTurnHooks.contextOverflowRecoveryHook should then run one forced compaction and resend once — only if that resend also fails is the original error surfaced. A session at 92% of a 1M window should be compacted and recover, not bricked.

Actual. The rejection is terminal and permanent. Every subsequent request fails identically, and the session is unusable.

Redacted error summary

HTTP 400 invalid_request_error
invalid params, context window exceeds limit (2013)
model:       MiniMax-M3.1-Flash (thinking, effort=max)
session context_limit:        1,000,000
session context at last OK:     920,573 tokens (92%)
last successful turn:       finish_reason=stop, 2026-10-24 14:14:15
failures:                  10 consecutive, 14:14 -> 15:52
usage on every failure:    total_tokens=0, context_window=1000000

All ten request_ids, in order:

072b85f5e1e8e03574a2c32d1d0a0271
072b861530e3205e9698fdc782d26fd4
072b884f028475eea3a62e25f937c3a8
072b88620972fe5ba1ac8204d1cc3f80
072b8889ab0043db99982a5f2e920361
072b8a3180d55889c08e390552667f83
072b8ce4c2abac8328ce5907a6e6c779
072b8ced715583b847876b78b9e9795b
072b9312435caabe55bf92d6acc7a25a
072b9ce121862ce841c5fcdadb1fa9ff

Additional observations

1. The error string is already recognised by the shared classifier. packages/shared/src/llm-error-classifier.ts defines LLM_CONTEXT_OVERFLOW_MESSAGE_RE with \bcontext window exceeds limit\b, and the comment directly above it quotes this exact payload: "MiniMax reports it as invalid params, context window exceeds limit (2013), so the bare 2013 code (a generic invalid-params code) is not used." So this rejection is classified as context_overflow and, per #460, should be a single deterministic attempt followed by one compaction-and-resend — not a hard stop.

2. The reported number 2013 does not correspond to the real overflow. The session was at 920,573 / 1,000,000 tokens, so a genuine overflow would be reported as a six-digit figure. 2013 is a small constant that stayed identical across all ten requests — including requests with an image attachment and requests with a four-character plain-text message. A constant small limit across wildly different payloads points at a fixed max_tokens being validated as a context window, not at the real context size.

   • 2013 = 2048 - 35, and 2048 is the Anthropic SDK's default max_tokens. MiniMax's Anthropic-compatible endpoint appears to validate max_tokens as if it were the context window, so a request that inherits the SDK default gets rejected with "only ~2K tokens of input allowed", no matter how large the real context is.

3. The failure appears only above a context threshold. Every request in the same session succeeded up to 92% occupancy and failed from there on — which is consistent with the automatic-compaction path taking over near the window limit. That path issues a checkpoint request ("summarize the preceding conversation") before the real turn, and if that checkpoint request inherits the default max_tokens, it is rejected before the turn can even start.

   • This looks closely related to #514 ("mcode exec fails with limit_exceeded (exit 7) when auto-compaction runs, because the checkpoint consumes --max-steps"), where the first provider request of a turn is the checkpoint. The difference there is the CLI reporting a step-limit error; here the app surfaces the raw upstream 400 and never recovers.

4. The recovery hook does not appear to run. #460 caps the recovery compaction at "50% of the rejected request's measured tokens/bytes, because the estimate had admitted a request the provider rejected." If the app runtime's local context estimate is missing or measured differently (e.g. not accounting for tool-result payloads and cached prefixes the way local-runtime-v2 does), the forced compaction may not shrink the request below the provider's real limit, the resend fails with an identical error, and per #460 the original error is surfaced — exactly what was observed.
   → Question for the maintainers: does the app runtime register contextOverflowRecoveryHook at all? If it does not, a context_overflow rejection is unrecoverable there while the CLI/TUI path recovers.

5. The user messages are persisted, but the replies are not. Each failed turn is stored with an incrementing admission_index (30 → 37) and the error text is stored as an assistant message with finish_reason=error; every failed request reports usage.total_tokens = 0, i.e. the request never ran. The session is left in a state where the user keeps re-sending the same message (four identical retries with "怎么样了") and nothing can clear it.

Screenshots

None — the error is surfaced as raw terminal-rendered text in the client.

Before submitting

• I have searched existing issues.
• I have included my version and removed sensitive information.