When there are several surfaces, the first practical question is where to run a specific task. The temptation is clear: take the most powerful surface, or the one that is already open. Both are a choice by habit rather than by task, and it is exactly that choice which later turns into extra cost and an extra radius of error. The sign that the choice was made by habit is simple: the surface is named before the task and its result are.
It seems logical: since Devin Cloud is more autonomous than the Editor, let it do everything - less thinking about where to run what. Or the reverse: since the editor is already open, it is convenient to run both pointed and long work in it. Both strategies save the decision now and create the problem later.
It breaks on the fact that autonomy is not free power but a trade. The wider a surface's permissions, the greater not only the speed but also the radius of error, the cost of verification and the number of external effects. A powerful surface on a small task spends your attention and tokens where an inline edit would have sufficed; a weak one on a large task forces you to split by hand what the environment would have done on its own. The difference between levels is not only speed but also how much of the outside world the agent can touch in a single turn.
Hence the rule of minimal power: start with the narrowest surface capable of finishing the task, and step up a level only when the narrow one stops being enough. This is not asceticism for its own sake but a way to keep verification cheap: the narrower the environment, the less you have to prove afterward.
Laying this out by task is simple. A single local edit with a clear diff - Command or Devin Local. Exploring unfamiliar code without changes - DeepWiki, Codemap, Ask or Plan. A multi-step local task - Devin Local in a separate worktree, so as not to touch the active branch. Hours of autonomous work with the laptop closed - Devin Cloud. A need for a specific agent ecosystem - ACP, after checking the provider. An old workflow or memory - temporarily Cascade, then migration into a skill or a rule.
Stepping up the levels is not a sign of error but a normal move, as long as it is controlled. It is reasonable to start with Ask or Plan while the scope is unclear, and switch to Normal once the goal is defined. It is reasonable to start in a worktree and move to the Cloud once it is clear that the work is long and does not need your machine. What is bad is not raising autonomy itself but starting at the ceiling: while the unknown is not yet resolved, a wide surface only increases how much you will have to prove afterward without bringing the result closer.
Each step up adds something you will have to verify. An inline edit is verified by reading the diff. Devin Local - also by permission decisions and a test run. A worktree - by a merge and a re-check in the target branch. The cloud - by environment setup, secrets and the network policy of someone else's VM. Stepping up, you agree to this extra work deliberately, not after the fact. It helps to ask in advance whether you are ready for that verification now; if not, the task is asking for a lower surface or better preparation.
Before launching it helps to answer three questions and write the answers down. Which single task you are solving and which surface you chose. What result will be proof of completion - a concrete diff, a green run, a reproduced scenario. Which action the agent must not perform without you - deploy, writing to .env, changing the data schema. Three answers take a minute and define both the boundaries of the task and the way to close it.
These three answers are not a formality. The named surface fixes whose environment this is and what permissions hold in it. The named proof separates the claimed result from the actual one - without it "done" stays a word. The named forbidden action is a future permission deny or sandbox, not a good wish in the prompt. Together they turn the choice of surface from a habit into a decision you can explain and check.
You should check the choice by the same criterion by which you made it: did the narrowest of the chosen surfaces close the task fully and cheaply. If you had to step up a level, it is good that the step was a deliberate move, not a starting position. If the narrow one was enough, you saved both time and verification.
The typical failures are two-sided. On one side, over-autonomy: a heavy surface is launched on a task where Command would have sufficed, and paid for with attention and tokens. On the other, under-isolation: large multi-step work is run in the active branch instead of a worktree, and then a mixed diff is untangled. The sign of both is the same: the surface was chosen before the task and the proof of its completion were named. Name them first, and most of these failures simply do not happen.