The reason to self-host a coding assistant is rarely cost. It is a sentence in a security review: source code may not be sent to a third party. Once that sentence exists, the hosted options are out and the question becomes what to run instead.
Three pieces make a workable stack: a completion server, an editor client that can point at it, and a model you are allowed to run. Tabby, Continue, and an open-weight model cover those three roles.
The short answer
Self-hosting buys a data boundary and control over model versions. It costs GPU capacity, a serving stack, and someone who owns upgrades. It is worth it when the boundary is a requirement; it is a hobby when it is a preference.
What the boundary actually covers
| Data | Hosted assistant | Self-hosted stack |
|---|---|---|
| Code you paste | Vendor | Your network |
| Repository index | Vendor | Your server |
| Prompts and completions | Vendor | Your logs |
| Model version | Changes under you | Pinned |
The second row is the one people forget. A completion tool that indexes your repository is sending your code to the index, even if you never paste a file.
Tabby: the server
Tabby is a completion server with editor plugins: it indexes repositories, runs a model, and answers completion requests. It can run on a CPU with a smaller model or on a GPU with a better one, which makes the cost a dial rather than a fixed price.
Its useful property is that it is boring infrastructure: an HTTP service, a database, and a model. Boring is good for something that every developer depends on.
Continue: the client
Continue is the editor side: completion, chat, and edits, with the model behind each action configurable. That is what makes a mixed setup possible — a local model for completion, a stronger hosted model for a one-off explanation, and the boundary applied only where it matters.
The trade is a config file per developer and a model account to manage. It is not a finished product and does not pretend to be.
The model question
An open-weight model runs locally and can be fine-tuned, but the smaller variants are noticeably weaker at multi-file reasoning. Completion is where local models hold up best: the task is narrow and latency matters more than depth.
The honest setup is a local model for completion and a policy for anything more complex. Pretending a small local model replaces a frontier model for refactors produces frustration, not savings.
The operations cost
Three things need an owner: the serving stack, the index refresh, and the model upgrade path. A completion server that is down is noticed by every developer immediately, which makes it production infrastructure with a different kind of pressure.
Before starting, answer who is on call for it. If the answer is nobody, the hosted option is cheaper in the currency that matters.
Should you?
If the boundary is a requirement, yes — this is the standard stack for it. If the boundary is a preference, start with a hosted tool and revisit when the security review actually asks the question.
Frequently asked questions
Can I run this on a laptop? For completion, a small model works. For repository indexing at scale, you want a server.
What about quality? Completion quality with a local model is acceptable; multi-file reasoning is not close to frontier models yet.
How do I know it works? Measure suggestion acceptance and review findings, not latency alone. See Tabby and coding tools.
Last checked: 12 November 2026.
Related: coding assistants by supervision model, Continue, and coding tools.
