Bug Report: Agent session history grows unbounded → exponential token consumption

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Bug Report: Agent session history grows unbounded → exponential token consumption

Submit to: Bug Reports - Cursor - Community Forum

Title

Agent session history grows unbounded in state.vscdb, causing exponential token consumption

Severity

High — financial impact (silent token burn) + degraded UX (slower responses over time)

Where does the bug appear?

Cursor IDE — Agent / Composer mode (all platforms)

Summary

The agentKv table in state.vscdb accumulates agent conversation history indefinitely with no eviction, pruning, or user-visible warning. Long-running sessions cause exponential token growth because the entire uncapped history is sent as context with each new message.

Evidence (from my machine after ~2 weeks of use)

Metric

Value

state.vscdb file size

389 MB

agentKv entries

16,273 (197.6 MB)

bubbleId entries

7,250 (114 MB)

Total KV entries

25,090

Worst single session

873 messages / 43.6 MB

2nd worst session

371 messages / 31.7 MB

SQL to reproduce:

– File: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb
SELECT
CASE
WHEN key LIKE ‘agentKv:%’ THEN ‘agentKv’
WHEN key LIKE ‘bubbleId:%’ THEN ‘bubbleId’
ELSE ‘other’
END AS category,
COUNT(*) AS count,
ROUND(SUM(LENGTH(value))/1024.0/1024.0, 2) AS total_mb
FROM cursorDiskKV
GROUP BY category
ORDER BY total_mb DESC;

Steps to reproduce

Use Agent/Composer mode for many turns in a project

Observe state.vscdb grow without bound

Run the SQL query above to see the accumulated data

Note that each new message in a long session incurs linearly growing context overhead

Root cause

No per-session message cap — sessions grow to 873+ messages

No client-side context budget enforcement — server-side limits arrive too late (tokens already consumed)

No visible indicator of session size or context usage

No automatic eviction of old/inactive agent sessions

Expected behavior

Enforce a per-session message or token budget, auto-summarize or trim beyond a threshold

Show context usage % in the composer UI (similar to the existing contextUsagePercent field already stored in the DB)

Auto-prune old/inactive agent sessions from state.vscdb (e.g., keep last N sessions, age-based TTL)

Warn the user when a session exceeds a threshold: “This conversation has 800+ messages. Start a new session to reduce token usage and improve response quality?”

Impact

Users unknowingly burn through monthly token/request quotas

Response quality degrades as context window fills with stale history

389 MB of SSD wasted on stale conversation data that is never cleaned up

No way for users to know which sessions are consuming their budget without manually querying SQLite

Environment

macOS 15.5 (arm64, M4)

Cursor version: latest (as of 2026-05-30)

Steps to Reproduce

yes

Expected Behavior

yes

Operating System

MacOS

Version Information

202605302026053020260530

For AI issues: which model did you use?

202605302026053020260530

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

cursor-bug-report.txt (2.9 KB)

6

Hey, thanks for the detailed report with metrics and SQL. This is helpful.

It helps to split this into two parts.

The growth of state.vscdb is a real issue. Right now there’s no automatic retention policy or eviction for old agent and chat sessions, so with active use the database keeps growing. This is a known issue and it’s being tracked, but I can’t share an ETA for a fix yet. The same topic is discussed in a few threads, for example Cursor state.vscdb growing at 1 GB in a day and Cursor freezes; state.vscdb grows to 10 GB.

What you can do right now to clean it up:

  • Command Palette Cmd+Shift+P → Delete Old Chats
    • Deletes old chats based on a day threshold.
  • Command Palette → GC Agent KV Blobs
    • Cleans up orphaned blob records and runs VACUUM.

On the “exponential token consumption” part, there’s a small misunderstanding. All local history from state.vscdb is not sent to the model in full on every message. On the server side, old turns in long sessions are summarized and trimmed before sending to the LLM. That means the context that actually goes to the model is capped, and token usage does not grow linearly with the size of the local database. state.vscdb growth is about disk usage and UI performance, not about burning tokens.

There are already feature requests for a UI indicator for context usage and for a built-in cleanup tool. You can add a vote and details here:

Let me know if the database doesn’t shrink after Delete Old Chats, then we can dig deeper.

7

Hi there, if you improved the speed and overhead of Cursor in newer versions? Currently I can only like using Cursor for several hours and it either stucks or lags completely… have to kill the workflow and clean by hand. And restart losing the continuous workflows of the agents. That is really unusable for heavy use cases and heavy users… could you share info on the recent situation? Any one in cursor team consider to improve the Cursor overhead or efficiency? Is Cursor usable for multi-agent heavy workflows now? Thanks.

8

@taliefirzen, the slowdowns and freezes in long sessions are partly caused by the local DB growing state.vscdb, and the session itself building up a lot of history. Over time, this hurts the UI and responsiveness.

A couple things that help right now:

  • Clean the DB from time to time: Command Palette Cmd+Shift+P → Delete Old Chats (removes old chats based on a day threshold) and GC Agent KV Blobs (cleans orphaned blob entries and runs VACUUM).
  • For heavy or multi-agent work, try not to keep a single session going for hundreds of messages. Start a new one occasionally since long sessions get slower and the context quality can degrade.

There isn’t an automatic retention policy yet, so you still need to clean it manually. This is known, but I can’t share an ETA.

If the lag or freezes still happen after cleaning, please share your Cursor version, OS, and the size of state.vscdb plus the Request ID if you have it. Then we can check if it’s a separate memory-related case, not just the DB size.