Skip to main content
There is no mode to pick before you send a request. The agent reads each message and decides whether to answer, ask for context, implement directly, or plan first. Two controls shape the work itself: sprints define a unit of work, and effort sets how deeply a sprint approaches it. Model selection chooses the models used for that work.

​
How the agent decides

To plan first, say so in your message, for example “plan the architecture before you build”. Review the plan in Plan, then ask for implementation. Planning never starts a build on its own. In the CLI, /plan keeps your next messages on the plan (flows, spec, roadmap, architecture) and runs no code; it returns to automatic behavior once the plan lands, and /auto returns immediately. /plan needs a paid plan. The web app has no Plan toggle.

​
Choose a unit of work

For a small change, describe it in chat. Use a dedicated sprint for a defined feature:
A sprint runs in a new session. In projects with a roadmap, the sprint controls can build the next planned task or continue through the roadmap on Autopilot. Follow the session that owns the run. Parallel work, queuing, and admission limits depend on the client and account; sending another message does not guarantee that it starts immediately.

​
Sprint effort

Set effort with /effort before launching the sprint. Higher effort can involve more model work and credits. Effort controls the workflow; it does not promise a particular duration or result.

​
Review the outcome

Builds that change code end with an independent verification of your acceptance criteria. State the checks you need in the request, for example type checking, a specific test suite, or a browser journey, and read the diff before shipping.