[BUG] Claude Code consistently degrades in performance over long sessions

Preflight Checklist

I have searched existing issues and this hasn't been reported yet
This is a single bug report (please file separate reports for different bugs)
I am using the latest version of Claude Code

What's Wrong?

After long sessions (Claude Max with several autocompacts), Claude Code becomes slower and slower to the point that it becomes so slow that takes several minutes between requests. The current solution is to shut it down and start fresh. It looks as if something accumulates (data structure or something) and causes a terrible performance issue. I have /rewind disabled (disabled it due to the performance issue) and nothing improoves that doesn't seems to be the cause. I am using streaming MCP.

What Should Happen?

Stay at the same performance level during long sessions by using performant O(nlogn) data structures and not slow to a crawl. Or not have some memory leak (could be the cause too)

Error Messages/Logs

No error, just heavy performance degradation.

Steps to Reproduce

Run during a very long session and several auto compacts. Monitor the performance with performance counters scattered around blocks of code to locate the culprit region.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

v2.0.31

Platform

Anthropic API

Operating System

Windows 11

Terminal/Shell

Windows Terminal

Additional Information

No response

Found 3 possible duplicate issues:

[BUG] 2 hour session exhausts 4G and crashes claude code 2.0.28/2.0.29 #10728
Claude Code Memory Leak - Process Grows to 120+ GB RAM and Gets OOM Killed #4953
[Bug] Performance Degradation: Persistent Slowdown After PostToolUse:Edit Hook #8927

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

Preflight Checklist

I have searched existing issues and this hasn't been reported yet[x] This is a single bug report (please file separate reports for different bugs)[x] I am using the latest version of Claude Code

What's Wrong?

After long sessions (Claude Max with several autocompacts), Claude Code becomes slower and slower to the point that it becomes so slow that takes several minutes between requests. The current solution is to shut it down and start fresh. It looks as if something accumulates (data structure or something) and causes a terrible performance issue. I have /rewind disabled (disabled it due to the performance issue) and nothing improoves that doesn't seems to be the cause. I am using streaming MCP.

What Should Happen?

Stay at the same performance level during long sessions by using performant O(nlogn) data structures and not slow to a crawl. Or not have some memory leak (could be the cause too)

Error Messages/Logs

No error, just heavy performance degradation.

Steps to Reproduce

Run during a very long session and several auto compacts. Monitor the performance with performance counters scattered around blocks of code to locate the culprit region.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

v2.0.31

Platform

Anthropic API

Operating System

Windows 11

Terminal/Shell

Windows Terminal

Additional Information

No response

This is probably due to the 200K token budget limit related to the context window. I chatted with the support team and they confirmed that the 200K limit is shared across Pro and Max subscriptions. It can be increased up to 500K, but that requires an enterprise account.
In the meantime, you should migrate from output style (which will be deprecated on November 5th) to system prompt using --append-system-prompt-file, as this will help with caching. However, the performance degradation you're experiencing also depends on how large your projects are and how much context accumulates over long sessions

Plus one, after using Claude for hours, with many compacts, performance is TERRIBLE. I have to either lose context (very bad) or it's unusable.

This is probably due to the 200K token budget limit related to the context window. I chatted with the support team and they confirmed that the 200K limit is shared across Pro and Max subscriptions. It can be increased up to 500K, but that requires an enterprise account. In the meantime, you should migrate from output style (which will be deprecated on November 5th) to system prompt using --append-system-prompt-file, as this will help with caching. However, the performance degradation you're experiencing also depends on how large your projects are and how much context accumulates over long sessions

I disagree. Longer context means more processing, not less. This seems to be some bug lurking around. I disabled MCP, appeared to improve but also happens without MCP. It consistently happens with native version too. I switched to native to delay this as much as possible.

@tokoroten

Root Cause Analysis: Console History Accumulation After Compaction

This analysis was performed by @tokoroten using Claude Code to investigate the compiled source.

I've investigated the performance degradation issue and identified the root cause by analyzing the compiled code in @anthropic-ai/claude-code@2.0.35.

The Bug

The terminal renderer fails to clear fullStaticOutput buffer, causing progressive performance degradation through two compounding mechanisms:

Expensive string concatenation operations with growing buffer size
Re-rendering of accumulated historical data on every render cycle

Technical Details

1. `fullStaticOutput` Never Gets Cleared

Ultra-thorough analysis confirms: fullStaticOutput is initialized once but never reset.

Occurrences in cli.js:

Line 202: Initialized to "" in TG1 constructor
Lines 207, 208, 211: Appended using += operator
Lines 207, 209: Read for rendering output
Line 204: reset() method exists but does NOT clear fullStaticOutput

// Line 202 - Constructor
this.state = {
  fullStaticOutput: "",      // ⚠️ NEVER CLEARED after initialization
  previousOutput: "",         // Cleared by reset()
  prevFrame: B                // Cleared by reset()
}

// Line 204 - Incomplete reset() method
reset(){
  this.state.prevFrame = ATA(this.state.prevFrame.rows, this.state.prevFrame.columns),
  this.state.previousOutput = ""  // Only these two are reset
  // fullStaticOutput is NOT touched!
}

2. Dual Performance Degradation Mechanism

Problem 1: O(n) String Concatenation Cost

// Lines 207, 208, 211
this.state.fullStaticOutput += A.staticOutput

JavaScript strings are immutable
Each += operation creates a new string object and copies all existing content
As fullStaticOutput grows (10KB → 100KB → 1MB), each append requires full memory copy
Cost increases linearly with accumulated buffer size

Problem 2: Re-rendering Historical Data

// Lines 207, 209 - Every render outputs the FULL accumulated buffer
{type:"stdout", content:this.state.fullStaticOutput, scrollback:!0}

Every render operation processes the entire accumulated history
Terminal scrollback buffer holds hundreds of KB to MB of old output
Rendering cost increases with session length

3. Compaction Does Not Trigger Cleanup

Verification: Searched entire codebase for cleanup during compaction:

❌ No PreCompact hook that clears fullStaticOutput
❌ No PostCompact hook that clears fullStaticOutput
❌ No code path exists where fullStaticOutput is reset to ""

The only assignment to fullStaticOutput = "" is in the constructor (Line 202).

Impact Analysis

This dual mechanism explains the reported symptoms:

✅ Performance degrades progressively over long sessions
✅ Multiple autocompacts exacerbate the issue (more data accumulates)
✅ Eventually takes several minutes between requests
✅ Restarting Claude Code fixes the issue (destroys TG1 instance, reinitializes to "")

Growth pattern:

Session starts: fullStaticOutput = "" (fast)
After 10 compactions: fullStaticOutput = 500KB (each += copies 500KB, each render outputs 500KB)
After 20 compactions: fullStaticOutput = 1.5MB (each += copies 1.5MB, each render outputs 1.5MB)
Performance becomes unusable

Proposed Fix

Option 1: Clear in reset() method (minimal change)

reset(){
  this.state.prevFrame = ATA(this.state.prevFrame.rows, this.state.prevFrame.columns),
  this.state.previousOutput = "",
  this.state.fullStaticOutput = ""  // Add this line
}

Option 2: Clear during compaction (proper lifecycle management)

Add cleanup hook after compaction completes:

// In PostCompact or after compaction finishes
if (this.renderer && this.renderer.state) {
  this.renderer.state.fullStaticOutput = "";
}

Option 3: Use buffer with size limit (prevent unbounded growth)

const MAX_STATIC_OUTPUT = 100000; // 100KB limit
if (this.state.fullStaticOutput.length > MAX_STATIC_OUTPUT) {
  this.state.fullStaticOutput = this.state.fullStaticOutput.slice(-MAX_STATIC_OUTPUT);
}
this.state.fullStaticOutput += A.staticOutput;

Verification Method

To confirm this fix resolves the issue:

Monitor process.memoryUsage().heapUsed over long sessions
Measure render operation timing before/after compaction
Check fullStaticOutput.length growth over time
Profile string concatenation operations during active sessions

Environment

Analyzed version: @anthropic-ai/claude-code@2.0.35
Analysis method: Claude Code-assisted decompiled source review
File: cli.js (compiled/bundled)
Key lines: 202 (initialization), 204 (reset), 207/208/211 (append), 207/209 (render)

Analysis performed by @tokoroten using Claude Code (Sonnet 4.5) on 2025-11-08

The symptom I'm experiencing is that the scrollback buffer gets fouled up, keeps jumping back to the top and jittering from top to bottom. I'm running stock Ubuntu 22 with default terminal.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I moved to VS code extension due to the flickering. Seems to be degrading less but still does.

Experiencing Same Issue - WSL2

Environment:

Claude Code version: 2.1.6
Platform: WSL2 on Windows
Kernel: Linux 6.6.87.2-microsoft-standard-WSL2
System RAM: 16GB

Symptoms:

Typing lag progressively worsens over ~15 minutes of active use
System-wide freeze affecting all Windows applications (not just WSL)
CPU spikes to 190%+ during lag episodes
Terminal eventually crashes and restarts

Onset: Started ~1.5 days ago. Never had this level of lag before.

Observed Memory Growth Pattern:

Time	Elapsed	RSS Memory	Notes
0:00	start	~340MB	Fresh session
0:09	9min	490MB	Normal use
0:09	+30sec	588MB	+98MB in 30 seconds
0:10	+30sec	641MB	+53MB in 30 seconds
0:11	11min	716MB	CPU hit 190%

Key observation: Memory grows ~50MB per 30 seconds during active tool use (bash commands, file reads). Older idle sessions stabilize around 400MB, but active sessions balloon rapidly.

System impact: When Claude Code spikes, VmmemWSL on Windows side also shows high CPU - suggests bottleneck at WSL/Windows boundary, possibly from memory pressure or I/O.

Workaround in use: Restarting sessions every 30-45 minutes before lag becomes severe.

Diagnostic data available: I have memory timeline CSVs and CPU spike logs if helpful for debugging.

Can confirm the progressive slowdown over long sessions on v2.1.14 (macOS). Restarting is still the only workaround.

Confirmation: Long sessions cause 80-100% idle CPU (macOS)

Adding data from a macOS environment that confirms this issue persists in v2.1.27-2.1.30.

Environment: MacBook Pro M3 Max, macOS 15.7.4

Observation: 10 concurrent sessions with --continue flag, running 7h to 4 days, all showed 50-98% CPU while completely idle. The oldest session (3d 22h) used 92% CPU with 745MB memory.

Immediate workaround: Running /clear in a session drops CPU from 98% → 0% instantly and reduces memory ~10x. This is more practical than killing sessions since it preserves the session ID for --continue.

This aligns with the root cause analysis in this thread about fullStaticOutput buffer accumulation. The /clear command appears to reset whatever state causes the continuous rendering/GC activity.

Cross-ref: Detailed diagnostic data in #22509

Still waiting for a resolution. Why is no one picking this up? Every single person who has ever used claude code over a period must have faced this issue.

Instead of fixing the bug, it seems like even people at Anthropic has learned to live with it instead.

Additional data: Multi-instance orchestration scenario

Environment:

Claude Code version: 2.1.27
Platform: Linux (Ubuntu, kernel 6.14.0)
Use case: Running 10-15+ concurrent Claude Code instances for agent orchestration

Symptoms:

Each idle instance uses 50-110% CPU (confirmed via top)
Performance degrades progressively during sessions
Past workaround was pinning to older versions, but that's not sustainable

Impact:
For users running multiple instances (e.g., AI agent orchestration systems), this compounds significantly. Total system CPU usage from idle Claude Code processes can exceed 500%.

Workaround discovered in this thread:
The /clear command tip is valuable - will test dropping CPU from ~98% → 0%.

This issue is blocking adoption for multi-agent use cases. Would appreciate prioritization.

Performance degradation over long sessions is caused by context inflation — the signal-to-noise ratio drops as bloat accumulates. Each compaction cycle helps briefly, then bloat re-accumulates.

Cozempic v1.4.1 keeps sessions lean continuously with a guard daemon. 17 strategies strip different bloat types: progress ticks (40-48%), stale reads, duplicate documents, old images. The new compact-summary-collapse removes 85-95% of pre-compaction content.

pip install cozempic && cozempic init

Should help maintain performance quality across long sessions. Feedback welcome.

[BUG] Claude Code consistently degrades in performance over long sessions #10881

Description

Preflight Checklist

What's Wrong?

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

Activity

github-actions commented on Nov 3, 2025

PaoloBrera commented on Nov 3, 2025

Preflight Checklist

What's Wrong?

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

erichanson commented on Nov 6, 2025

waldoalvarez00 commented on Nov 6, 2025

tokoroten commented on Nov 7, 2025

Root Cause Analysis: Console History Accumulation After Compaction

The Bug

Technical Details

1. fullStaticOutput Never Gets Cleared

2. Dual Performance Degradation Mechanism

3. Compaction Does Not Trigger Cleanup

Impact Analysis

Proposed Fix

Verification Method

Environment

erichanson commented on Nov 10, 2025

github-actions commented on Dec 11, 2025

waldoalvarez00 commented on Dec 12, 2025

chris-w-gibson commented on Jan 13, 2026

Experiencing Same Issue - WSL2

alberduris commented on Jan 21, 2026

terrylica commented on Feb 3, 2026

Confirmation: Long sessions cause 80-100% idle CPU (macOS)

GiteshDalal commented on Feb 28, 2026

devinvenable commented on Mar 4, 2026

Additional data: Multi-instance orchestration scenario

junaidtitan commented on Apr 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1. `fullStaticOutput` Never Gets Cleared