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

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/10728
2. https://github.com/anthropics/claude-code/issues/4953
3. https://github.com/anthropics/claude-code/issues/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 * [x] 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.

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:

1. Expensive string concatenation operations with growing buffer size
2. 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:

1. Session starts: fullStaticOutput = "" (fast)
2. After 10 compactions: fullStaticOutput = 500KB (each += copies 500KB, each render outputs 500KB)
3. After 20 compactions: fullStaticOutput = 1.5MB (each += copies 1.5MB, each render outputs 1.5MB)
4. 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:

1. Monitor process.memoryUsage().heapUsed over long sessions
2. Measure render operation timing before/after compaction
3. Check fullStaticOutput.length growth over time
4. 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.