I've been trying Cursor for the past two weeks on our main SaaS codebase. It's a pretty large TypeScript monorepo with several packages and a lot of dependencies.
I notice significant latency when asking for refactors or generating new functions. The "thinking" time can be 10-15 seconds, sometimes more, compared to almost instant responses in smaller projects. Has anyone else hit this? Is it the model context size, the LSP indexing, or something else? I'm trying to understand if this is a known constraint or if our project setup is causing it.
Yeah, welcome to the club. It's usually the Language Server Protocol indexing and the model trying to chew through your entire context. A 10-15 second "thinking" time on a large TS monorepo is, frustratingly, pretty normal for Cursor's current setup.
The main culprit is it's scanning and feeding your whole workspace to the model. Every time you ask for a refactor, it's pulling in all those `tsconfig.json` paths, node_modules references (even if it ignores them, it still parses the configs), and cross-package imports. The indexing is aggressive and not very smart about what's actually relevant to your request.
You can try a few things, but temper your expectations.
* Exclude huge directories like `dist`, `build`, and `coverage` from your `.cursorignore`. It helps a bit.
* Open a smaller, focused subdirectory of your monorepo as its own workspace instead of the whole beast. This is the only thing that's given me a real speed boost.
* Their LSP seems to choke on complex path aliases and barrel files. If you're using a lot of `@app/` style imports, that might be adding to the parsing load.
Ultimately, it's a known architectural trade-off they've made for "whole project" awareness. You get the context, you pay in latency.
Speed up your build
You're running into the classic context window tax. The 10-15 second delay is almost certainly Cursor's LSP gathering and tokenizing your entire project structure before sending it to the model, not just the model thinking.
What's often overlooked is the cumulative effect of your `tsconfig.json` paths and `baseUrl` settings. If you're using path aliases that map to deep directory structures, the LSP tries to resolve and include all those potential files in its context scan. I've seen cases where simplifying path mappings in a development environment shaves several seconds off the initial "thinking" phase.
Have you checked the Cursor agent's activity in your system monitor during this lag? You'll likely see a spike in a single core, which is the LSP, not the model inference.
- Mike