Choosing an AI Coding Setup: IDE, Terminal or Cloud

Three architectures, not ten products

The market looks crowded, but there are really only three families.

IDE-based. The agent lives in your editor. You see what it does, the diff is right there, git checkout is one keystroke away. This is the smallest jump from your usual way of working, and the easiest to undo.

Terminal- or CLI-based. The agent runs in a shell, on your machine, in your working directory. It is editor-independent, scriptable, and can be put into CI. In exchange it shows less of its own accord: what you do not ask about, you do not see.

Cloud, asynchronous. You pick a repo and a branch, the provider copies it onto a virtual machine, the agent makes a plan, works, then commits to a branch and opens a pull request. You do something else meanwhile. Whatever it breaks arrives as a PR.

The three are not alternatives to one another — most serious teams have all three, for different jobs. The choice is not "which one", it is "which one for what".

What changed in the summer of 2026

Two events that say more about the market than any feature list.

A product name disappeared. On 2 June 2026 the maker of a well-known AI editor announced the next generation — under a new name. The upgrade arrived as an ordinary automatic update; the subscription, the pricing and the extensions all stayed the same. The agent engine was swapped out too: support for the old one ended on 1 July 2026.

A tool changed hands. The maker of another popular AI editor was acquired by a large technology company; the transaction closed on 14 August 2026, and the tool moved into the acquirer's AI unit. (We know this from financial press sources, not from a statement by the parties.)

The lesson is not "do not choose a tool". It is that the exit cost has to be planned in: the product name, the owner and the pricing can all change within a year. What is worth protecting: keep your project instructions, your working method and your processes tool-independent. That part is what the project instructions post takes further, in practice.

The price is no longer one number

Three different pricing models are competing at once, and they cannot be compared in a single table:

• Flat monthly fee. Simple and predictable, but the limits are hidden somewhere else.
• Credits or an allowance. You get monthly credits and pay separately for overage. On enterprise plans the credits often go into a shared pool rather than being per head.
• Rate-limit window. No credits; N requests within a given time window. This is the hardest one to plan for.

What is true of all three: the list price is not the total cost. The annual list price for a team of ten currently ranges from roughly $2,300 to $7,100 for the same work, depending on the plan — and that does not include overage. (Our own calculation, using September 2026 list prices, before tax.)

One concrete example of how far from simple the picture is: at one large provider, the data residency and compliance option means a 10% surcharge in the model multiplier. That shows up nowhere in the monthly fee.

The repo indexing argument looks settled

For two years the question was how an agent finds code in a large repo: a semantic index (a database of embeddings) or fast text search.

By 2026 the balance has tipped towards the second. According to one large IDE's own documentation, their codebase indexing is not embedding-based but a search engine of their own, which on large codebases outperforms even the established fast text search, with no configuration. Alongside it, the models' context window has grown to one million tokens.

This has a consequence that is not obvious: it is why the terminal agent suddenly became competitive with the IDE. If no separate index has to be built for the agent to find the code, then the editor's infrastructure is no longer an advantage.

On the enterprise side, a small detail that can cost a lot: at one provider, codebase indexing is included only in the top enterprise plan — the middle business plan does not have it.

Who trains on your code? — it differs by plan

This is the most important section of this post, because it is concrete, checkable, and most teams have it wrong.

The pattern that repeats at every large provider: the individual plans have the least favourable defaults, and the enterprise plans the best ones.

• At one large provider, on the individual plans the provider may use usage data for model training (there is an opt-out), while on the business and enterprise plans the documentation states in as many words that it does not train on them. The intellectual property indemnity, too, only starts at the business plan.
• At another provider, on the consumer plans training happens if the setting is switched on — and then the retention period is five years; if it is not, thirty days. Code and prompts sent under the commercial terms, on the other hand, are not used for model training, unless the company joins a separate partner programme. Zero data retention has to be enabled separately, per account, and is not a default part of the enterprise plan.
• And there are providers that offer zero code retention, source attribution and indemnity as well, together with a fully isolated deployment.

And one item that barely gets discussed: the local cache. One terminal agent stores conversation transcripts in plain text in the user folder, for thirty days by default. The retention period is adjustable. If you work in a regulated environment, that directory is as much an audit item as any cloud service — it is just that nobody knows it is there.

Where the data is

There are three solutions, in increasing order of strictness:

1. Data residency at the provider. One large provider has offered a US and an EU data boundary (EU + EFTA) since 13 April 2026. Two things are important to know: it is off by default and the enterprise admin has to switch it on, and it means a 10% surcharge in the model multiplier.
2. Inference running in your own cloud. Through the model platforms of the large cloud providers, the code never leaves your own environment.
3. A fully isolated deployment. An air-gapped variant exists too, with no outbound network at all.

Open-source agents offer a separate route: they can be run on your own machine, with whatever model backend you like. In exchange, the setup and the maintenance are yours.

The decision skeleton

1. WHERE DOES THE CODE RUN?
   on your machine (IDE / CLI)  vs.  the vendor's VM (cloud agent)
   -> a security, a speed and a working-method decision at once

2. WHEN DO YOU LOOK AT IT?
   synchronous (you watch live)  vs.  asynchronous (a PR arrives)
   -> the cloud agent pays off if you do SOMETHING ELSE meanwhile

3. HOW MUCH DOES IT ASK?
   the approval model is the "how much do I trust it" dial
   -> on an unfamiliar codebase always start with the strictest

4. WHO TRAINS ON YOUR CODE?
   it differs by plan. The individual plan's default is
   typically the worst one. READ IT, do not assume it.

5. WHERE IS THE DATA?
   data boundary (opt-in, surcharge) / your own cloud / air gap
   + the LOCAL cache that everyone forgets about

6. WHAT IS THE EXIT COST?
   if tomorrow it gets a new name or a new owner: how much
   of your work goes with it? Project instructions and
   working method should stay tool-independent.

What to pick if you have to decide now

• Alone or in a small team, on an existing codebase: start IDE-based. It is the smallest jump, and the diff is in front of your eyes.
• If a lot of the work is repetitive and scriptable: the terminal agent is more efficient, and it can be wired into CI.
• If you have well-described, boring tasks that are not urgent: the cloud agent pays off where the parallelism is the gain — you do something else meanwhile.
• In a regulated environment: the order is reversed. Settle points 4 and 5 first, and only then look at the features.

Common misconceptions

• "I will pick the best one and be done." The field is reshuffled in six months, and within a year even the product name can change. Choose an architecture, not a brand.
• "The monthly fee is the cost." There are three different pricing models, and overage, the credit pool and the compliance surcharge are in none of them.
• "They do not train on my code, I am paying for it." Paying does not settle it on its own. The type of plan settles it, and the individual plans typically have the least favourable defaults.
• "If there is no data in the cloud, there is no risk." The local conversation transcripts can sit on your machine in plain text for weeks.
• "Data residency is on, we are on an enterprise plan." At one large provider it is explicitly off by default, and has to be switched on separately.

What to take away

There are three architectures, not ten products: the agent runs in your editor, in your terminal or on the provider's virtual machine. Do not let the feature list decide — let four questions decide: where the code runs, when you look at it, how much it asks, and who trains on it. The answer to the fourth one has to be read, because it differs by plan — and because most teams have it wrong.

Which of the three working modes to use when is what the three modes of AI coding post sorts out, mode by mode; picking that first real task is the subject of the first task with an agent post, with numbers.