Sep 10, 2026

Twinny 4.0 + Ollama in 2026: The Local-First VS Code Extension Is Back — Auto-Discovery, the Two-Model Rule, and P2P Ollama Sharing

Q: Which model should I use for autocomplete on weak hardware?

`qwen2.5-coder:1.5b` — around 1 GB, runs acceptably even on CPU. The autocomplete model's job is speed; going bigger than 3B for FIM mostly buys latency, not better ghost text. Spend your VRAM on the chat model instead.

By AICoderScope Team · 12 min read

twinnyollamalocal-llmsetup-guidevscodeqwen

TL;DR: Twinny — the MIT-licensed, local-first VS Code extension — went silent for thirteen months and came back on September 7, 2026 with a 4.0 release that auto-discovers a running Ollama, picks sane models for autocomplete and chat on its own, and can share one machine’s Ollama with another over an encrypted peer-to-peer link. Setup is now genuinely zero-config if you pull the right two models first.

What you’ll be able to do after this guide:

Get ghost-text autocomplete and sidebar chat running against a local Ollama with no manual provider form at all — and know exactly which two models to pull so 4.0’s strict auto-picker doesn’t leave autocomplete unset
Fix the three things that actually break Twinny sessions: an instruct model in the FIM slot, the 5-minute keepAlive eviction that makes the first completion after lunch take 20 seconds, and the 100-line default context that misses your imports
Pair a laptop to the Ollama on your desktop GPU box with a one-time pairing code instead of exposing port 11434 to your LAN

Honest take: If you want one extension that does local FIM autocomplete in VS Code with the least configuration in 2026, Twinny 4.0 is now the pick — discovery plus model auto-selection beats hand-writing a Continue.dev config. If you need JetBrains support, cloud-model mixing, or an agent that edits files for you, stay with Continue.dev or Cline — Twinny deliberately stops at completion, chat, review, and commit messages.

Back from the dead, and it shipped fast

Twinny’s release history tells the story in two lines. Version 3.23.31 landed on August 7, 2025 — then nothing for over a year. On September 7, 2026, v4.0.0 appeared, followed by v4.0.1, v4.0.2, and v4.0.3 within 48 hours; the repository’s package.json already reads 4.0.9 as of September 10. That cadence is what a revival looks like: one maintainer (rjmacarthy) landing a rewrite and then patching it live.

The dormancy mattered because Twinny occupied a spot nothing else quite fills: a free, MIT-licensed extension built around local inference as the default, not a cloud product with a local escape hatch. The 3.x versions worked but aged — provider setup was a manual form, and the recommended models in old guides (CodeLlama-era) are two generations stale. The 4.0 line fixes the first problem structurally and sidesteps the second with automatic model selection.

What’s actually new in 4.0, from the source:

Local server discovery. On first run, Twinny probes the machine for servers people actually run — Ollama on 11434 first, then LM Studio on 1234, llama.cpp on 8080, Oobabooga, LiteLLM, Open WebUI, and a generic OpenAI-compatible catch-all — and turns whatever answers into configured providers without you typing an address.
Strict model auto-pick. Discovery reads the server’s model list and assigns roles by name: something matching code|coder|fim|starcoder|codestral|codegemma goes into the autocomplete slot, an instruct/chat-tagged model goes into chat, embed|minilm|bge|e5|nomic into embeddings. Crucially, the unattended picker is strict — if nothing on the server looks like a code model, it leaves autocomplete unset and says so rather than jamming a chat model in.
Twinny P2P. A new provider type that reaches another machine’s Ollama over an encrypted peer-to-peer connection (Noise handshake over a DHT, UDP port 49737) with one-time pairing codes. More on this below, because it’s the most interesting thing in the release.
Code review and commit messages. A twinny.review command that reviews diffs locally (16,000 diff characters by default) plus git commit message generation.

The five-minute setup

Tested September 10, 2026 with Ollama v0.34.0 (released September 5) and Twinny 4.0.x on VS Code. Twinny requires VS Code 1.84 or newer.

Step 1 — pull the two models. This is the part that decides whether the zero-config story works. Twinny wants different models for autocomplete and chat, and its strict picker will only fill the autocomplete slot with something that looks like a code/FIM model:

ollama pull qwen2.5-coder:1.5b   # ~1 GB — FIM autocomplete; small on purpose
ollama pull qwen3-coder:30b      # ~19 GB — chat/refactor; MoE, 3.3B active params

Why this pair: autocomplete fires on every pause while you type (Twinny debounces at 300 ms by default), so the FIM model’s job is latency, not brilliance — a 1.5B model returns ghost text fast enough to feel native, and qwen2.5-coder is explicitly on Twinny’s known-code-model list. Chat is the opposite trade: qwen3-coder:30b is a 30B mixture-of-experts with only 3.3B active parameters and a 256K native context, so it runs like a much smaller model while giving you repository-scale reasoning. If you’re on 8–12 GB of VRAM, substitute qwen2.5-coder:7b for chat and keep the 1.5B for FIM.

Step 2 — confirm Ollama is answering:

curl -s http://localhost:11434/api/tags | python3 -m json.tool | grep '"name"'

Expected output:

"name": "qwen3-coder:30b",
"name": "qwen2.5-coder:1.5b",

If that curl hangs or refuses, fix the server first — our Ollama connection-refused guide covers the IPv6 localhost trap and the rest.

Step 3 — install the extension from the VS Code Marketplace or Open VSX (search “twinny”, publisher rjmacarthy). On activation, discovery runs, finds Ollama on 11434, and assigns qwen2.5-coder:1.5b to autocomplete and qwen3-coder:30b to chat. Open a file, stop typing for a third of a second, and ghost text appears; Alt+\ forces a completion, Ctrl+I edits the selection with an instruction, Ctrl+Shift+Enter accepts a pending edit.

That’s the whole happy path. No config file, no YAML, no API key. Under the hood the providers Twinny wrote for itself hit different endpoints for different jobs — worth knowing when you need to debug:

Job	Endpoint Twinny uses on Ollama	Why
Chat / edit / review	`http://localhost:11434/v1`	OpenAI-compatible chat completions
FIM autocomplete	`http://localhost:11434/api/generate`	Raw prompt with model-specific FIM tokens
Embeddings (workspace context)	`http://localhost:11434/api/embed`	Ollama-native embeddings API

The FIM request is a raw prompt built from a template — Twinny ships formats for codeqwen, codellama, codestral, codegemma, deepseek, starcoder, stable-code, and llama, plus an automatic mode that infers from the model name and a custom escape hatch. Each template carries its own stop-token set (the Qwen one stops on <|fim_prefix|>, <|file_sep|>, <|im_end|> and friends), which is why picking the matching template matters if you configure manually.

The two-model rule (and what it looks like when you break it)

The most common failure we hit reproducing old Twinny guides: one big instruct model on the server, doing both jobs. Symptoms — ghost text that arrives a beat late and reads like a sentence: # Sure! Here's a function that... inline in your Python file, or completions that re-explain the code above the cursor instead of finishing the line.

The cause is mechanical. FIM models are trained to fill a hole between a prefix and suffix marked by special tokens; instruct models are trained to answer messages. Feed an instruct model a <|fim_prefix|> prompt through /api/generate and it does its best impression of a chat reply. Twinny 4.0’s strict picker exists precisely to stop this: if your Ollama only serves llama3.3:70b, discovery will configure chat and leave autocomplete empty rather than guess wrong. The fix is always the same — ollama pull qwen2.5-coder:1.5b (or :3b if you have headroom), then re-run discovery or assign it in the provider panel.

Two more real-world catches, with fixes:

The keepAlive eviction. Twinny sends keepAlive: "5m" by default, matching Ollama’s own default: five idle minutes and your model is unloaded from VRAM. Come back from a meeting, type a line, and the first completion takes 15–30 seconds while 19 GB of chat model reloads — which users reliably misread as “Twinny broke.” Set twinny.keepAlive to -1 (keep loaded indefinitely) on a dedicated dev box, or leave it if you share the GPU with other workloads. Same class of problem as the Ollama out-of-memory issues — VRAM residency is the hidden state under every local setup.

The 100-line context window. twinny.contextLength defaults to 100 lines around the cursor for FIM prompts. In a long file, your imports and type definitions fall outside it, and the model hallucinates symbol names. Bump it to 300–500 if your completions invent functions — cost is latency, since every keystroke’s prompt gets bigger. Related knobs that ship conservative: maxLines: 40 caps multiline suggestions, numPredictFim: 512 caps tokens, and fileContextEnabled: false keeps neighboring files out of the prompt (turn it on for multi-file work, watch latency). Note this is a line-count setting on the client — the server-side token context is a separate fight, covered in our Ollama context-length fix.

P2P: your desktop’s GPU, your laptop’s editor

The genuinely new idea in 4.0. The usual way to use a remote Ollama is exposing OLLAMA_HOST=0.0.0.0 and pointing clients at your LAN IP — which works until you’re on hotel Wi-Fi, and which puts an unauthenticated inference API on your network. Twinny 4.0 instead ships a P2P provider: the machine running Ollama acts as a node, your laptop pairs to it with a code, and traffic flows over an encrypted session (Noise-handshake, dialed through a DHT on UDP 49737) — no port forwarding, no reverse proxy, no Tailscale dependency.

The pairing model is tight by design: a code is the node’s public key plus an 8-byte random secret in one base64url string; it expires after ten minutes, works once, and a wrong guess burns it. The key half tells your laptop who to connect to and the handshake proves it; the secret half proves you were shown the code. Practically: generate a code on the desktop, paste it on the laptop, and the desktop’s qwen3-coder:30b shows up as a “Twinny device (P2P)” provider next to your local models.

This slots Twinny into the same niche LM Studio’s LM Link and remote-tunnel setups serve, with less machinery. If your laptop has no GPU at all, this plus a used RTX 3090 in a desktop is the budget path to full-speed local coding — the runaihome.com VRAM guide maps which models fit which cards, and a RunPod hourly rental covers the try-before-you-buy case.

Twinny vs Continue.dev vs Cline for local work

All three are free and open source; the split is scope. Verified against each project’s current state, September 10, 2026:

	Twinny 4.0	Continue.dev	Cline
Best for	Local FIM autocomplete + chat, minimal config	Cross-IDE assistant, mixed local/cloud	Agentic edits, tool use
IDE support	VS Code only	VS Code + JetBrains	VS Code
Setup for Ollama	Auto-discovery, zero config	`config.yaml` by hand	Provider form, per-model quirks
FIM autocomplete	Yes — core feature	Yes	No (agent, not completion)
Local server support	Ollama, LM Studio, llama.cpp, Oobabooga, LiteLLM, Open WebUI, any OpenAI-compatible	Same set via config	Ollama, LM Studio, OpenAI-compatible
Remote GPU story	Built-in P2P pairing	Point config at remote URL	Point provider at remote URL
The catch	No agent mode; single maintainer	Config surface is large	Burns tokens/VRAM fast; needs big models for tool use

The single-maintainer point deserves honesty: Twinny just demonstrated it can go dark for a year. It also demonstrated it can come back with the best first-run experience in the local-VS-Code category. MIT licensing means the worst case is a fork, but if you’re standardizing a team, that risk profile matters; for a personal setup it’s a non-issue.

FAQ

Does Twinny work fully offline? Yes. With Ollama and pulled models, completion, chat, embeddings-based workspace context, review, and commit messages all run without any network egress. The cloud providers (OpenAI, Anthropic, Mistral, Groq, OpenRouter, Cohere, Perplexity, Gemini, DeepSeek) are optional additions, not requirements.

Which model should I use for autocomplete on weak hardware? qwen2.5-coder:1.5b — around 1 GB, runs acceptably even on CPU. The autocomplete model’s job is speed; going bigger than 3B for FIM mostly buys latency, not better ghost text. Spend your VRAM on the chat model instead.

Twinny found my Ollama but autocomplete does nothing. Check the provider panel: 4.0’s strict picker leaves the FIM slot empty when no model on the server matches its code-model pattern. Pull a -coder model and reassign. If the slot is filled and ghost text still doesn’t appear, check twinny.autoSuggestEnabled and try Alt+\ to force a completion.

Can I use LM Studio instead of Ollama? Yes — discovery probes LM Studio’s port 1234 right after Ollama, using /v1 for chat and /v1/completions for FIM. Remember LM Studio’s server is opt-in: the app being open doesn’t mean the server is running, the #1 confusion we documented in the LM Studio connection-error guide.

Sources

Last verified September 10, 2026. Twinny 4.0.x is patching rapidly this week; settings names and defaults above are from the 4.0.9 manifest and may shift in minor releases. Pricing and features change frequently; verify current state before relying on them.

Was this article helpful?

Know which coding tool is worth paying for

Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.