[ACP] Context-overflow 401 ("supports only 256K context") is misreported as "Authentication required" (-32000) when auto-compaction exceeds a 256K model's window

[bowser-bot]

What version of Kimi Code is running?

0.32.0

Which open platform/subscription were you using?

Kimi For Coding (managed subscription, api.kimi.com/coding/v1)

Which model were you using?

kimi-code/k3-256k (the same session works fine on kimi-code/k3)

What platform is your computer?

Linux 6.8.0-124-generic x86_64 x86_64

What issue are you seeing?

When a session whose context has grown past 256K tokens is switched to a 256K-window model (kimi-code/k3-256k) and prompted over ACP, session/prompt fails with:

{ "code": -32000, "message": "Authentication required", "data": null }

The kimi-code log for the same session records the real server error:

ERROR compaction failed
  KimiError: 401 k3-256k supports only 256K context.

The managed provider intentionally returns HTTP 401 for plan/capability errors (per the official error reference), and the response body clearly states this is a context-window limitation. But the client classifies every 401 as an auth failure, so ACP clients receive Authentication required and cannot distinguish a real auth problem from context overflow. A headless ACP client that retries and surfaces "please re-login" is actively misleading here — no amount of re-authentication can fix an over-long context.

Failure chain:

1. Session context grows past 256K (observed ~322K tokens, inputCacheRead: 321792).
2. After switching the session to kimi-code/k3-256k, the next prompt triggers auto full-compaction (full_compaction.begin source=auto).
3. The compaction request itself sends the whole ~322K context to the 256K-window model → the server rejects it with 401 k3-256k supports only 256K context. → full_compaction.cancel.
4. session/prompt rejects with -32000 Authentication required.

Code pointers (current main, commit 98ee35afd24f327af6faa762383461ae337da183):

• packages/agent-core-v2/src/kosong/contract/errors.ts:403 — isContextOverflowStatusError only accepts status 400/413/422, so a 401 can never be classified as context overflow; the CONTEXT_OVERFLOW_MESSAGE_PATTERNS (same file, L291-300) also do not match the "supports only N context" wording.
• classifyApiError (same file, L524) then falls through to 401/403 → auth; the v1 path packages/agent-core/src/errors/serialize.ts:89 likewise maps any 401 to provider.auth_error.
• packages/agent-core-v2/src/kosong/model/modelRequesterImpl.ts:213 and packages/node-sdk/src/kimi-code-model-provider.ts:113 treat any 401 as a token problem and force a token-refresh retry; after the second 401 they throw auth.login_required ("OAuth token was rejected after refresh. Run /login to re-authenticate.") — misleading for a context-size rejection.
• packages/acp-adapter/src/session.ts:1638 (isAuthErrorCode) + mapPromptError (L1595) then map those codes to RequestError.authRequired() with no message attached, so the server's original text is discarded before it reaches the ACP client.

What steps can reproduce the bug?

1. Build up a session beyond 256K tokens of context (any long coding session; context usage > 262144).
2. Over ACP: resume that session, session/set_model → kimi-code/k3-256k, then send any session/prompt.
3. session/prompt returns { code: -32000, message: "Authentication required" }; the kimi-code log shows KimiError: 401 k3-256k supports only 256K context.

Control experiments (same machine, same credentials):

• Same session resumed with kimi-code/k3 (1M window) → prompt succeeds.
• Fresh session with kimi-code/k3-256k → prompt succeeds.

So the token, quota, and model entitlement are all fine; the failure is purely context size × model window, mislabeled as auth.

What is the expected behavior?

• Classify 401s by response body: a "supports only N context" / context-size message should surface as a context-overflow error (e.g. context.overflow / APIContextOverflowError), not as an auth error — and should not trigger a pointless token-refresh retry.
• Preserve the server's original message in the ACP error (e.g. attach it via RequestError.authRequired(undefined, message) or a dedicated error code), so clients can act on it.
• Optionally, fail fast with an actionable error: session/set_model could compare the session's current context tokens against the target model's maxContextSize; and full-compaction whose input already exceeds the target model's window is doomed by construction — chunk the compaction input or tell the user to switch to a larger-window model / start a new session.

Additional information

Closest existing issues are #794 (different compaction failure path), #1330 (API-key auth gate), and #2325 (openai_responses compaction loop) — none cover this 401-misclassification. Happy to submit a focused PR for the classification fix if maintainers agree on the intended mapping.

[bowser-bot]

Downstream Multica mitigation PR: multica-ai/multica#6395

It preserves the provider's context-limit detail when ACP returns the opaque Authentication required error, maps the failure to context overflow ahead of generic HTTP 401 authentication handling, and keeps genuine authentication failures unchanged. The upstream fix is still valuable because downstream recovery necessarily depends on stderr evidence.