Context window detection fails for third-party Anthropic-compatible providers

Status Closed — not planned

Maintainer reply None cached

Activity 11 comments · opened Apr 10, 2026 · closed May 31, 2026

When using a third-party provider that implements the Anthropic API (e.g., MiniMax via https://api.minimax.io/anthropic), Claude Code's context window detection falls back to the hardcoded default of 200,000 tokens, even when the underlying model may support a larger context window.

Root Cause

In src/utils/context.ts, getContextWindowForModel() calls getModelCapability() to retrieve max_input_tokens from a cached capability list. However, getModelCapability() is gated by isFirstPartyAnthropicBaseUrl() in src/utils/model/modelCapabilities.ts:46-51:

function isModelCapabilitiesEligible(): boolean {
  if (process.env.USER_TYPE !== 'ant') return false
  if (getAPIProvider() !== 'firstParty') return false
  if (!isFirstPartyAnthropicBaseUrl()) return false  // ← MiniMax fails here
  return true
}

Since MiniMax's base URL is https://api.minimax.io/anthropic (not api.anthropic.com), isFirstPartyAnthropicBaseUrl() returns false, and getModelCapability() returns undefined. This causes getContextWindowForModel() to fall through to MODEL_CONTEXT_WINDOW_DEFAULT = 200_000.

Impact

AutoCompact triggers too aggressively: With a 200K assumed window, AutoCompact threshold is 200,000 - 13,000 = 187,000 (93.5%). If MiniMax actually supports 1M, this is ~19% into the real window.
Users hit context limits unexpectedly: The tool estimates the context is at 93.5% when it may actually be at only 18.7% for a 1M-capable model served through MiniMax.
Manual /compact becomes necessary: Users report needing to run /compact manually when the auto-compact warning should have fired much earlier (or not at all).

Reproduction Steps

Set ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
Set ANTHROPIC_AUTH_TOKEN=<MiniMax token>
Set ANTHROPIC_MODEL=MiniMax-M2.7 (or any model served through MiniMax)
Observe that getContextWindowForModel("MiniMax-M2.7") returns 200000 regardless of the model's actual capabilities
Note that AutoCompact warning fires at ~187K tokens (based on 200K window) rather than at a proportional threshold for the actual window

Expected Behavior

Claude Code should either:

Detect actual context window for third-party providers (if the provider exposes model capabilities via their own endpoints)
Allow manual override via environment variable (CLAUDE_CODE_MAX_CONTEXT_TOKENS) or model configuration
At minimum, not assume the smallest possible window for unknown third-party providers — use a conservative estimate or probe the actual limit

Proposed Fix

Option A: Extend capability detection to third-party providers (medium effort)

Add a getThirdPartyModelCapability() path that tries to fetch from the provider's model list endpoint, or maintain a local override map for known MiniMax/Gateway models.

Option B: Environment variable override for specific models (simple, immediate)

Add support for per-model context window overrides in CLAUDE_CODE_MAX_CONTEXT_TOKENS:

CLAUDE_CODE_MAX_CONTEXT_TOKENS="MiniMax-M2.7:1000000,claude-opus-4-6:1000000"

Option C: Probe actual context limit on first use (most robust)

On the first API call with a new model, detect 413 Payload Too Large and learn the actual limit, persisting it locally. Already done for team memory (src/services/teamMemorySync/index.ts:529), could be generalized.

Workaround

Set CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000 in environment to override the auto-detected window for all models.

Additional Context

AutoCompact already has a circuit breaker (3 consecutive failures) to prevent hammering the API when context is irrecoverably over the limit (src/services/compact/autoCompact.ts:70)
The 200K default is documented at src/utils/context.ts:9 as a comment but may not reflect actual provider capabilities
This issue affects any Anthropic-compatible third-party API (Azure, AWS Bedrock, Vertex, MiniMax, OpenRouter, etc.) where the provider URL doesn't match api.anthropic.com

View original on GitHub ↗

11 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Fearvox · 4 months ago

Additional Context for Triage

Affected providers: MiniMax (via https://api.minimax.io/anthropic), likely also affected for Azure, AWS Bedrock, Vertex, OpenRouter, and other Anthropic-compatible third-party APIs.

User config that triggers this:

ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
ANTHROPIC_AUTH_TOKEN=<MiniMax token>
ANTHROPIC_MODEL=MiniMax-M2.7

Symptoms reported by users:

Auto-compact fires at ~187K tokens (93.5% of assumed 200K window) even when the session is only ~20% of actual capacity
Users must manually run /compact when the automatic system should have handled it
Session appears healthy in Claude Code UI but the API rejects with 413/400 when context is truly near limit

Technical notes:

The gate in src/utils/model/modelCapabilities.ts:46-51 (isModelCapabilitiesEligible()) intentionally restricts capability detection to first-party only — this is a design choice, not a bug — but it means third-party providers get the conservative 200K floor regardless of actual model support
AutoCompact threshold calculation: effectiveContextWindow - 13,000 tokens (src/services/compact/autoCompact.ts:75-76)
For a model that actually supports 1M context served through MiniMax, the AutoCompact fires at 187K (19% of real capacity), wasting significant context budget

Suggested labels: area:providers, area:core, enhancement, provider:minimax

Priority consideration: This affects any multi-provider setup where models are routed through non-Anthropic endpoints. As more third-party providers support Claude models (Azure, AWS, Google Cloud), this becomes a broader issue.

Fearvox · 4 months ago

Not a duplicate of the linked issues.

The linked issues cover:

#29015: Fast mode disabled with custom ANTHROPIC_BASE_URL — unrelated symptom
#32378: ToolSearch disabled with custom base URL — same root cause as #29015, closed
#35214: has1mContext() doesn't match canonical model IDs from API response

Our issue adds a distinct problem that the existing issues don't cover:

Third-party providers (MiniMax, Azure, Bedrock, Vertex, OpenRouter) are gated out at a higher level — isModelCapabilitiesEligible() in modelCapabilities.ts:46-51 returns false for any non-api.anthropic.com URL, so even if has1mContext() were fixed, third-party providers would still get the 200K default because getModelCapability() is never called for them.

The fixes needed are different:

#35214's fix (matching canonical model IDs in has1mContext()) helps first-party API responses
Our issue requires extending capability detection to third-party providers — separate work

Please reopen or acknowledge as a separate tracking issue.

pavel-kalmykov · 4 months ago

Same problem here with DeepSeek V4 (deepseek-v4-pro and deepseek-v4-flash), which advertise a 1M context window in the official docs: https://api-docs.deepseek.com/news/news260424.

Repro:

export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
export ANTHROPIC_AUTH_TOKEN="$DEEPSEEK_API_KEY"
claude --model deepseek-v4-pro

Claude Code reports 200K in both the status bar and /context, and AutoCompact fires at the ~187K mark even though there's another ~800K of headroom on the provider side. Same root cause flagged in the OP for MiniMax: isFirstPartyAnthropicBaseUrl() returns false for api.deepseek.com so getModelCapability() falls through to the 200K default.

Adding DeepSeek as a second data point in case it helps.

zahidzorbaz · 4 months ago

Adding a third data point — and an inverse manifestation of the same root cause.

Setup

vLLM serving \RedHatAI/Qwen3.6-35B-A3B-NVFP4\ with a 256K context window (\max_model_len: 262144\ from \/v1/models\)
Anthropic-compatible proxy in front of vLLM
Env:

\\\ANTHROPIC_BASE_URL=http://<lan-host>:8000 ANTHROPIC_API_KEY=<dummy> ANTHROPIC_DEFAULT_SONNET_MODEL=RedHatAI/Qwen3.6-35B-A3B-NVFP4 ANTHROPIC_DEFAULT_OPUS_MODEL=RedHatAI/Qwen3.6-35B-A3B-NVFP4 ANTHROPIC_DEFAULT_HAIKU_MODEL=RedHatAI/Qwen3.6-35B-A3B-NVFP4 \\\

Symptom
Claude Code's status line reports a 1M context window — the underlying model only supports 256K. This is the inverse direction from the MiniMax / DeepSeek reports above (where Claude Code under-reports), but the root cause is the same: \isModelCapabilitiesEligible()\ returning false for non-\api.anthropic.com\ base URLs causes capability detection to fall through to a default that doesn't match reality.

Why the over-detection direction also hurts

Auto-compact never fires in time — Claude Code's ~80% threshold lands at ~800K, far past the real 256K limit
The session looks healthy in the UI right up until the proxy returns \context_length_exceeded\ and breaks the flow with a hard error, no soft warning
Manually running \/compact\ is the only safety net, but users have to guess the real budget

Reinforcing the prior request: a generic override would fix both directions
Three concrete proposals (any one of these unblocks local-LLM workflows):

Env: \ANTHROPIC_CONTEXT_WINDOW=262144\
Settings: \models.<id>.contextWindow\ field in \~/.claude/settings.json\
Read \max_model_len\ from the proxy's \/v1/models\ response when available

As local-LLM-via-router (vLLM, Ollama, llama.cpp) becomes a more common Claude Code setup, the lack of any override mechanism is a real friction point — the workaround today is "ignore the bar and \/compact\ by feel," which negates a lot of Claude Code's session-management value.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

allenjack · 2 months ago

Hi guys,

I met the same problem: my Minimax M3 model only has a 200k context window. After adding a '[1m]' suffix to the model configuration, the problem may be fixed:

cmpute · 2 months ago

@allenjack Could you share which version of cc you are using? I'm not able to get it work even with a [1m] suffix

allenjack · 2 months ago

@allenjack Could you share which version of cc you are using? I'm not able to get it work even with a [1m] suffix

Hi @cmpute , I am using the CC Switch, and my CC version is 2.1.160 (Claude Code).

Fearvox · 2 months ago

> @allenjack Could you share which version of cc you are using? I'm not able to get it work even with a [1m] suffix Hi @cmpute , I am using the CC Switch, and my CC version is 2.1.160 (Claude Code).

GOATED CHOICE

github-actions[bot] · 19 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.