Why Cursor is slow, and how to isolate the real cause

Match the symptom to the layer

“Cursor is slow” is not yet a diagnosis. Say what is slow while the rest of the product is doing what. The dividing line is whether a local action lags before any AI request exists. If typing into a plain file stutters, the model provider is not the first suspect. If editing is crisp but Agent takes thirty seconds to start streaming, deleting editor caches is not the first suspect.

The ten-minute diagnosis

Stop when a single change produces a repeatable improvement. That result is worth more than a list of twenty speculative tweaks. Re-enable the suspected condition and confirm the slowdown returns before making a permanent tradeoff such as disabling indexing or abandoning an extension.

Extensions and the extension host

Cursor inherits the VS Code extension-host architecture and adds its own AI processes. Public forum reports repeatedly show high CPU and memory caused by several AI extensions running beside Cursor's built-in AI, language tooling activated for stacks not used in the current repository, or extension processes that remain after windows close. The point is not that extensions are bad. It is that they are executable programs sharing the editor's event loop and filesystem activity.

cursor --disable-extensions

If the control is fast, create workload-specific profiles. A TypeScript service does not need Java, Flutter, Jupyter, C#, Go, three AI assistants, and a pull-request bot activated at once. Keep the extensions required by the repository and disable the rest in that profile. Multiple AI coding extensions are especially prone to duplicating file watching, completions, indexing, and chat services.

Indexing and large repositories

A large repository can be small in source code and enormous in files. Dependency trees, build output, caches, coverage, generated documentation, model artifacts, logs, and experiment results all create watcher and indexing work. Forum cases of CPU pinning after edits repeatedly improve when those paths leave the Cursor index or when the user opens a narrower workspace.

**/node_modules
**/.git
**/dist
**/build
**/.next
**/.cache
**/coverage
**/__pycache__
**/*.pyc

The file is not a universal best-practices list. Exclude directories the agent should neither search nor edit. Do not ignore generated source when your task routinely inspects that output, and do not assume .gitignore and .cursorignore answer the same question. One controls Git tracking; the other controls what Cursor should consider.

Long chats and local state

A long Agent conversation can be slow in two independent ways. First, more context must be assembled, transmitted, and processed before the next answer. Second, local chat history and UI state can grow large enough to make the chat panel itself lag. Cursor forum support has described cases where the local state.vscdb grew to multiple gigabytes and old Agent history made the interface nearly unusable.

Prefer built-in history deletion to manually deleting a database. If a forum workaround tells you to remove state or cache directories, treat it as destructive maintenance: fully quit Cursor, back up the data, record exact paths, and understand that chat history may be unrecoverable. Cache clearing is a last resort after a clean-profile test proves state is involved, not a first response to any slow answer.

A fresh chat also improves cost and quality when a task has changed direction. Carry forward the objective, relevant file paths, current diff, tests run, and unresolved error. Do not paste the entire old transcript back into the new window; that recreates the context problem in one turn.

Network, model, and service latency

When the editor stays responsive and only Agent waits, classify the wait. Time to first token points toward request setup, context processing, route, model, or streaming transport. Slow tokens after the response begins points more toward provider generation or a buffered stream. Slow tool steps inside an otherwise responsive answer point toward the command, remote filesystem, or extension host the agent is waiting on.

1. Start a fresh narrow chat. This removes accumulated context from the comparison.
2. Try one other model. Keep the prompt and repository constant. A model-specific delay is useful evidence.
3. Run Cursor network diagnostics. Save the result instead of relying on a browser speed test.
4. Test another allowed network. VPNs, Zscaler, corporate proxies, and managed routes can buffer long-lived streams while normal web pages load normally.
5. Try Cursor’s HTTP compatibility setting. Forum support commonly suggests HTTP/1.1 or disabling HTTP/2 for buffered streaming, followed by a full restart.
6. Check status. Correlate the incident time and selected model rather than treating a green page as proof no partial degradation exists.
7. Capture a Request ID. This lets support distinguish provider delay, Cursor infrastructure, and client-side stream behavior.

Usage limits and slowness should remain separate diagnoses. Current on-demand requests are not intentionally put in a slow queue after included usage ends. If a response is slow, investigate performance. If it is rejected with a quota message, investigate the account limit. An old article about "slow premium requests" describes a retired billing era.

Remote SSH has three extra bottlenecks

Remote SSH adds a network hop, a remote extension host, and a remote filesystem. Cursor forum reports show lag that is worse in workspaces with recursively large file trees, heavy remote extensions, MCP servers activated remotely, or Cursor Server installed on slow network-mounted storage. A local project being fast does not clear any of those remote layers.

Use Developer: Show Running Extensions while connected remotely. Extensions can be installed on the local UI side, the remote workspace side, or both, and the slow process may not be where you expect. Keep remote profiles lean. A language server needed for the current code belongs there; a calendar of unrelated AI and review extensions does not.

Do not delete ~/.cursor-server as a casual first step. That can force a clean reinstall and has helped individual forum cases, but it removes remote state and extensions. First capture the version, logs, extension activation times, install filesystem, and a reproducible small-workspace comparison. If cleanup becomes justified, back up what matters and target the explicit remote directory.

Rendering, GPU, and release regressions

If typing, scrolling, menus, and panel animation lag while CPU and extension tests are clean, the Electron rendering path is plausible. Forum users have reported improvements after disabling hardware acceleration, especially after particular releases. That is a diagnostic switch, not a universal performance recommendation: on a healthy system GPU acceleration should make rendering cheaper, and disabling it can move work to the CPU.

A release correlation is not proof by itself. Updates also restart processes, rebuild indexes, activate new extension versions, and migrate state. The control tests still matter. The useful bug report says "version X is slow in a clean profile on this file, version Y is not", not merely "it became slow after Tuesday".

What to send Cursor support

Cursor version and release track:
Operating system and hardware:
Local / Remote SSH / container:
Exact slow action:
Time to reproduce:
One repo or every repo:
Fresh chat result:
Small local folder result:
--disable-extensions result:
Top Process Explorer process:
Network diagnostics result:
VPN / proxy / managed network:
Selected model and Request ID:
Workspace file count and largest generated paths:
First version where the problem appeared:

Attach the smallest reproduction and say which single control changed the result. Avoid logs containing source or prompts your policy does not permit sharing. A screenshot of Process Explorer, extension activation times, and the network diagnostic is usually more useful than a screen recording of a spinner.

Questions people ask

Keep reading