Windsurf, now Cognition's Devin Desktop

Windsurf, now Cognition's Devin Desktop

Windsurf is a code editor built around an agent that reads the project, changes several files at once, runs commands, and reacts to their output. It differs from ordinary code completion by working in tasks rather than in lines. Since 2 June 2026 it goes by the name Devin Desktop, because Cognition gathered its products under one brand.

This product's history is unusual even for this industry, and worth knowing, since it explains why material from a year ago describes something other than what you get after installing.

Who makes it now

The company was previously called Codeium and shipped a free coding assistant. It then renamed itself Windsurf and released its own editor.

In 2025 something unusual happened. Google paid for a non exclusive licence to the technology and hired the chief executive, the other co founder, and part of the research team. The press put 2.4 billion dollars on that transaction. The company kept the product, the customers, and the remaining staff, but lost its leadership.

Days later Cognition acquired the rest, the company behind Devin, an autonomous coding agent. Terms were not disclosed, and the figure circulating in reports is around two hundred and fifty million dollars, so treat it as a press number rather than an announcement.

The direction after that change is legible. Windsurf stopped being a standalone editor competing on features and became part of a platform combining work inside an editor with an agent handling whole tasks unsupervised. The release numbered two shipped on 15 April 2026 and added a cloud agent reachable straight from the editor plus the Agent Command Center, a kanban view holding every agent session at once.

Windsurf is now called Devin Desktop

On 2 June 2026 the product was renamed, and it arrived as an ordinary update. Cognition gathered four things under one brand: Devin Cloud, Devin Desktop, Devin CLI, and Devin Review.

For writing code itself, little changes. The editor, extensions, shortcuts, workflows, and settings carry over automatically, plans and pricing stay as they were, and the JetBrains plugin kept the Windsurf name. What changes is what you do not see in the editor window. The application is now called Devin, meaning Devin.app on macOS and Devin.exe on Windows, so a corporate device management policy that only allows "Windsurf" will block it after the update. The surf command gave way to devin-desktop, though the old names still ship in ~/.codeium/windsurf/bin/. The Linux package is called devin-desktop, with windsurf left as a transitional dependency. Documentation and the changelog moved to docs.devin.ai.

The agent changes separately. Cascade gained a successor called Devin Local, sharing its engine with Devin CLI: it burns up to thirty percent fewer tokens on the same task, can spawn subagents, and runs in a sandbox with filesystem isolation and network filtering. New conversations start on Devin Local by default, Cascade stayed as the second selectable agent, and workflows and memories move across through a migration wizard. Billing is identical either way.

The practical consequence for you: judge this tool by releases from the last six months rather than comparisons from a year ago, since those concern a different product under a different name.

The agent, the heart of this editor

The agent, whether Cascade or Devin Local, is not a chat window beside the code. The difference lies in what happens after your instruction.

An ordinary assistant proposes a fragment you paste. An agent reads the files it needs, changes several at once, runs tests or a build, looks at the output, and fixes what failed. You see the changes as a proposal to accept rather than as a finished fact.

The gain appears on tasks spread across many files: adding a field to a model that has to travel through a migration, a data layer, the interface, and tests, or swapping one library for another in thirty places. That is mechanical work where a person errs from boredom and an agent does not.

The loss appears on tasks requiring judgement. An agent asked to "improve performance" will do something that looks like an improvement and not necessarily the thing that was needed. The more a task rests on choosing between solutions, the less use it is.

A practical rule that emerges after a few weeks: describe the outcome and the constraints rather than the steps. "Add order cancellation, keeping the existing service interface and adding tests to the neighbouring file" works better than a list of instructions, since the agent decides the order while you set the boundaries.

Code indexing and where context comes from

This is the element that most differentiates tools in this category and shows the least.

The agent does not see the whole repository at once, since it does not fit. It sees what the search system hands it, so answer quality depends largely on whether the right files reached the context.

On a large repository it pays to help. Naming specific files in an instruction beats hoping the search lands. Describing where the thing lives works similarly: a directory name in a sentence narrows the search more effectively than a more precise description of the task itself.

Project rules stored in a repository file form a separate layer. That is the place for naming conventions, the libraries in use, patterns the team avoids, and the language version. Without it the agent writes code that is correct and does not match the rest, and you fix the same things on every change.

Where those files live changed along with the change of owner, and that is worth knowing, since older guides point at what is now the fallback location.

.devin/rules/            preferred, takes precedence, one md file per rule
.windsurf/rules/         fallback, still read
.windsurfrules           legacy format, single file at the repository root
AGENTS.md                rules for a directory and its children, always on
~/.codeium/windsurf/memories/global_rules.md    global rules across all projects

Rules split into separate topical files work better than one long file, because the limit is twelve thousand characters per directory rule file and six thousand for the global one, and a shorter rule is less likely to be lost in context. Directory rules carry an activation mode in their header: always on, at the model's discretion, for files matching a glob, or only on demand. Rules from .cursor/rules can be imported.

# Data layer

- API calls go only through src/api/client.ts
- We do not use fetch directly inside components
- Network errors are handled by the wrapper, components receive a Result
- New endpoints ship together with a response type in src/api/types.ts

Know what leaves as well. Code from an open project reaches the model, so with a repository under a confidentiality agreement you check plan terms and file exclusion settings rather than assuming the defaults suit you.

What changes when an editor meets a remote agent

The direction set by the new owner comes down to joining two working modes that previously existed separately, and the difference between them deserves understanding.

Work in an editor is interactive. You see the changes, accept them one by one, interrupt when the agent heads the wrong way. The feedback loop lasts seconds, and you sit with the task throughout.

Remote agent work is the opposite. You describe a task, walk away, and return after tens of minutes to a finished change request. The loop lasts longer while consuming none of your time in between.

Those two modes suit different tasks, and that distinction is worth drawing deliberately. A change requiring a decision every few steps is wasted in remote mode, since the agent will make those decisions itself and half will not match your intent. A mechanical task, moving a hundred call sites to a new interface for instance, wastes your time in interactive mode, since you sit there clicking accept.

The practical route: tasks you can describe in three sentences together with a completion criterion suit remote mode. Anything needing supervision along the way stays in the editor.

Have a shared way of verifying the result too. An agent working unsupervised needs tests and type checking as a completion condition, otherwise the output has to be reviewed as carefully as interactive work, and the gain disappears.

{
  "scripts": {
    "verify": "pnpm lint && tsc --noEmit && pnpm test --run"
  }
}

One command gathering every check matters more than it looks. An agent told in the rules that a task ends only after this command passes will fix its own mistakes rather than hand back code that does not compile. A project without that layer is usually not ready for the remote mode, however good the tool itself is.

Cost and how to steer it

Billing in this tool category rests on usage rather than headcount, and that changes how you work more than it looks.

The main principle is simple: a task given to an agent costs what follows from the number of steps and the size of the context. An instruction pointing at specific files costs less than one forcing a repository search, since the agent need not read half the project to find a starting point.

The difference shows best in two phrasings of the same task.

Expensive: fix the cart bug, price does not refresh after adding a second item

Cheaper:  in src/cart/useCartTotals.ts the price does not recompute after a
          quantity change, check the useMemo deps, test in
          src/cart/__tests__/totals.test.ts

The second phrasing is not longer out of politeness. It removes the search stage from the agent, and on a large repository that stage often costs more than the fix itself.

The second principle concerns the model. Mechanical tasks suit a weaker and cheaper variant; tasks demanding reasoning suit a stronger one. Using the strongest for everything is the most common way to exhaust an allowance halfway through a month.

The third concerns session length. A conversation held over one task for an hour carries the whole context so far, so each further step costs more than the last. Closing a task and starting a new one is often cheaper than continuing to refine within the same session.

Look at usage after the team's first week. The distribution usually surprises: a few people generate most of the cost, and the cause is usually how instructions are phrased rather than the number of tasks.

The plans themselves survived the rename unchanged:

The quota refreshes daily and weekly rather than in one lump at the start of the month, so a day of heavy tasks does not eat the whole billing period. Once a paid plan's quota runs out you buy extra usage at API rates, so work does not stop, it stops being a flat fee.

Windsurf against the alternatives

The first two rows resemble each other most, and the choice between them rarely settles on a feature list, since both catch up with each other every few months. What usually settles it is which one hits the context of your particular repository better, and that can only be tested on your own code, in a week.

The fourth row deserves consideration if changing editors is a cost. A terminal tool plugs into any stack and does not force abandoning a configuration you built over years. You lose completion while typing and gain independence from one product.

Daily practice

A few things change effectiveness more than the choice of tool.

Work in small changes. A task touching three files can be reviewed; a task touching thirty gets reviewed only by somebody very determined, and an unreviewed change from an agent is a change nobody understands.

Keep a clean working tree before starting the agent. Automatic changes otherwise mix with yours, and reverting one without the other becomes awkward.

Tests change the whole dynamic. An agent that runs tests after a change and sees red fixes itself. An agent with no tests reports readiness and leaves the checking to you. That is the cheapest investment in this kind of tool's effectiveness.

Read what passes through. Generated code looks polished, and that is its most misleading property. Error handling, edge cases, and behaviour on empty data are where appearance and substance diverge most often.

The last point: not every task suits an agent. A one line fix you already know how to make takes less time than describing it.

It also pays to record the instructions that worked. A phrasing after which the tool landed on the first attempt is repeatedly useful in the same repository, and reconstructing it from memory two weeks later usually fails. A file holding such records next to the project rules speeds up the whole team more than any setting.

Common mistakes

The first is judging the tool from material predating the ownership change. The product went through a technology licence to Google, the departure of its leadership, acquisition by Cognition, and a rename to Devin Desktop, so year old comparisons describe a different stage under a different search term.

The second is tasks touching too many files at once. A change that cannot be reviewed enters the repository unreviewed, and that is debt rather than saving.

The third is having no project rules file. Without it the agent writes code that ignores the team's conventions, and you fix the same things repeatedly.

The fourth is running the agent on a dirty working tree. Separating your own changes from automatic ones then becomes a task of its own.

The fifth is working without tests. An agent with no feedback from a run cannot correct itself and pushes all checking onto you.

The sixth is skipping the question of what leaves. With code under a confidentiality agreement, plan terms and file exclusions need setting deliberately.

The seventh is running one session for an hour instead of closing tasks. Context grows with every step, so cost grows, and the effectiveness of fixes drops as the agent loses track of its own earlier decisions.

The eighth is assuming the agent knows the business context. It knows what it sees in files and nothing beyond, so a rule living only in the team's heads gets broken without warning. Anything that must hold belongs in the project rules or in a test.

FAQ

Who owns Windsurf and what is it called now?

Cognition, the company behind the autonomous agent Devin. The acquisition happened in 2025, days after Google bought a non exclusive licence to the technology and hired the chief executive and the other co founder along with part of the research team. The editor itself has been called Devin Desktop since 2 June 2026; the Windsurf name stayed with the JetBrains plugin.

How does Windsurf differ from Cursor?

In starting point. Both are editors with an agent that reads the project and changes many files at once, and feature differences blur every few months. What usually decides is which one hits your repository's context better, and you can only test that yourself.

Is Windsurf free?

There is a free plan with a light quota and a shortened model list. Paid plans start at twenty dollars a month for Pro and two hundred for Max, while the team plan costs eighty dollars per team plus forty for each full seat. The quota refreshes daily and weekly, and once it runs out you buy extra usage at API rates.

Does my code reach the model?

Yes, since the agent cannot work otherwise. With a repository under confidentiality, check plan terms, retention settings, and the file exclusion mechanism rather than assuming the defaults suffice.

Do I have to change editors?

With this tool yes, since it is a separate editor. If changing environments is a cost, Aider runs in a terminal and fits an existing configuration, and GitHub Copilot installs as an extension.

Documentation now sits at docs.devin.ai, the ownership change is covered in the Cognition announcement, and the rename in the Devin Desktop post.