[BUG] Claude memory usage spiking and speed dropping to a crawl

Status Fixed / completed

Maintainer reply ✓ Yes — bcherny

Activity 5 comments · opened Jul 31, 2025 · closed Aug 12, 2025

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Environment

Platform (select one):
[x] Anthropic API
[ ] AWS Bedrock
[ ] Google Vertex AI
[ ] Other:
Claude CLI version: 1.0.63
Operating System: macOS 15.5
Terminal: iTerm2

Bug Description

Over the last 2-3 days, I have seen Claude slow to a complete standstill when it is performing tasks using defined sub-agents. This started happening around when I defined ten sub-agents (until then, I had been using just the general sub-agent). I don't know if that is related, or if it is simply a coincidence. I think it is a coincidence, since I have seen others mentioning weird interface bugs, but thought I would mention it.

I saw a bug reported about the ESC key resulting in the hanging of the terminal sessions - that is happening to me too. I also have seen an issue about the agent usage and sub-process spinning causing massive memory overload and have instituted the solution suggested there (https://github.com/anthropics/claude-code/issues/1970) and I am still experiencing the problem.

Steps to Reproduce

Give Claude directions that include spinning up one or more sub-agents
Initially, the system will appear to be functioning normally, but eventually, every single execution will take mane, many minutes, and even acknowledging and showing my input in the terminal window takes upwards of 10-20 seconds. If I press ESC, the terminal session freezes and I lose all the history of what was done in the session. I also cannot see anything that the sub-agents is doing except for what one of them needs input to allow a command or an edit/write to a file.
I eventually end up having to quit Claude altogether if the terminal session hasn't frozen, or I need to force quit the app from the Activity Manager.

Expected Behavior

Consistent, fast, responsiveness which has been the norm for the couple of months that I have been using it.

Actual Behavior

Detailed above

Additional Context

None

View original on GitHub ↗

5 Comments

dormem · 1 year ago

It even took 20-30 seconds to execute the /exit command just to try to cleanly terminate the processes.

I also see this message on the bottom right when having exited: 4 MCP servers failed · /mcp for info

bcherny collaborator · 1 year ago

Fix incoming in the next version

dormem · 1 year ago

Fix incoming in the next version

That's great! Is that 1.0.64, which was installed after I wrote my report?

Will that mean that we can remove the configuration suggested in a different thread:

Process Safety Rules

CRITICAL: Prevent system overload

Max 10 concurrent processes
Sequential execution only
No parallel spawning

Safe command usage:

# ❌ AVOID
fd .                    # Can spawn too many threads
rg pattern             # Can hang on large output
cargo build            # Can spawn 100+ processes

# ✅ USE INSTEAD  
find . -type f  < /dev/null |  head -1000     # Limited results
grep -r pattern . | head -100   # Limited output
cargo build --jobs=2            # Limited parallelism

github-actions[bot] · 1 year ago

Found 3 possible duplicate issues:

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