Projects Context Usage

I just started using cursor after their introduction of the “Projects” feature. What I got from reading over the internet is that a Project is supposed to help you work on a certain project for weeks or even months, but it seems like after one day the context window for the main chat (orchestrator) is getting pretty full. I thought I would be able to start a new main chat and continue working from there using the context saved onto the project files, but I can’t quite figure out how to either clear the context window for the main chat or start a new one.

Am I misunderstanding how Cursor Projects work or am I using it incorrectly?

I have the same thoughts. The context of my orchestrator has gone above 100% so it doesn’t get compacted automatically either

@mofen — you’re not misunderstanding the “weeks/months” intent; the missing piece is that Project files and the orchestrator chat are different layers. The chat still fills (and then compresses). Project-saved notes don’t auto-rebuild a fresh main chat’s working memory unless you pull them in on purpose.

What has held up for me on long Cursor projects:

  1. Treat the orchestrator chat as a short working buffer, not the archive. When it’s getting full, start a new main chat rather than fighting the window.
  2. Keep a tiny always-on note (Project file / AGENTS / alwaysApply) with current goal, hard invariants, and “before X, retrieve Y” — not the project novel.
  3. Put evolving architecture in Markdown notes with Decision / Rejected / Status / Supersedes. When a decision changes, mark the old one Superseded and point to the new id — don’t append a contradictory twin.
  4. Five-minute test in the new chat: ask a why-question that needs Decision + Rejected + what it replaced, and make the agent cite the note path. Same-session answers don’t prove the vault.

If clearing/starting a new main chat inside Projects is still unclear in the UI after that, that’s useful product feedback too — happy to compare how you’re organizing the Project files vs what you expected the orchestrator to retain.

Hey, thanks for the question, and yep, you’re using Projects correctly. There’s no misunderstanding here.

The main chat coordinator uses the same context window as a normal chat on the selected model, so the counter goes up as you chat. But you don’t need to clear it or manually start a new one. When the window gets close to the limit, the coordinator automatically summarizes the older part of the conversation and keeps going. In the context counter you’ll see a “Summarized conversation” section. There isn’t a second main chat inside a single Project by design. It’s one coordinator per Project, and with auto-summarization you don’t need another one.

What helps keep the main chat lightweight for weeks or months:

  1. Let the coordinator delegate. Hand off heavy work to agents it launches. Each agent gets a fresh context window.
  2. Store long-lived knowledge in the Project files in the Context tab. notes.md, docs, plans. They survive summarization, and the coordinator can reread them.
  3. If you want to compress things manually, type /summarize or /compact in the main chat while the coordinator is idle.
  4. The counter depends on the selected model. If it fills up too fast, pick a model with a larger context window for the main chat.

@argarcia-ottersoft If your counter shows over 100% but the coordinator still replies, it’s probably just how the UI measures it relative to the model, and the real window is larger. If the coordinator actually stops replying once it’s full, let me know and include the Request ID right top chat menu > Copy Request ID plus your Cursor version, and I’ll take a closer look.