Anthropic staff investigate Claude Code P99 RSS, CPU, and memory complaints

• Anthropic says Claude Code performance work has already landed on P99 RSS, while CPU and memory complaints still need repro details from users, according to bcherny's P99 RSS reply.
• The current ask is specific: Claude Code surface, OS, task or tool, and hardware specs, based on bcherny's platform reply and bcherny's machine-specs reply.
• At least one fix path is still in progress: bcherny called it "50% of the way there" in one follow-up and answered another report with "Looking" in another follow-up.
• No confirmed product change explains one reported shift yet, since bcherny's restart check said there were no changes he was aware of and asked whether restarting Claude helped.

Anthropic's own Claude Code troubleshooting page has a hidden-ish /heapdump command, a claude --safe-mode plugin isolation path, and a warning that heap snapshots include full conversations and credentials. The Claude Code release notes show the performance work is not hypothetical: recent entries mention unbounded RSS from unreleased streaming buffers, truncated MCP outputs retained in memory, and quadratic normalization stalls in long sessions.

Boris Cherny's public GitHub profile lists him as working on Claude Code at Anthropic. In the thread, bcherny said the team has "landed large improvements to P99 RSS over the past few months" while asking for more details about current CPU and memory reports.

That phrasing keeps the confirmed improvement narrow: P99 resident set size, while the newer complaints still needed reproduction data.

The official changelog lines up with that pattern. Version 2.1.74 fixed a streaming API response buffer leak that caused "unbounded RSS growth" on the Node.js/npm path, and later release notes mention fixes for MCP tool output retention, quadratic long-session normalization cost, and unbounded memory growth from oversized settings files in the Claude Code release notes.

The active investigation is collecting a minimal bug report, not just complaints about fans spinning.

Anthropic asked for:

• Surface: CLI or Desktop, in bcherny's platform reply.
• OS: macOS, Linux, or Windows, in bcherny's P99 RSS reply.
• Trigger: a specific task or tool that seems to cause the issue, in bcherny's P99 RSS reply.
• Hardware: RAM and CPU, in bcherny's machine-specs reply.

The GitHub issue tracker shows why those fields matter. One high-CPU issue reported two Claude Code CLI instances using sustained CPU while idle on Linux Mint, with Node.js version, core count, RAM, terminal, and per-thread CPU output included in the GitHub report. Another memory issue described Claude Code v2.1.87 growing from about 350 MB to 3.6 GB in under five minutes on WSL2, with plugins, WSL memory, swap, Node.js, and launch command listed in the issue details.

One user got a progress marker, not a closure: bcherny replied that Anthropic was "50% of the way there" and still working on it.

A second follow-up got a shorter status update: "Looking." In another branch, bcherny said he was going to "bash on this a bit" to see if the team could trigger similar symptoms bcherny's repro reply.

One report sounded like a perceived behavior change. bcherny answered that he was aware of no changes, then asked whether people still saw the issue after restarting Claude.

That restart question separates persistent resource growth from state carried by a running session. Claude Code's troubleshooting docs also tell users to close and restart between major tasks and to run /compact to reduce context size on the performance and stability page.

Anthropic already documents a deeper diagnostic path for memory cases. The troubleshooting page says /heapdump writes a JavaScript heap snapshot and a diagnostics JSON file to the Desktop, or to the home directory on Linux without a Desktop folder.

The docs add two important constraints: the .heapsnapshot contains every string in the process, including full conversation text and credentials, while the diagnostics JSON is the file Anthropic asks users to attach to public GitHub reports. The same page says the printed summary breaks memory into resident set size, JS heap, array buffers, unaccounted native memory, and leak indicators in the official troubleshooting docs.