The first practical question about Devin Local sounds deceptively simple: is it even on, and is it really the one running? In an ecosystem where the word "agent" stands for two different executors, the answer is not obvious, and the cost of a mistake is real edits by the wrong tool under the wrong permission model.
The naive move is to open a new tab and start writing the task, assuming that since the editor was updated, the agent under the hood is already the new one. The expectation is backed by a fact: new tabs really do pick Devin Local by default unless you have pinned another agent. It seems there is nothing to check. The illusion is reinforced by the interface and window layout staying the same: a familiar surface suggests a familiar executor underneath.
It breaks on the word "unless". Per the documentation, when Devin Local is unavailable the tab honestly falls back to Cascade - and does so silently. Availability does not depend on you alone: in Enterprise the agent is enabled by an administrator through team settings, while on a personal machine Devin Local must be explicitly turned on once in settings. Until that is done, a "new tab" opens the wrong agent, and the task goes to an executor with a different permission model. And this is not a rare edge case: the fallback fires silently exactly when you least expect it - on a fresh install, on a machine without the required subscription, on a tab opened before the agent was enabled.
The professional move is to enable the agent deliberately and once, by the documented procedure. Open the Command Palette (Cmd+Shift+P on macOS, Ctrl+Shift+P on Windows and Linux), go to Devin User Settings, turn on Devin Local on the Agents tab, and restart Desktop. In Enterprise, availability is granted by an administrator under Settings, Enterprise, Windsurf. After the restart the agent is ready - but that is not yet a reason to write the first prompt.
The second step is recognition, and it matters more than the first. The active agent is shown in the selector in the bottom-right corner of Devin Desktop. A glance there before the first prompt answers the question "who will run the task" with a fact rather than an assumption. It is a cheap habit: one second against an hour of figuring out why "the agent behaved strangely".
Why the fallback to Cascade was made silent rather than blocking. For the developer, continuity of work matters more than a strict refusal: better to hand over a legacy agent than to leave a tab without an executor. But continuity has a flip side - an implicit substitution - and it is removed by attention, not by hope. Devin Local shares the agent harness with the Devin CLI but runs inside Desktop with access to local files, tools and environment - so the substitution changes not cosmetics but exactly this pairing of permissions and environment.
The cost of inattention is concrete. An instruction written for Devin Local's permission model, landing in Cascade, will run under its modes and auto-execution rather than under your deny, ask and allow. And the reverse: a rule or memory from the Cascade era will not be picked up by Devin Local. In both cases the agent works honestly - just not the one you meant and not by the rules you meant, while you explain the result with a cause from the wrong layer. Untangling such confusion after the fact costs more than preventing it: logs and the diff will show what was done, but will not hint that behind the word "agent" at that moment stood a different executor.
A separate setting removes the ambiguity itself. Cascade can be hidden with the devin.cascade.enabled setting - then the choice narrows to a single executor, and the question "who is in the selector" goes away. That is reasonable on a personal machine where legacy processes are already migrated; where Cascade is still needed for old workflows and memories, it is too early to hide it.
You should verify the result of enabling by a different method than you used to do it. If you turned it on in settings, confirm it not by opening settings again but by a glance at the selector on a real tab. More precisely still - hand over a safe task such as reading a file and see the agent's name and the character of its requests in the approval card: if the card behaves by the deny, ask, allow model, you are looking at Devin Local, not at Cascade with its auto-execution switches. Two checks of different kinds - a glance at the selector and the card's behavior - are more reliable than one: the setting could have been saved but not applied until a restart.
The typical failures grow from a skipped glance at the selector. "My permission rules do not apply" - because the tab is run by Cascade. "Devin Local did not appear" - because in Enterprise an administrator did not enable it, or Desktop was not restarted. "The agent behaves as before" - because an old preferred agent is pinned, and the default does not affect it. The sign is the same: agent behavior is discussed without naming which agent is in the selector. Name it first, and most of these "for some reason" cases disappear before the task even starts.