Agents get progressively slower as sessions get longer.
Steps to Reproduce
Start one agent.
Give prompts for 10 minutes.
Record screen as reply arrives.
Give prompts for a day.
Record screen as reply arrives
You’ll notice the agent is at least 2x slower in the 2nd recording. (video attached of an agent I left working overnight)
And it will get slower and slower with usage.
Expected Behavior
With Claude Code and Codex (Cursor extensions or CLIs), the contents get cycled and the token throughput is practically the same. Cursor agents, however, as session length increases, text shows up slower and slower, looking extremely buggy and feeling sluggish.
Context about “Does this stop you from using Cursor”. I answered “Yes”, and it’s because it makes it feel slow and not enjoyable. Because of this, I’ve switched to using Claude Code / Codex extensions inside Cursor and it’s really a shame because I do love everything else about Cursor.
Thanks for the detailed report and video. This is a confirmed issue - long agent sessions accumulate internal state that progressively slows down text rendering, which is exactly what your recording shows.
Workaround:
Start fresh agent sessions periodically. Closing the current chat tab and starting a new one resets the renderer state that causes the slowdown. This is the most effective mitigation right now.
Check your state.vscdb file size. Over time, this internal database can grow to several GB and compound the sluggishness. On Windows, check: %APPDATA%\Cursor\User\globalStorage\state.vscdb. Important: back up this file before deleting it — removing it will clear your chat history and workspace state, but it will restore normal performance if it has grown large.
Confirming this on Windows 11 / Cursor 3.15.6 (Agents Window) with measurements that match the confirmed long-session slowdown + state.vscdb growth pattern.
[RendererPing] window 1 blocked for ~15010ms / ~15022ms
No ptyHost heartbeat after 6 seconds (many times)
[PowerMainService] … reason=“agent-loop” …
RendererPing is enabled with blockThresholdMs=15000 — these are real ~15s main-thread blocks.
After full Cursor restart (~3 minutes up)
Metric
Before
After
Cursor total WS
~7.6 GB
~2.4 GB
Heaviest renderer
~2.5 GB
~0.48 GB
RendererPing blocks
multiple ~15s
none yet
ptyHost heartbeat misses
dozens
0
state.vscdb
~864 MB
~868 MB (still huge)
Restart temporarily clears in-memory renderer bloat/freeze, but does not shrink the persistent chat/agent DB. Matches staff guidance on this thread.
Extra observation (possibly separate)
workbench.mcp.allowlist*.log filled with ~150k identical lines:
[MCPService] Admin MCP runtime policy unchanged; skipping MCP respawn pass
(5 MB × 6 rotated files). Happy to file separately if useful.
Happy to attach a small redacted evidence zip (sizes + log excerpts only — no state.vscdb body / chat contents) if wanted.
Thanks for the super detailed writeup, @ll1! Two built-in Command Palette commands will shrink that ~864 MB DB without wiping your history (you’re on the Agents Window, so you’ll have them). Open the palette (Ctrl+Shift+P) and run:
Delete Old Chats (under Developer) - deletes chats older than a cutoff you pick, then reclaims the space. It permanently removes chats past that cutoff, so choose a window that keeps what you still need (say 7–14 days).
GC Agent KV Blobs (under Developer) - garbage-collects the leftover agentKv/bubbleId blobs and compacts the DB.
Run Delete Old Chats first, then reload the window. This is the long-session slowdown + state.vscdb growth we’re tracking, so periodic fresh sessions still help the in-memory side - but those two commands are what actually shrink the persistent DB.
The MCP allowlist logging looks like a separate issue. Could you open a new forum thread for just that (with the same log excerpt)? That way we can track it on its own. No need to send anything with chat contents - the redacted zip is plenty.