Continue.dev Is Dead. Here's How I Switched to Cline + Ollama on Proxmox (2026)

TL;DR: Cursor acquired Continue.dev on June 18, 2026. The GitHub repo went read-only the next day, the data deadline was July 15, and the standalone product is gone. If you were running Continue + Ollama as your local AI coding stack, the best drop-in replacement is Cline — same open-source, bring-your-own-key model, same VS Code extension install pattern, and full Ollama support. This post covers the exact migration steps, model selection for different hardware tiers, and the one Ollama config fix that makes the difference between "broken" and "genuinely useful."

What Actually Happened with Continue.dev

If you missed the news: on June 18, 2026, Cursor announced it had acquired the Continue team. It's an acqui-hire — Cursor took the engineers, and the standalone product ends. The continuedev/continue repo shipped a final 2.0.0 release on June 19 and went read-only. No new issues, no new PRs, no roadmap. Users had until July 15 to export their data before it was deleted.

The irony is heavy. Continue was built specifically as an open, privacy-first alternative to GitHub Copilot — the tool you chose because you didn't want to send your code to a cloud subscription. It got acquired by Cursor, which is a paid cloud subscription IDE. The mission didn't continue through Cursor. The code lives on under Apache 2.0, but the project is dead.

For those of us running Proxmox homelabs with Ollama, this matters more than it does for people who just want a cloud coding assistant. We deliberately built a stack where code never leaves our hardware. We need a replacement that respects that architecture.

Why Cline Is the Right Replacement

There are several Continue.dev alternatives floating around right now — Tabby, Void, Aider, and others. I spent two weeks testing them against my actual workflow (.NET backend + Angular front-end on a Beelink GTi14 running Proxmox). Here's why Cline won for me.

First, the overlap with Continue is near-perfect on paper: both are Apache 2.0 open-source VS Code extensions, both support bring-your-own-key, both connect to Ollama at localhost:11434. If you had Continue working, you can have Cline working in under ten minutes.

The key difference is that Cline is more agentic. Continue was primarily a developer-controlled AI layer — you asked it things, it answered. Cline operates more autonomously: it reads files, runs terminal commands, inspects error output, and iterates until a task is done. Every action requires your approval before it executes, which is the right design for a tool that's actually touching your codebase. Think of Continue as a smart chat panel bolted onto your editor, and Cline as a junior developer sitting next to you who can also use the keyboard.

For self-hosted setups, this distinction matters because agentic capability is where local models have historically struggled the most. A 7B model doing autocomplete is fine. A 7B model planning a multi-file refactor is a disaster. With Cline's architecture and the right model selection (more on this below), the experience on modest hardware is meaningfully better than what Continue's approach allowed.

Cline also has 5 million VS Code installs and 58,000 GitHub stars as of August 2026, so this isn't a fringe project. It has real momentum and an active maintenance cycle — exactly what you want when picking a long-term replacement for a tool that just got acqui-hired into oblivion.

Prerequisites

This guide assumes you're running Ollama somewhere on your network. If that's already the case, skip this section. If you're starting fresh:

• Hardware: You need enough RAM/VRAM to run a coding-capable model. The realistic minimum for useful output is a 7B parameter model at Q4_K_M quantization, which requires ~6GB VRAM or ~8GB unified memory. For the 32B models that actually shine on multi-file work, you need ~22GB VRAM or a mini PC with 32GB+ unified memory. If you're shopping for a dedicated box, the Beelink GTi14 (Core Ultra 9, 64GB DDR5) is what I run — it handles qwen2.5-coder:32b at Q4_K_M at around 18 tokens/sec. The Beelink SER7 with the Ryzen 7 7840HS is a cheaper entry at ~$370 and runs the 7B model comfortably.
• Proxmox + Ollama LXC: I covered the full Ollama + GPU passthrough setup in my Ollama on Proxmox with GPU Passthrough guide. Follow that first if you need it.
• VS Code installed on your dev machine (or wherever you code).
• Ollama reachable on your local network. If your LXC or VM IP is 192.168.1.50, Ollama should be listening at http://192.168.1.50:11434.

I do most of my long sessions with Sony WH-1000XM5 headphones — the noise cancellation is good enough that I can run inference for 20-30 seconds while the model thinks through a refactor without getting distracted. Not strictly required, but worth mentioning. When working on longer coding sessions, I also keep a Samsung T7 Shield SSD nearby for backing up working states before any larger automated refactor.

Step 1: Pull Your Model in Ollama

Model choice matters more with Cline than it did with Continue because Cline's agentic tasks require actual multi-step reasoning. My recommendations by hardware tier:

8–16GB VRAM / unified memory: qwen2.5-coder:7b — fast, capable on single-file work, compiles TypeScript or C# on first try roughly 70% of the time.

16–24GB VRAM / unified memory: qwen2.5-coder:14b — meaningful jump in quality for multi-file reasoning. This is the sweet spot if your hardware can handle it.

24GB+ VRAM or 32GB+ unified memory: qwen2.5-coder:32b at Q4_K_M — the community gold standard for local coding agents right now. Multi-file refactors that would have required cloud Claude 18 months ago now complete locally.

Pull whichever fits your hardware:

ollama pull qwen2.5-coder:32b

If you're on the 7B or 14B, replace the model name accordingly. Pull happens on your Proxmox LXC (or wherever Ollama runs), not your dev machine.

Step 2: Fix the Context Window (Critical)

This is the step that most guides skip, and it's the reason people think "Cline with Ollama doesn't work." Ollama defaults a model's context window (num_ctx) to roughly 2K–4K tokens. An autonomous coding agent like Cline blows past that within two or three tool calls — it reads a file, reads another file, reads the error output, and suddenly the context is gone and the model starts hallucinating.

Fix this by creating a Modelfile that extends the context:

# On your Proxmox Ollama host
cat << 'EOF' > /tmp/Modelfile-coder
FROM qwen2.5-coder:32b
PARAMETER num_ctx 32768
EOF
ollama create qwen2.5-coder-32b-ctx32k -f /tmp/Modelfile-coder

This creates a new model name (qwen2.5-coder-32b-ctx32k) that you'll point Cline at. You can go up to 65536 if your hardware has the VRAM headroom — 32K is the minimum useful value. Once set, Cline stops losing track of what it was doing mid-refactor.

Step 3: Install Cline in VS Code

Open VS Code → Extensions panel → search "Cline" → Install. The extension ID is saoudrizwan.claude-dev. Despite the name, it's not locked to Claude — that's just the original author's naming.

After installing, you'll see the Cline icon in the Activity Bar (left sidebar). Click it to open the Cline panel.

Step 4: Configure Cline to Use Your Ollama Instance

1. In the Cline panel, click the settings gear icon (top right).
2. Under API Provider, select Ollama from the dropdown.
3. Set the Base URL to your Ollama instance: http://192.168.1.50:11434 (use your actual LAN IP).
4. In the Model field, type your model name: qwen2.5-coder-32b-ctx32k (the one you created in Step 2).
5. Leave the API key field blank — Ollama doesn't need one.
6. Save.

Open a project folder in VS Code and type your first prompt in the Cline panel. Cline will list every action it plans to take (read file, edit function, run test) and wait for you to approve before executing anything. The first response on a fresh model load will be slow — 10–20 seconds to warm up — subsequent calls are faster.

Real Workflow: Refactoring a .NET Service with Cline

Here's how this actually plays out in day-to-day use. I was working on a microservice where a data access layer had grown into an untestable mess — one class doing three jobs, sync and async methods mixed without reason, and no dependency injection. I gave Cline this prompt:

"Refactor OrderRepository.cs to split it into a read model and write model following CQS principles. Use constructor injection for IDbConnection. Add XML doc comments to all public methods. Don't touch any existing test files."

What happened next is what I couldn't do with Continue's interaction model:

1. Cline read OrderRepository.cs — requested approval, got it.
2. Cline scanned the project structure to find where the repository was registered — requested approval, got it.
3. Cline read the existing test file to understand what it should not break — requested approval, got it.
4. Cline proposed a three-file split (OrderQueryRepository.cs, OrderCommandRepository.cs, interface file) with the full code for each — I reviewed, approved.
5. Cline updated the DI registration in Program.cs — requested approval, got it.

Total prompts from me: one. Total approval clicks: five. The result compiled on first try and the existing tests still passed. With Continue, that same task would have taken five back-and-forth messages and me doing all the file editing manually. The difference isn't subtle.

For keyboard comfort during long sessions like these, the Keychron K4 is what I type on. The tactile feedback makes reviewing Cline's proposed edits faster — I can run through the diff and hit accept without thinking about the keyboard.

What Doesn't Work (Yet)

Being honest: local models still have real limits. Cline + qwen2.5-coder:32b handles single-service refactors well. It starts to fall apart when the task requires reasoning across five or more files simultaneously, or when the codebase relies on framework conventions the model hasn't seen enough of. Cross-project refactors (changing a shared library and updating all consumers) still need cloud Claude or GPT-4o.

The approval model also slows you down on simple tasks. If you just want to rename a method across the codebase, using VS Code's built-in rename symbol is faster than delegating it to Cline. Use Cline when the task requires reasoning, not just search-and-replace.

Inference latency on 32B models is real: 15–20 tokens/sec means a complex response takes 30–60 seconds. If you're used to Cursor's cloud speed, this will feel slow for the first week. I've adapted by using the thinking time to write notes or review a PR — it's not dead time if you treat it right.

What I'd Improve Next

I'm planning to set up a remote Ollama endpoint that Cline can reach from anywhere using Headscale (my self-hosted Tailscale control plane), so I get the same local AI coding experience on my laptop while traveling. The Proxmox LXC runs 24/7, so there's no reason it should only be reachable on the home network.

I'm also testing devstral:24b from Mistral as an alternative to qwen2.5-coder — early results suggest it handles Angular TypeScript better than qwen2.5, which makes sense given the training data. If that holds up over a few more weeks, I'll post a follow-up comparison.

Migration Checklist: Continue.dev → Cline

• Export any custom slash commands or context files you built in Continue
• Pull your chosen model in Ollama (add :7b, :14b, or :32b)
• Create a Modelfile setting num_ctx 32768 minimum
• Install Cline from VS Code marketplace
• Point Cline at your Ollama LAN IP, select the extended-context model
• Run a small test task — file read + single edit — to confirm the connection works
• Done. Total time: under 15 minutes.

FAQ

Is Cline free?

The Cline extension itself is free and open-source under Apache 2.0. When pointed at Ollama, inference is also free — you're using compute you already own. There's no subscription to Cline. If you choose to connect it to a cloud provider (Anthropic, OpenAI, etc.) instead of Ollama, you pay that provider's API rates directly.

Can I still use Continue.dev v2.0.0?

Technically yes — the final release is still installable and the code is still on GitHub under Apache 2.0. But there will be no security patches, no bug fixes, and no VS Code API compatibility updates. VS Code extensions break regularly as VS Code ships new API versions. Continue v2.0.0 will degrade over the next 6–12 months. Don't build a long-term workflow on it.

Does Cline work with JetBrains Rider?

Not yet as of August 2026. Cline is VS Code only. If you live in Rider for .NET development, the closest alternative with Ollama support is Continue v2.0.0 (with the caveats above) or Void, which is an open-source VS Code fork that supports JetBrains-style keybindings. I haven't tested Void enough to recommend it yet.

What's the best model for limited hardware — 8GB RAM, no dedicated GPU?

On CPU-only inference, you're realistically limited to 3B–7B models, and inference will be slow (1–3 tokens/sec). Qwen2.5-coder:3b can handle autocomplete passably, but Cline's agentic mode will be frustrating at that latency. If you're in this situation, I'd actually recommend spending the $370 on a Beelink SER7 — the iGPU on the Ryzen 7 7840HS runs the 7B model at 14 tokens/sec, which is actually usable for agentic tasks.

Should I use Cline with cloud APIs or local Ollama?

Depends on your threat model. If code privacy isn't a concern, connecting Cline to cloud Claude gives you significantly better reasoning quality and speed. If you're working on proprietary code, a client project with NDAs, or you just don't want your codebase in training data — stick with Ollama. The local path is my default for any client work.

Will Cursor absorb Continue's features?

Cursor says yes, the ideas continue through Cursor's product. In practice, this means you'd pay $20/month for a subscription that still sends your code to the cloud — the opposite of what Continue's users wanted. If you're considering that path, compare it honestly against what you can get for free with Cline + Ollama first.