Skip to content

HTTP 401 exceeding the 256K context limit - CC Switch & Codex

Quick fix

Lower the AUTO COMPACT trigger threshold in the Codex config.toml so the real token count of the request body stays under the Kimi 256K limit.

Error output
unexpected status 401 Unauthorized: CC Switch local proxy failed while handling Codex endpoint /responses. Provider: Kimi; model: kimi-k2.7-code; upstream_status: HTTP 401; cause: k3-256k supports only 256K context., url: http://127.0.0.1:15721/v1/responses

When Codex detects the context approaching the window limit (usually 90%-95%), it sends a compaction request automatically to the /responses/compact interface. In cc-switch 3.18.0, however, that request passes straight through to the upstream Kimi /chat/completions interface, which does not support context compaction. Once the real token count in the request body (system prompt, tool definitions, MCP schema, reconstructed history, and so on) exceeds the 256K limit of your Kimi plan, the upstream returns HTTP 401 outright. Note also that the usage percentage the Codex UI shows is only an estimate of the visible context in the current session — the actual network request is often larger, so the compaction never kicks in soon enough.

  1. Open the Codex config file, find the automatic compaction settings, and lower the trigger threshold.

    config.toml
    auto_compact_threshold = 200000
  2. Check the cc-switch routing configuration and confirm the model name mapped to Kimi is the standard k3 or k3-coding 256K tier, not an alias that triggers the 1M limit.

  3. If you have MCP tools or session history sync enabled, turn off the non-essential tools temporarily or test in a fresh empty session, to rule out extra fields pushing you over the token limit.

  4. Check the cc-switch proxy log, compare the model field and the request body size actually sent upstream, and verify the effect of your adjustment.

ToolCodex
Version3.18.0
PlatformsWindows
Why does it return 401 when the UI shows only 23% used?
The UI counts only the text tokens of the current conversation window, while the request actually sent upstream also carries the system/developer prompt, tool definitions, MCP schema, reasoning fields, and reconstructed history. Those hidden costs consume the budget fast, so the real request is far larger than the UI figure.
Why does cc-switch not handle the compact request itself?
The current version has no built-in local parsing and compaction logic for /responses/compact, so it forwards it to the upstream LLM as a standard chat request by default. The upstream interface does not support the operation and is bounded by your plan context limit, so it rejects it with a 401.
Would upgrading the Kimi plan to 1M resolve it?
It routes around the error but does not fix the root cause. Lowering the Codex automatic compaction threshold to fit your current 256K plan is the better first move — it saves money and keeps requests stable.

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.