Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
I strongly suspect that Cursor continuously injects the system prompt into the context in order to avoid context drift, wording issues, or LLM hallucinations. From a context-engineering and prompting-architecture perspective, that is also the right approach, and I do not want to argue against it.
What is currently a problem is the flexibility around how the user can interact with system prompts. In other words, the user has no control over how often the system prompt is continuously injected into the context, which, depending on the architecture and how the user works, can lead to inefficiencies in the context and in the prompting architecture.
As a hypothetical example, let’s say you have a system prompt that is 3,000 lines long. I do not know how often Cursor continuously reinjects the system prompt. Let’s say that every time the user submits a new chat input, the system prompt is injected again. Somehow, it feels to me as though that is what is happening.
That would mean that, in an iterative process with an LLM that has a 1 million token context window, the system prompt may be reinjected 20 to 30 times, depending on the use case. In certain scenarios, it can be correct and appropriate for that to happen. However, depending on the architectural design of the system prompt and how it is structured, it can also lead to undesirable behavior. Efficiency, the task itself, and many other variables play into this.
What I would like is for Cursor to offer more specific configuration options for the system prompt. For example:
- Whether it is injected only once at the beginning
- What the timeout is before it is injected again
- At what interval it should be reinjected
- Similar settings that give the user more flexibility in this area
I would really appreciate it if Cursor MUST provide users with more control here, so the behavior can be adjusted depending on the architecture and use case.
I’m currently at a point where I’ve already had to rewrite my system prompt so that it effectively uses a kind of caching principle, or so that it is recognized through flag gating in the LLM’s internal reasoning process. The goal is for it to recognize when a system prompt has already been executed and not perform the same steps again.
The problem in the current system is that when the system prompt is continuously re-indexed and contains explicit requirements, the LLM starts processing those items again and again within its internal reasoning process, depending on the complexity and the reasoning model involved.
This leads to several issues:
- It reduces prompting efficiency.
- It can cause drift in the context, because it starts extending into other areas.
- It also has a financial impact, because beyond a certain point, depending on the context size, money is simply being wasted as the context is repeatedly re-indexed.
Very often, users do not notice this at all.
Because of that, we need more flexible options regarding the system prompt, specifically around when it is indexed, how often it can be indexed, and more settings in that area. This MUST be configurable more flexibly.
Steps to Reproduce
see desc
Operating System
Windows 10/11
Version Information
Version: 2.6.20
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Early Access
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.8.0-106-generic
Does this stop you from using Cursor
No - Cursor works, but with this issue