When a parent agent waits for sub agents a plan stops implementing in the UI

Support Bug Reports
, ,
1

Part of my “workflow” is a critical orchestration rule requiring that the model implementing a plan not code, and instead spawn sub agents.

Each sub agent must verify the task makes sense, implement, and check their work.

So sub agents are the ones handling the plan, and the parent model just checks things off along the way.

The problem:

When I click build on a plan, and it executes the plan in a chat, the parent model waiting on background agents to finish causes the UI to display that the plan is currently not building creating a confusing disconnect in the UI.

If sub agents are implementing a planned item in the same chat where the plan was being built, I’d expect the plan to still show that its being worked on.

This way I cant accidentally click it again stopping work, and killing the current run.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

On this topic, can we maybe also have a “implement” in new chat button or toggle in the plans drop down below use parallel agents? That uses the selected model for the plan in a fresh context?

If you think of a plan more as a “hyper-tuned” prompt, it makes sense you may want to plan with a frontier, then implement with a model like Grok.

The problem I see Cursor bumping into is that a plan is tied to a chat, and you can’t delete a chat only “archive” which is a big difference.

This means even if you have a plan, and archived a chat, that chat will come back to life when a plan is started. I think this is a “feature” of how you guys tie plans to a chat.

Simply having the option to execute a plan in a new chat saves me the cache miss of having a cheaper agent ingest the entire planning chat from the parent agent that planned it.

This is why I use sub agents currently, so I dont cache miss when building the plan.

I plan with a frontier, then “build” the plan with a frontier to keep the cache, but enforce cheaper models write code.

Its just a verbose way to start a new chat.

Could I pull the markdown from tmp and just prompt a new chat? Maybe? But from my testing I miss out on the UI bonuses I get from just clicking build, like inline todos, etc.

8

Hey @aidanhibbard. Two things here:

Choosing the build model already works - in Plan mode there’s a model picker next to the Build button (defaults to “Inherit”). Pin a cheaper model there and it implements the plan while you plan with a frontier. One caveat: it still runs in the current chat, so it won’t dodge the cache miss on its own.

Building in a fresh chat isn’t available yet - a plan is tied to the chat it was built from, so there’s no native “implement in a new chat” that only sees the plan. That’s a reasonable ask (fresh context for a cheap implementer, plus the native Build UI like inline todos). We’ll track this thread to gauge interest.

On the original point: the plan showing “not building” while sub-agents run isn’t intended behavior, and we’ve let the team know. Until it’s sorted, treat the chat as the source of truth - if sub-agents are still running there, the plan’s still being worked on, so avoid clicking Build again.

9

Hi @mohitjain ,

Thanks for the response!

I think my biggest current issue is what you said:

One caveat: it still runs in the current chat, so it won’t dodge the cache miss on its own.

That’s a reasonable ask (fresh context for a cheap implementer, plus the native Build UI like inline todos). We’ll track this thread to gauge interest.

I think even if it’s not popular (not a ton of users I’d imagine are pushing for this if I’m the first to bring it up.) It’s still technically the right way to avoid a cache miss, and right now we are locked into that cache miss. To that end, I’d call it a bug to not have a way to build a plan in a fresh CTX with a “grunt worker” model.

It’s not necessarily something people “want” but architecturally it’s a “proper design.”

  1. Select a plan model
  2. Use the yellow drop down menu to build in a new chat with the selected model
  3. “Re-tie” the plan to the new chat

That’s just my two cents though :slight_smile:

Thanks!