Continue.dev vs Cody vs Tabby: AI Code Assistants That Live on Your Machine

Your Code Deserves Better Than a Cloud Subscription Judging It in Real Time

Let’s paint a picture. You’re deep in a project, you’ve got a function called do_the_thing_for_real_this_time_v3, a variable named temp2, and a comment that just says # idk. GitHub Copilot is watching all of this. It’s learning from all of this. Somewhere in a Microsoft datacenter, your crimes against clean code are being ingested into a training pipeline.

Or maybe that’s not what bothers you. Maybe it’s the $10/month bill. Maybe it’s the fact that your company’s legal team sent a three-page email about not pasting proprietary code into AI tools. Maybe you just like owning your stack.

Whatever the reason, you’re here because you want an AI code assistant that runs on your own hardware, respects your privacy, and doesn’t require a credit card. The good news: the options are actually pretty solid now. The slightly less good news: each one has its own quirks, setup overhead, and personality.

Let’s dig in.

Why Self-Host Your Code Assistant?

Before the comparison, let’s be clear about what you’re trading off.

The case for self-hosting:

• Privacy. Your code never leaves your machine. That matters for proprietary work, client projects, or just basic paranoia (valid).
• No per-token costs. Once you’ve got local models running, completions are free. Run it 10 times or 10,000 times — same bill.
• No telemetry. No one is collecting your prompts, your completions, or your usage patterns.
• Works offline. Traveling? VPN restrictions? Air-gapped environment? Doesn’t matter.
• Model choice. You pick the model. Want a 7B parameter model that runs on a laptop? Go for it. Got a beefy GPU and want to run something larger? Also fine.

The trade-offs:

• Setup takes more than clicking “install extension.”
• Quality depends heavily on the model you run locally — a 3B model is not going to match GPT-4.
• You need hardware. A decent GPU or at least 16GB RAM helps a lot.

If those trade-offs are acceptable, let’s look at what’s actually available.

The Three Contenders

Continue.dev — The Flexible Swiss Army Knife

Continue.dev is a VS Code and JetBrains plugin that acts as a front-end for whatever AI backend you want to point it at. It doesn’t run models itself — it connects to things like Ollama, LiteLLM, OpenAI-compatible APIs, Anthropic, or basically anything that speaks the right protocol.

This is both its superpower and its one complication: you need to have a backend running separately.

What it does:

• Inline code completion (the gray ghost text that finishes your thoughts)
• Chat sidebar (ask questions, get explanations, refactor code)
• Context-aware: it can read your open files, selected code, terminal output, and more
• Configurable via a config.yaml file — which sounds annoying but is actually pretty clean once you get the hang of it

The config.yaml approach means you can switch models without reinstalling anything. Want to try a different model? Update one field. Want to point at a remote server instead of local? One line change. (Older guides reference config.json — that format is deprecated now; YAML is the current way.)

Best for: People who already have (or want to set up) Ollama, and want a polished IDE experience with full chat + autocomplete.

Verdict: The most practical choice for most self-hosters. Especially if you’re already in the Ollama ecosystem.

Tabby — The Server You Own

Tabby is a different beast. It’s a self-hosted server application — you run it on a machine, it exposes an OpenAPI endpoint, and then your IDE extensions connect to it. The VS Code extension is the main integration, with JetBrains support also available.

What makes Tabby interesting is that it’s designed around the idea of training on your own codebase. You can point it at your repos and it builds context from your actual code, not just a generic pretrained model. For teams working on large or specialized codebases, this is a genuinely useful differentiator.

What it does:

• Code completion (its core strength)
• Repository context indexing
• OpenAPI interface — tools can integrate against it
• Docker-friendly deployment
• Answer Engine feature for chat-style queries (newer addition)

The trade-off: Tabby is more operationally involved than Continue.dev. You’re managing a server process, dealing with model downloads and GPU configuration, and keeping it running. It’s not hard, but it’s closer to “running a service” than “installing a plugin.”

# Quick Tabby start with Docker (CPU only)
docker run -it \
  -v $HOME/.tabby:/data \
  -p 8080:8080 \
  tabbyml/tabby \
  serve --model TabbyML/StarCoder-1B

Best for: Teams or power users who want to index their own codebase and treat the AI assistant as a proper service in their infrastructure.

Verdict: More setup, more power. Excellent if codebase-aware completion is what you need.

Cody — The Polished One With an Escape Hatch

Cody is Sourcegraph’s AI coding assistant. It’s the most polished of the three out of the box and works really well as a cloud product.

Heads up though: Sourcegraph killed the Cody Free and Pro plans in July 2025. Cody is now Enterprise-only — there’s no more individual free tier, and Sourcegraph is pointing solo devs at its newer agentic tool, Amp, instead. Cody still belongs in this comparison because of its self-hosted path via Sourcegraph Enterprise, but the “just use the free tier” escape hatch is gone.

What it does:

• Chat and autocomplete in VS Code, JetBrains, Neovim
• Deep codebase search via Sourcegraph’s code intelligence (this is where it genuinely shines)
• Command palette for common tasks (explain code, generate tests, fix bugs)
• Context from multiple repos simultaneously

The honest take on self-hosting: Cody self-hosted means running Sourcegraph, which is a substantial piece of infrastructure. It’s not a weekend project — it’s closer to “enterprise deployment.” If you’re a team already using Sourcegraph, adding Cody is a natural extension. If you’re a solo developer who just wants local completions, it’s overkill.

Since the free and Pro tiers are gone, the old “just use the cloud version for free” play doesn’t exist anymore. It uses Anthropic models on the backend and the product itself is still strong, but for individuals it’s now an enterprise license or nothing — which pretty much knocks it out for solo self-hosters.

Best for: Teams already in the Sourcegraph ecosystem on an Enterprise plan.

Verdict: Great product, but the individual free tier is dead and the self-hosting story is enterprise-grade complex. Solo devs should look at Continue.dev or Tabby instead.

The Practical Setup: Continue.dev + Ollama

This is the combo most people should start with. Here’s the full path from zero to working autocomplete.

Step 1: Install Ollama

Ollama handles model downloads, serving, and the API. It’s the easiest way to run local models.

# Linux/macOS
curl -fsSL https://ollama.com/install.sh | sh

# Pull a good coding model
ollama pull qwen2.5-coder:7b

qwen2.5-coder:7b is a solid choice — strong at code, reasonable resource requirements. The newer qwen3-coder line is worth a look too if it’s pulled into Ollama by the time you read this. If you’ve got the VRAM, deepseek-coder-v2:16b is excellent.

Verify it’s running:

ollama list
curl http://localhost:11434/api/tags

Step 2: Install Continue.dev

In VS Code: Extensions panel → search “Continue” → install the one by Continue.dev.

Once installed, it opens a sidebar. You’ll be prompted to configure your backend.

Step 3: Configure config.yaml

Open the command palette (Ctrl+Shift+P) → “Continue: Open config.yaml”

Here’s a working config that sets up both chat and autocomplete with Ollama:

models:
  - name: Qwen 2.5 Coder 7B
    provider: ollama
    model: qwen2.5-coder:7b
    apiBase: http://localhost:11434
    roles:
      - chat
      - edit
  - name: Autocomplete
    provider: ollama
    model: qwen2.5-coder:7b
    apiBase: http://localhost:11434
    roles:
      - autocomplete

The roles field is what tells Continue which model handles chat vs. autocomplete — in the YAML format, that replaces the old separate tabAutocompleteModel block. Telemetry is opt-in and configured from the User Settings page now, so flip it off there since you came here for privacy.

Step 4: Use it

• Autocomplete: Just start typing. Ghost text appears. Tab to accept, Escape to dismiss.
• Chat: Click the Continue sidebar or hit Ctrl+L to open chat. Select code first to include it as context.
• Inline edit: Select code, hit Ctrl+I, type your instruction.

That’s it. You’ve got a local Copilot.

Comparison Table

Which One Should You Actually Use?

Use Continue.dev if: You want to get something working this weekend, you’re already comfortable with or interested in Ollama, and you want chat + autocomplete without managing a separate server. This is the default recommendation for 80% of people reading this.

Use Tabby if: You’re working on a large proprietary codebase and want the assistant to actually understand your code patterns, not just generic completions. Also if you want to run it as a shared service for a small team.

Use Cody if: You’re already a Sourcegraph Enterprise shop and want codebase-aware AI baked into tooling you already pay for. The individual free tier is gone, so if you’re a solo dev who landed here for that, look at Continue.dev instead (or Sourcegraph’s newer Amp tool, which is the path they’re nudging individuals toward).

Use GitHub Copilot if: You enjoy paying $10/month for the privilege of having Microsoft read your variable names. (It is, to be fair, very good. But you knew that already.)

Hardware Reality Check

Let’s not pretend you can run a useful 70B model on a MacBook Air. Here’s the honest breakdown:

• 4GB VRAM / 8GB RAM: 3B models work. Completions will be fast. Quality is “helpful but not magical.”
• 8GB VRAM / 16GB RAM: 7B models work well. This is the sweet spot for most people. qwen2.5-coder:7b is genuinely useful here.
• 16GB+ VRAM: 13B-34B models. Quality gets noticeably better. Deep completions, better context handling.
• 24GB+ VRAM or multi-GPU: 70B models. Cloud-competitive quality. At this point you’re running a small server, which honestly sounds fun.

CPU-only is possible but slow. Tabby and Ollama both support it. If you’re on CPU, smaller models (1.5B-3B) are the realistic choice for anything resembling a responsive experience.

The Bottom Line

Self-hosted AI code assistants have crossed the threshold from “interesting experiment” to “actually useful daily driver.” Continue.dev with Ollama is the entry point most people should take — it’s practical, flexible, and the setup is well-documented.

Tabby is the right call if you’re thinking about this from a team infrastructure angle and want codebase-aware completions as a proper service.

Cody is excellent at what it does, but with the free and Pro tiers retired it’s an Enterprise-only product now — great if you’re already a Sourcegraph shop, a non-starter for solo self-hosters.

Your code can stay on your machine. Your variable names can remain your shameful secret. That’s the deal.

Have a different setup that works better for you? Running something exotic like LM Studio or a custom LiteLLM proxy? The comments are open, and I’m always curious what janky configurations people have gotten working in production.

Related Reading

• Aider & Cline: Terminal AI Coding That Actually Ships
• AMD Lemonade: Local LLM Serving for AMD GPUs
• Exploring the Diverse World of LLM Models
• Flowise vs Langflow: Build AI Pipelines Without Writing a Novel
• LiteLLM & vLLM: One API to Rule All Your Models