The choice you were not offered

Most AI coding assistants arrive as a package: a subscription, a fixed model, and a small paragraph explaining that your code is sent to a server somewhere for processing. For a hobby project that is a fair trade. For a repository with a client's name in the schema, a regulated industry's data model, or an unannounced product, it is a negotiation that ends with the security team saying no. The gap is not about quality. It is about who decides.

Continue fills that gap by refusing to be a package. It is an open source extension that installs into the editor you already use, whether that is the common free editor or one of the commercial environments, and it connects to whatever model you configure: a hosted commercial model, an open model running on your own machine, or a private deployment inside the company network. The configuration lives in a file that travels with the repository, so what the assistant does is reviewable in the same way as the code it helps write.

What open actually buys

The first benefit is bargaining power. When the model is a configuration line rather than a subscription, prices and capabilities become something you can compare, and switching costs a minute. Teams that would never renegotiate a yearly contract will happily test three models in an afternoon and keep the cheapest one that passes their own evaluation, which is a healthier relationship with the technology than brand loyalty.

The second is that sensitive work stays where it belongs. Point the extension at a model running on the developer's machine and the code never leaves the laptop. Point it at an internal endpoint and the traffic stays inside the network. This is not a marketing claim about good intentions; it is a property of the architecture, and it can be verified by watching the network rather than trusting a policy document.

The third is that nothing about the workflow changes. Inline completion, chat about the open file, edits that use the whole repository as context, and custom commands written as reusable prompts all work the way they do elsewhere. The assistant also speaks the tool protocol that lets it reach external data sources, so connecting a documentation index or an issue tracker does not require a plugin for each.

What it costs you, honestly

The trade is real. A hosted assistant with a fixed model is a managed experience: someone else handles availability, context limits and the slow drift of model behaviour. Here you own those problems. A local model needs memory and a graphics card to be useful, and the difference between a large hosted model and a small local one is visible in the quality of suggestions, especially on unfamiliar code.

Configuration is another honest cost. The file is readable, which is the point, but it does mean somebody has to read it. In practice one person on a team sets it up once, commits it, and everyone else inherits the result, which is the same pattern as a linter config and just as unglamorous.

The point of an open assistant is not that it is free. It is that the decision about which model reads your code belongs to the people who own the code, and that decision should be changeable without asking a vendor.

Practical advice for a first week. Start with the local option to see how much quality you lose, because that number tells you whether the private route is viable for your work at all. Write the team's conventions into a custom command, since that is where most of the value sits once the novelty wears off. And keep sensitive repositories on an endpoint you control, because an open tool only delivers its advantage when it is used with the configuration it was chosen for.