We humans use our knowledge according to the needs of the task. Agents can work the same way. There is no need to resend the entire context in every round. The solution is simple: just avoid sending more context than the current prompt — perhaps two or three turns at most. If the agent needs to remember something, it can simply read from a memory vault, like the one in my editor.
That would be much more interesting and useful to the user than disabling thinking — which, in my case, simply results in twice as much explanation. lol.
And I can actually see this in practice: on Cursor, my basic subscription lasts about 3 days with constant use; in my editor, the same subscription lasts about 5 days. hehe.
I’d keep the current goal, constraints and unfinished actions in a small always-present working state, and pull older evidence from the vault on demand. With only two or three turns, the tricky case is a dependency the latest prompt doesn’t mention: the agent needs enough of that working state to know what to look up. To test the savings, I’d replay the same tasks and compare completion quality and total billed usage, including memory reads and retries—not just how many days a subscription lasts.
I’ve been in a testing phase ever since I started using Composer/Grock within my environment to edit the environment itself. While operating, the agent detects issues, bugs, and the like, suggesting fixes in its report. I’ve tested thousands of prompts, repetitive tasks—you name it—and I have statistics on all the models; I know the profile of each one. And yes, less context means cost savings; regardless of the task, the biggest expense comes from context usage. I’ve been working on this editor of mine for 15 months, and I haven’t used Cursor for editing in about five months—the difference in the environment is stark. I can’t bring myself to use any current IDE anymore.
That’s essentially what I’ve already implemented and tested extensively in my editor. I’m not proposing that agents should have no working state — only that the persistent context should stay very small. In my setup, I typically send just the current prompt plus 2–3 turns. When older context is actually needed, the agent can retrieve it from a memory vault on demand.
The important part is that the agent doesn’t need to search the entire workspace to discover where something might exist. The user already knows the coordinates and provides them: source → destination → intent. The agent only retrieves what is necessary and performs the adaptation.
I’ve run this workflow extensively in real tasks. In my own usage, the same basic subscription has lasted roughly 3 days with constant use in Cursor versus about 5 days in my editor. That’s not a controlled benchmark, of course, but it was enough to make the effect very noticeable.
Hey, thanks for the detailed feedback. The idea of keeping persistent state small and pulling the rest from a memory vault on demand sounds totally reasonable. I’ll pass it to the team as a suggestion for context management.
A couple of things you can already use in this direction right now:
Rules and AGENTS.md are a good place for a compact, always-available working state like goals, invariants, and key coordinates. The docs recommend linking to files instead of copying their contents, so the context stays short and doesn’t go stale: Rules | Cursor Docs
On measuring impact, I agree with @izgorodin above. It’s better to compare completion quality plus total billed usage, including memory reads and retries, rather than how many days a subscription lasts. That makes the effect of trimming context much clearer.
I’ll pass the proposal along to the team: minimal persistent state plus retrieval on demand as the agent’s default behavior. If you want, we can also spin this into a separate thread in Feature Requests so it’s easier to track.
@Anderson_Pereira — agree that “send the whole history every turn” is the expensive failure mode. The pattern that has held up for me on long Cursor projects is closer to what you and @izgorodin sketched: a tiny always-present working state, plus a vault you pull from only when the prompt needs it.
Practically:
Keep 1 short alwaysApply / AGENTS note with current goal, hard invariants, and “before X, retrieve Y” — not the project novel.
Put evolving architecture in Markdown notes with Decision / Rejected / Status / Supersedes (amend the live record; don’t append a contradictory twin).
In a fresh 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.
Dean’s point on linking to files instead of pasting them is the same idea: short working state, on-demand evidence. Happy to compare how you’re deciding what belongs in the vault vs the 2–3 turn working set.
Disclosure: I work on agent-memory infrastructure. I’d refine my earlier wording: I see working context as a projection of the world model for the agent’s current situation and purpose, not a fixed checklist of goals, constraints and next steps. Ideally, that projection is rebuilt for every invocation, selecting what matters for that run; the latest decision may belong in it, but it isn’t a mandatory field.
This is already a reality in my system; look at the example below, which proves that the old session context does not interfere with the quality of the path. In this 84-turn chat, for every turn, I sent only the four preceding turns and the current prompt. I decide how many turns to send, and I can confirm that the savings are significant.
What I’m interested in is how the context is rebuilt for the current task, rather than a fixed set of working-state fields. Your screenshot separates Memory Vault from Conversation: is that vault slice selected afresh for each invocation, or kept stable across the session?
It remains consistently stable. The agent uses “read” to access the “Memory Vault” when I request a review of past turns or when it determines on its own that it is necessary. In many cases involving more than 50 turns, it doesn’t even need to read the “Vault.”
I meant rebuilding the context for the task, not the archive itself. I don’t want an outdated decision in every prompt. But if I ask why we changed course, I want to see it alongside the decision that replaced it.
In an 80-turn chat—in my case—there are file paths across various unrelated files. Now, if in your case all the files in a section are related, that’s a completely different story. For that scenario, my system has a “Safe editing” feature where the agent stays within scope and only edits related files. So, there are two different cases.
@Anderson_Pereira — the 84-turn / four-preceding-turns result is the clean evidence for “history is not working state.” Stable vault + agent read when needed matches what I’ve seen hold up: most turns never touch the vault once the current goal and hard invariants sit in a tiny always-present note.
Edward’s rebuild-projection point still matters for the failure mode you called out in #16: unrelated paths across a long chat. When a section is tightly related, your Safe editing scope is the right gate. When it isn’t, the cheap check before an edit is a why-retrieval that must cite Decision + Rejected (or explicitly mark none), so an outdated decision doesn’t ride every prompt but still shows up when someone asks why course changed.
Curious how you decide “agent should read the vault on its own” vs wait for the user to name coordinates — that’s usually where the savings and the missed dependency trade off.
It happens somewhat automatically once the agent determines that the user’s current request does not correspond to previous tasks found in the conversation history. Alternatively, if I explicitly ask it to correct or review “PR 30,” for example, it accesses the vault, retrieves the PR number, prompt, and commit hash, executes the command using that hash in the terminal, and thereby obtains exactly what was edited in that PR.
@Anderson_Pereira — that split is useful: (1) automatic vault read when the current ask doesn’t match prior tasks in history, and (2) explicit coordinates (“review PR 30”) that pull PR number → prompt → commit hash → terminal diff.
The PR→hash→git path is the cleanest “working state is addressable” example in the thread. Conversation history alone rarely reconstructs that chain without you naming the PR.
One failure mode I’d watch on the automatic branch: false “new task” detections that skip vault when the ask is a continuation with new wording. If you’ve got a case where mismatch-detection stayed quiet and you had to name the PR anyway, that would pin where the heuristic needs a nudge vs a hard coordinate.
Hey, great thread. Thanks for continuing to share implementation details. The breakdown between automatic vault-read when it doesn’t match the history vs explicit coordinates review PR 30 → PR number → commit hash → diff is really clear.
Suggestion on context management, minimal persistent state plus retrieval on demand, seems reasonable. I’ll pass it to the team as feedback. I can’t give an ETA for it though.
What you can already apply in this direction right now:
Rules and AGENTS.md are a good place for a compact, always-available working state goals, invariants, key coordinates. The docs suggest linking files instead of copying their contents so the context stays short: Rules | Cursor Docs
On-demand retrieval via MCP is exactly the pattern you’re describing.
And since the discussion has picked up, I can move it into a separate thread under Feature Requests, that’ll make it easier to track. Let me know if that’s OK and I’ll move it.
There is a nuance here: the system queries the vault if it determines that the current prompt relates to previous interactions that aren’t visible in the active chat session. In those instances, the query happens automatically. However, this only occurs if I limit the input to just the current prompt. To mitigate risks, I might include, say, the four previous turns along with the current one. This system gives me full control over the context without compromising the quality of the output—something I can attest to after more than six months of using it with actual development prompts. It is no coincidence that I stopped using Cursor for development during that same period.
Great, then I’ll move the thread to Feature Requests so it’ll be easier to track and pull in updates.
The proposal is already with the team: minimal persistent state plus retrieval on demand as the agent’s default behavior. I can’t give an ETA, but if there’s any news in this direction, I’ll reply right here.
Thanks for laying out your approach in such detail, especially the chain PR 30 → PR number → commit hash → diff. It’s a clear example of why the working state needs to be addressable, not something that lives only in chat history.
