I’m currently at around 45% of the context window and want to start sub-agents. I have detailed prompts that pass large handoff reports to the sub-agents, but the sub-agents aren’t starting. I assume there may be a limit on the spawn context. Could the Cursor developers please confirm whether there’s a limit on how much can be passed to sub-agents?
I hope there isn’t one. If there is, it would obviously be incredibly limiting. I assume that if I spawn a sub-agent using the same model as the orchestration agent—for example, with a one-million-token context window—I should be able to pass it 800,000 tokens if I wanted to, right? Of course, the orchestration agent’s original context window would need to have enough room, but that’s definitely the case here. The example above was only hypothetical, but I think you understand what I’m getting at.
Is there a limit? If so, how large is it? If not, why isn’t this working?
Or is this related to the issue here with the response limit, since the orchestration agent is trying to generate a response for the subagent that has reached the limit?
not cursor staff so i can’t confirm the exact limit, but even if there’s room i’d avoid passing big handoffs inline. the orchestrator has to generate the whole handoff as output tokens, and output limits are far smaller than the context window, which fits what you’re seeing with the response limit.
what works better for me: have the orchestrator write the handoff to a file in the repo (something like handoff/task-1.md) and spawn the subagent with a short prompt that points to it. it’s faster and cheaper, and when a subagent goes wrong you can open the handoff and see exactly what it was given.
Hey, thanks very much for your response and the tip—I really appreciate it.
Regarding the thread above, it also isn’t possible to save large hand-off reports to a single file because of limits in tools such as Kimi or GLM. For example, if you try to save a file with 8,000 characters directly, you hit a limit and have to use the append mechanism to write the file in segments. More details are in the thread above.
As for prompt efficiency, whether it’s better to save the content to a file or pass it along is a separate question. From the harness perspective, there shouldn’t be any complications if you want to do this, even when a limit is involved.
I think this is a combination of the response limit mentioned in the thread above, which the Cursor developers have already confirmed exists, and possibly more general orchestration issues when larger hand-offs are passed along. Either of these could be the main underlying problem.
I can’t reproduce the issue consistently, though. I’ve had sessions where I followed exactly the same procedure and didn’t encounter it. I noticed it when I tried to start multiple agents in parallel, even after asking for them to start sequentially. It’s hard to say whether this is a persistent issue related to size.
ah that makes sense, some models cap how much the write tool takes per call. what helps there is splitting the handoff instead of appending to one big file: the orchestrator writes it in sections, each under the limit (handoff/task-1/01-context.md, 02-plan.md and so on), plus a short index file listing them in order, and the subagent prompt just points at the index.
bonus: the shared context section can be written once and reused across several subagents, so each spawn only needs its task-specific part.
Hey, thank you very much for the tip—I really appreciate it.
Even if it’s more efficient to create HCOA step-by-step plans and handle things differently with the orchestrator, that isn’t the main issue. I appreciate the workaround as a solution, but the primary concern is that there are limitations that shouldn’t be there.
If an end user wants to pass 8,000 lines to a subagent, they should be able to. Similarly, a file should be saved directly, without the end user having to worry about using a segmented append mechanism and explicitly directing agents to it.
Hey, thanks for the detailed write-up and the follow-up.
First, here’s how the handoff works. Sending a prompt to a subagent doesn’t copy it from the context window. The orchestrator generates the entire handoff as output in a single response, and the per-response output limit is much smaller than the context window. So even with a large-context model, you can’t pass hundreds of thousands of tokens in one subagent prompt. You hit the response output limit, not the context limit. That’s how the handoff currently works, and your guess about the response limit is generally right.
There’s a separate issue: very long handoffs can sometimes be truncated or invalid. When that happens, the subagent may show something like “Couldn’t start” instead of launching. We’re tracking that issue, and I want to distinguish it from the limit above.
I also understand your point that these limits shouldn’t be there, including the need to split large files into parts when writing them with some models. I’ll pass that feedback to the team. It’s a reasonable request.
To look into your specific case, could you send me:
The exact text shown on the subagent line when it fails, such as “Couldn’t start”, and any error message nearby
The Request ID for the failed attempt. In the chat menu, go to “…” > Copy Request ID
The model selected in the main chat
The email address you use to sign in to Cursor, shown under Cursor Settings > Account. It may be different from your forum email. Please also check whether the selected model is available on your current plan, since some models require a specific plan and may fail to launch otherwise.
With that, I can tell whether you’re hitting the expected output limit or the subagent launch issue. Let me know what you find.
