Skip to main content
Keep building without waiting: while the main task runs, you can still send new asks. Larger work can be split into background subtasks. Prefer Task view / the Tasks tab for progress (as shown in product).

​
Everyday analogy

Before: often only one crew could work; you waited for them to finish before sending the next message. Now: heavy work can stay with background crews while you keep talking in the main chat.

​
What the system actually does

It may feel like “just more parallel sends,” but under the hood:
  • Splits work: in Build, the main agent can assign implementation work to background workers in parallel by feature
  • Crews run alone: each subtask has its own progress and does not freeze the main chat
  • Reports back: when a subtask finishes, it reports to the mainline and merges results into the project
  • Chat stays open: while subtasks run, you can still ask new things; you may see “still generating in the background—you can keep talking”
  • Progress is visible: the activity panel prefers Task view / the Tasks tab; a running overlay can list session tasks; in-progress feature lists mirror into Task view
  • Stop runaway work: you can stop background tasks that are stuck or drifting, so they do not hold resources for long
  • Clearer failures: when a background task fails back to the mainline, you get more readable reasons (for example insufficient balance or unstable service)
  • Collaboration stays separate: tasks are tied to who started them; others generating show as “Collaborating,” reducing accidental stops
  • Queues are explained: planned execution goes through a shared queue; queued items should not be edited by mistake; when capacity is tight, your turn includes an explanation
One line: not merely “send more messages,” but split, parallelize, report back and merge, show progress in Task view—and keep multiplayer work from stepping on each other.

​
Main task vs subtask

Remember:
  • Main task = commander + main conversation
  • Subtask = parallel background crew

​
When something becomes a subtask

When the ask is large, separable, and better done slowly in the background, the main agent may spawn subtasks so you can keep asking other things (as shown in product). Flow in plain words:
  1. You send a message (or the agent judges a piece fits background work)
  2. The main agent starts a subtask
  3. The subtask advances on its own; you can keep chatting / asking in the main thread
  4. Open Task view / the Tasks tab for progress; stop a background task if it drifts
  5. Subtask finishes → reports to the main chat → results merge into the project when possible
Spend detail follows in-product billing. Prefer Task view for task progress; the billing view may be simplified and may not list every subtask line.

​
What if several people send similar asks?

In shared projects, the system tries to bill and track by who started the work: Separate by person
A’s main/subtasks stay with A; B’s with B. Progress, stop, and spend stay per person so you do not stop the wrong run. Someone else generating → “Collaborating”
You can see a teammate’s work is still running. Similar ≠ auto-merged
Two people each say “make the button red” are usually two independent requests—not secretly one job. May use resources twice
Duplicate similar work can cost twice. Agree who changes what before both edit the same spot. Your own back-to-back asks
  • Subtasks in background, mainline free → often you can keep asking (with a parallel hint)
  • Mainline still busy / queued → you may enter the queue; when it is your turn, you get an explanation
One line: collaboration is tracked per person; similar asks are not auto-treated as one job—coordinate first to avoid redoing the same work.

​
Big picture

​
Value in one line

Before: one generating reply often meant waiting. Now: heavy work runs in the background while you send the next ask and watch Task view—like a team that can assign work, not a counter that takes one ticket at a time.

​
FAQ

Not necessarily. After async assignment, the main agent may look idle while background crews work. Open Task view / the Tasks tab first; if subtasks are still running, you can keep asking in the main chat.
Usually no. The main agent often dispatches them when background work fits. You keep sending normal asks in the main input.
Not always. Ending the main task does not mean every subtask finished or every report merged.
Often yes. When the mainline is free you can still ask; the product may note background generation. If the mainline is busy or queued, you get an explanation when your turn starts.
Yes (entry points as in product). Use it when work is stuck, drifting, or no longer needed, so it does not hold resources.
Long jobs are often advanced in multiple background rounds. Each step may re-read context and call tools, so more rounds cost more. Review the plan and scope before running, and watch in-progress subtasks in Task view. Final billing follows the bill and in-product copy.
The system tries to separate progress, stop, and spend by who started the work. Others generating show as “Collaborating,” reducing accidental stops.
Usually no. Work continues in the cloud. While parallel subtasks run, status may not be fully written back yet—refresh helps you see the latest. See FAQ.