Coding assistants have become normal fast, and most people using them have very little idea what happens between typing a question and receiving an answer. Which files were sent? How much of them? What did the tool decide was relevant, and on what basis? The commercial products treat that as implementation detail, which is a reasonable product decision and leaves users unable to reason about why the assistant is helpful sometimes and useless other times. Continue is open source and its documentation has to explain those mechanics, which makes it an unusually good education in how these tools work. The context material is the most valuable part.
Everything an assistant does is downstream of what it can see, and the documentation covers context providers, how files and symbols are selected, how codebase retrieval works and how context windows constrain the whole thing. Once you understand that the assistant is working from a retrieved subset of your codebase rather than the whole thing, its failures stop being mysterious. It gave a bad answer because it did not have the file that explains the convention you were asking about. That single realisation changes how you use every tool in this category, including the closed ones.
Model flexibility is the practical differentiator and the docs handle it well. You can point the extension at a hosted frontier model, at a smaller open model running locally, or at different models for different roles, with autocomplete on a fast local model and chat on something stronger. Being able to switch and compare directly is genuinely educational. Reading that a smaller model is worse at code generation is abstract.
Watching it fail on your own codebase while a larger model succeeds is not, and the split role setup is a sensible pattern the documentation explains clearly. Explicit configuration is a virtue here. Your setup lives in a file you can read, version and share, rather than in a settings panel nobody else can see. For a team that means the assistant configuration can be reviewed like any other project decision, and for a learner it means the tool's behaviour is inspectable rather than magic.
The extensibility documentation is better than I expected. Custom context providers, custom slash commands and the interfaces for building them are covered with enough detail to actually build something. If you have a wiki, an internal API catalogue or a ticket system you want the assistant to know about, the path to that is documented rather than implied. The setup cost is the honest tradeoff.
Installing Copilot takes a minute. Getting Continue configured well takes an evening, involving model selection, API keys or a local server, context settings and autocomplete tuning. The documentation walks you through it capably and it is still substantially more work. Whether that is worth it depends on whether you value control and understanding over convenience, and both answers are legitimate.
Quality depends entirely on the model behind it, which is the thing to be clearest about. The extension is plumbing. Connect a weak model and you get weak suggestions, and no amount of configuration will rescue it. People who try this with a small local model on modest hardware and conclude the tool is poor have usually mistaken a model problem for a tool problem.
The documentation could be more direct about this than it is. Configuration format changes have caused real friction. The config structure has evolved across versions, meaning tutorials and forum answers written earlier no longer apply, and the failure mode is a config that silently does not do what you expect. Use the current official documentation and be suspicious of anything undated.
The local model guidance is where I would push back hardest. Running a coding model locally is presented as straightforward and the reality is that useful code completion needs a capable model, which needs substantial GPU memory, and that models small enough for modest hardware produce suggestions weak enough to be a net negative. That is a real constraint and the documentation is more optimistic about it than my experience supports. If you have the hardware, local models are genuinely good and private.
If you do not, be realistic rather than disappointed. Four point zero for documentation that teaches the mechanics of a tool category most people use without understanding, backed by an architecture open enough to make that teaching possible. The setup burden and the optimism about local models are the main things keeping it from higher.