Skip to content

[Bug]: Unknown-model warning flood (claude-opus-5-5) crashes the VS Code window with OOM on Windows (v2.4.0) #122

Open
Open
[Bug]: Unknown-model warning flood (claude-opus-5-5) crashes the VS Code window with OOM on Windows (v2.4.0)#122
Labels
bugSomething isn't working

Description

@jordanvalnet
jordanvalnet
opened on Sep 29, 2026

Preflight checklist

What happened?

For about a week, the VS Code window kept crashing with renderer process gone (reason: oom, code: -536870904), each time followed by an extension-host crash. It happened three times in a single evening. Other applications crashed at the same moment (Chrome), and copy/paste froze for minutes, while Task Manager still showed several GB of free RAM.

What I measured on the live machine:

  1. The unknown model. getModelPricing does not know claude-opus-5-5 (the table has claude-opus-5). It therefore falls through to inferPricingByFamily and calls console.warn("Unknown model: claude-opus-5-5, using … pricing as fallback") for every priced record. My history has about 50,000 Opus 5.5 records. A refresh prices them more than once, because getBranchBreakdown and getWorkflowBreakdown both call calculateUsageData.
  2. VS Code forwards the warnings. Every console.* call made in the extension host is forwarded to the window renderer (_handleConsoleCall → RPC → MessagePort.postMessage). Batches larger than Mojo's 64 KB inline limit travel in shared-memory sections.
  3. The renderer cannot keep up. Its Section handles climb in bursts: +30,000 in 5 s, up to about 270,000. They pin 10–30 GB of pagefile-backed commit that shows up in no process's private bytes.
  4. Out of memory. Once commit reaches the limit, the renderer is killed and every allocation on the machine starts failing.

Evidence (Windows 11 build 26200, 15.4 GB RAM):

  • Extension-host CPU profile during a burst (10 s, 1 ms sampling, taken through the host's inspector). 73.7% of samples have a growthjack.claude-code-usage-2.4.0 frame on the stack. 54% of self time is native postMessage. The dominant postMessage stacks:

    postMessage < send < _remoteCall < _handleConsoleCall
  < getModelPricing (pricing.js:435) < calculateCostBreakdown (pricing.js:553)
  < calculateUsageData (dataLoader.js:1097)
  < getBranchBreakdown (dataLoader.js:2740) | getWorkflowBreakdown (dataLoader.js:2210)
  < updateClaudeUsageIndex (claudeIncrementalIndex.js:1904)

  • CPU during bursts. The extension host ran at 130–190%, the workbench renderer at 200% or more, and the webview renderer stayed idle.

  • Renderer handle breakdown, about 8 minutes after a window reload. 84,460 of its 84,545 handles were Section objects, holding about 10 GB of pagefile-backed memory; the largest single section was 12.7 MB.

  • Windows event log. Windows logged 14 Resource-Exhaustion-Detector 2004 events (low virtual memory) in 5 days. The first one came about 5 hours after the auto-update to 2.4.0 on 2026-09-25, as Opus 5.5 records were piling up.

What did you expect instead?

An unknown model should be reported once, which is what PR #120 does. claude-opus-5-5 should also be priced without a warning, either as a table entry or through a claude-opus-5-* prefix match before the family fallback.

Steps to reproduce

  1. On Windows, have a Claude Code history with many records from a model that is missing from the pricing table. Here that was claude-opus-5-5: about 50k records in about 1.2 GB of JSONL.
  2. Keep a Claude Code session active, so that transcripts change and the index refreshes.
  3. Watch the handle count of the VS Code window renderer (Task Manager → Details → Handles column). It jumps by tens of thousands within seconds on each refresh, and commit charge follows.

Extension version

2.4.0

Claude Code version

2.1.284, then 2.1.285 (VS Code extension)

VS Code version

1.139.1 (commit 04c0d99f4f)

Operating system

Windows 11 Pro 25H2 (build 26200)

Model / proxy setup

Native Anthropic (Claude Code, Opus 5.5 with 1M context)

Diagnostic logs

Not captured: the window was crashing every few minutes. The CPU profile above was taken during a burst instead.

Anything else?

Activity

  1. github-actions commented on Sep 29, 2026

    @github-actions
    github-actionsbot
    on Sep 29, 2026 – with GitHub Actions

    🤖 Automated first-pass reply

    TL;DR: Treat this as two connected fixes: stop pricing claude-opus-5-5 through the unknown-model fallback, and make any remaining unknown-model diagnostic one-time/throttled rather than per-record. The current Anthropic table in src/pricing.ts already has claude-opus-5 but not claude-opus-5-5, so the direct fix is a pricing entry or prefix match.

    Analysis

    • The supplied src/pricing.ts shows the exact Anthropic table has 'claude-opus-5': OPUS_CURRENT but no claude-opus-5-5 entry. The Bedrock resolver already matches any claude-opus-5* via name.includes('claude-opus-5'), so the Anthropic path is the gap.
    • The report is consistent with getModelPricing()/inferPricingByFamily() calling console.warn() in the fallback path; the source excerpt does not include those functions, but the table gap is visible.
    • With a 50k-record history and refresh calls from both branch and workflow breakdowns, even a small per-record console call becomes a very large Extension Host → renderer message flood. The minimal behavior fix is to make claude-opus-5-5 resolve directly to OPUS_CURRENT instead of entering the warning path.
    • A general throttling/deduplication change is still valuable for future unknown labels, but it must not broaden diagnostic output carelessly; AGENTS.md requires explicit privacy review for diagnostic changes and says diagnostic output lives under src/extension.ts.

    Suggested next step(s)

    1. Add claude-opus-5-5: OPUS_CURRENT to MODEL_PRICING in src/pricing.ts and a red-green test in src/test/pricing.test.ts asserting it resolves without falling into the unknown-model path. Consider a claude-opus-5-* prefix match before the family fallback to cover future point releases.
    2. Separately, limit unknown-model warnings to once per unknown model label per Extension Host session, and/or route them to the extension diagnostic output channel rather than console; confirm this against the existing diagnostic ownership in src/extension.ts.
    3. Before merging, verify PR perf: report an unknown model once, not once per priced record (#99) #120’s exact behavior if it is still open: if it only deduplicates the warning but does not add claude-opus-5-5, this issue is not fully fixed by perf: report an unknown model once, not once per priced record (#99) #120 alone.

    🤖 Generated by DeepSeek as an automated first pass — not a maintainer decision.

  2. Carl723000 commented on Sep 30, 2026

    @Carl723000
    Carl723000
    on Sep 30, 2026
    Collaborator

    Thank you @jordanvalnet for the detailed Windows profiling, and @rsyuzyov for the targeted fix in #120.

    We have confirmed the repeated-warning path and implemented a fix targeted for v2.4.1, the next patch release:

    • Building on perf: report an unknown model once, not once per priced record (#99) #120, repeated pricing of the same unknown model no longer repeats its warning.
    • Opus 5.5 has an explicit verified pricing entry, so it does not use the warning-producing fallback.
    • A lifetime-wide diagnostic budget also bounds distinct unknown-model labels, preventing future model additions from recreating an unbounded warning flood.

    The repeated-record and model-churn regressions pass. The current fix set also passes 1,152 Node tests and 182 browser UI tests. It is in final review and is not yet available on Marketplace.

    These tests verify the source warning amplification is removed; they do not prove the Windows-native handle/commit-memory regression is resolved. We are keeping this issue open for validation of the released patch against the reported environment.

    Until that update is available, disabling Claude Code Usage is the safest temporary workaround for anyone seeing the same warning flood or crashes. Please do not upload conversation logs or credentials; anonymous diagnostics and a redacted CPU profile are sufficient if further evidence is needed.

    🤖 Generated with OpenAI Codex

  3. Carl723000
    added
    bugSomething isn't working
    on Sep 30, 2026

  4. Carl723000 commented on Oct 5, 2026

    @Carl723000
    Carl723000
    on Oct 5, 2026
    Collaborator

    Thank you @jordanvalnet for the detailed Windows evidence, and @rsyuzyov for #120. v2.4.1 is now available on VS Code Marketplace; the publish workflow and public version listing both confirm delivery.

    The patch removes the reported per-record pricing-warning amplification:

    • claude-opus-5-5 resolves to its own explicit pricing entry, including cache/TTL rates, without an unknown-model warning.
    • Repeated pricing of the same unknown label warns only once. A whole-Extension-Host-lifetime budget caps distinct-label warnings at 128 plus one suppression summary; label churn and refreshes cannot reset that budget.
    • Oversized or non-model-shaped labels are not retained or echoed verbatim in these diagnostics. Suppressing warnings does not stop token accounting.

    The repeated-record/model-churn regressions and release CI pass. We have not reproduced your Windows-native Section-handle/commit-memory scenario, so source tests are not proof that every renderer OOM is resolved.

    Could you confirm the installed extension is 2.4.1 and retest in the same Windows environment, checking whether warning bursts, handle growth and crashes stop? If they persist, please share anonymous diagnostics and a redacted profile rather than raw conversation logs, credentials or personal paths. We will keep this issue open pending that released-version validation.

    🤖 Generated with OpenAI Codex

  5. Carl723000 commented on Oct 15, 2026

    @Carl723000
    Carl723000
    on Oct 15, 2026
    Collaborator

    Released-version follow-up: 2.5.0 is now public. It retains the explicit Opus 5.5 pricing and lifetime-bounded unknown-model diagnostics shipped in 2.4.1, and adds the separately identified large-history stack-overflow fix in #126/#131.

    The warning-flood source path has regression coverage, but neither the new release nor green source tests prove that your Windows-native Section-handle/commit-memory crash is resolved. Keeping this issue open for validation in the reported environment.

    If you choose to retest, please confirm the installed version is 2.5.0 and whether the repeated warnings, handle growth and crashes still occur. Anonymous diagnostics and a redacted profile are enough; do not share conversation logs, credentials or personal paths. If it is still unstable, please disable the extension to protect your work.

    🤖 Generated by OpenAI Codex as an automated first pass — not a maintainer decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions