Brief description: When an agent launches a subagent of a differing model and context window, that subagent’s context window gets reset to a smaller one mid-run. This is extremely catastrophic for long running tasks, as a healthy session can immediately turn into one that should be cancelled because of how much context is filled.
What I am using: I am defining subagents in cursor/agents. I am then asking an agent in a fresh session to act as an orchestrator, and it has a higher reasoning model like Opus. I am telling it to spawn subagents when it wants to delegate work. The subagent I am telling it to spawn is one configured to a 1M context window.
What happens
The subagent will start with the correct configuration. Then mid run, potentially multiple times, the context window will change to 300K.
Impact
This is making me seriously consider moving away from cursor as a development harness for our team. The orchestrator + delegation pattern is powerful, and our repository is large enough where 300k is not cutting it when agent is implementing on average.
Steps to Reproduce
Create a .cursor/agent subagent that’s model is fixed to Sonnet 5 with a 1m context window
Ask a fresh agent session that is a non-Sonnet 5 model, like Opus, to spawn the subagent
Subagent gets started with the correct context window (1M)
Mid run, subagent’s context window goes down to 300k
Expected Behavior
The context window that is set during the creation/spawning of subagent should never change. The model choice, reasoning level and context window should stay fixed.
Operating System
MacOS
Version Information
IDE: 3.19.19
For AI issues: which model did you use?
Orchestrator: Opus 5 Thinking 1M High
Subagent: Sonnet 5 Thinking 1M High
Hi @Mujahid_Maqsood Thanks for the post and thanks for the detailed report. I can confirm what you’re seeing.
Your Sonnet 5 subagents use the full 1M window during normal turns. The drop happens when a subagent runs a terminal command in the background and is automatically resumed after that command finishes. That completion turn uses a 300K window, which can trigger summarization if the existing context is already larger than that.
This is not caused by your subagent configuration. We’ve let the team know and are tracking the issue.
For now, you can reduce the likelihood of this happening by adding an instruction like this to the subagent definition:
Always run terminal commands in the foreground and wait for them to finish. Do not run terminal commands in the background.
If you see the window drop without a preceding background-command completion, please share the request ID from that affected turn so we can investigate that path as well. I’ll post here when there is an update.
Thanks a ton for the fast response. Do you know what the cons of the terminal commands running in the foreground vs background is going to be?
I have noticed that in addition to the terminal command limitation, this may also mean an Orchestrator can never resume a subagent. That kinda sucks because sometimes there is a small follow up you want to send to a subagent that already has context instead of paying for it again.
Do you know if there’s any prioritization on a fix for this? This is becoming a critical roadblock for us.
The foreground workaround trades concurrency for context stability: the subagent has to block on each build or test instead of doing independent work while it runs, and long-lived watchers no longer fit that path. Until the resume bug is fixed, I’d checkpoint the subagent’s contract, decisions, and current state before every handoff so a replacement can continue from durable state rather than paying to reconstruct the whole chat.
Hey, +1 on this. I have had long horizon chats spuriously lose context when I stop the main thread, and the agent has to recollect what is happening from inspecting its own transcript. It seems to be related to a separate bug with background agents / commands showing up as completed every time I stop the chat.