Repository navigation
[Bug]: Claude custom/local models get no context window, so the context meter ring stays empty #26476
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Configure a Claude provider instance with a custom model through an Anthropic-compatible proxy — e.g. CLIProxyAPI, which backs the endpoint with OpenAI-style
chat/completionsupstreams that carry no context-window metadata (custom model entry in the instance'scustomModels, e.g. a slug likeGLM-5.3-Flash, envANTHROPIC_BASE_URL+ANTHROPIC_MODEL). - Optionally set
CLAUDE_CODE_MAX_CONTEXT_TOKENSon the instance — it makes no difference. - Send a prompt on a thread using that custom model, with the context window indicator enabled (Settings → General → Legacy features).
- Hover the indicator, and inspect the provider turn in
statev2.sqlite.
Expected behavior
The indicator ring fills proportionally to context usage. The provider turn's tokenUsage.maxTokens reflects the model's context window.
Actual behavior
The hover popover shows the token count but the ring never fills, because tokenUsage.maxTokens is null for every turn: the popover's usedPercentage needs maxTokens (ContextWindowMeter.tsx:30-33), and it stays empty at full strokeDashoffset without it. On my install, 181 of 181 recent claudeAgent turns have maxTokens: null while codex, opencode and pi turns all carry a real window.
The server resolves the Claude context window only from the bundled model catalog (ClaudeAdapterV2.ts:204-207, claudeContextWindow() → resolveClaudeCatalogContextWindowTokens(BUNDLED_CLAUDE_MODEL_CATALOG, …) ?? null). Custom model entries enter the catalog with an empty runtime (ClaudeModelCatalog.ts:99-113), so the lookup misses and every usage snapshot ships without maxTokens. CLAUDE_CODE_MAX_CONTEXT_TOKENS, which Claude Code itself honors and which is settable per instance in T3, is never read for this.
Impact
Minor bug or occasional failure
Version or commit
main @ eb751fa
Environment
Linux (Fedora, kernel 7.0), Claude Code CLI via CLIProxyAPI (Anthropic-compatible endpoint over chat/completions upstreams), custom model GLM-5.3-Flash
Possible fix directions
My read; happy to have maintainers weigh in.
- Fall back to the instance's
CLAUDE_CODE_MAX_CONTEXT_TOKENSenv var inclaudeContextWindow()when the catalog has no entry — smallest fix, honors a setting already exposed. - Let custom model entries declare a context window (field on
CustomModelEntry), so any custom model can state its window in settings.
Activity
pepsile commentedon Oct 30, 2026
Confirmed on T3 server v0.1.5, Ubuntu 24.04 ARM64, viewed from the macOS desktop client, using Claude Code 2.1.314 and a custom
xiaomi-plan/mimo-v2.6-promodel through Magpie's Anthropic-compatible gateway.An additional data point: the Claude SDK result already includes a context window for this custom model, but the meter still has no percentage. Relevant fields from the captured result envelope:
{ "modelUsage": { "xiaomi-plan/mimo-v2.6-pro": { "contextWindow": 1048576, "maxOutputTokens": 32000 } } }The affected thread's persisted
contextUsageonly containedusedTokens; the UI showed the token count without a denominator/percentage.CLAUDE_CODE_MAX_CONTEXT_TOKENS=1048576was also set in the Claude profile. This is a missing display-capacity value, rather than a failure to receive token counts.I traced the matching v0.1.5 source:
claudeContextWindow()exclusively queriesBUNDLED_CLAUDE_MODEL_CATALOG.resolveClaudeCatalogContextWindowTokens()returnsundefinedwhen the custom model is absent from that catalog.claudeProviderTurnTokenUsage()therefore emitsmaxTokens: nullinstead of using the available SDK capacity metadata.An isolated local replay of these original source functions with the same synthetic usage count produced:
The replay made no network/model requests and did not change the installed application.
Alongside the explicit custom-model/instance configuration options proposed above, a validated SDK
modelUsage[activeModel].contextWindowcould be another fallback when the bundled lookup misses. A result can contain several model entries, so that fallback would need to select the active model rather than take an arbitrary entry. The captured SDK value establishes that metadata is available here; it does not independently verify the upstream provider's actual limit.Posted with the account owner's authorization; diagnosis assisted by Codex.
RodriMora commentedon Nov 7, 2026
Fixed on 0.1.8