Can you run an AI coding agent fully offline

Short answer: no, not if 'AI coding agent' means Claude Code, Cursor, or Codex as shipped. Those tools are thin clients over a hosted model, and the agent loop — read file, plan, edit, run tests, read the error, try again — is the product. Cut the network and the loop stops at step one. What you can do is run a local model for a real share of that loop (autocomplete, small edits, first-pass answers) and only leave the machine when the task actually needs the strength of a frontier model. That's a different claim than 'fully offline,' and it's the one worth chasing.

Why the agent loop needs a network by default

Claude Code, Cursor, and OpenAI's Codex CLI are built around a specific hosted model per session. The agent's judgment — deciding which file to open next, whether a diff is safe, how to interpret a stack trace — comes from that model's weights sitting on someone else's GPU. There is no local fallback wired in. Kill your connection mid-session and the CLI just hangs on the next request or throws a network error. This isn't a bug, it's the architecture: these companies sell access to models too large to run on a laptop, so the client assumes a network is there.

That's the reason 'run it offline' searches mostly lead to disappointment. The tools weren't built with an offline mode as a first-class option, because the business model depends on the opposite.

What actually runs locally today

A separate, real category of tools does run entirely on your machine, no account, no API key, no network call ever. If your goal is genuinely offline coding help, this is where to look, not at Claude Code or Cursor.

• Ollama and LM Studio — pull an open-weight model (Qwen2.5-Coder, DeepSeek-Coder, Llama family) and run it as a local server. Both give you an OpenAI-compatible endpoint on localhost, so anything that speaks that API can talk to it.
• llama.cpp and vLLM — the inference engines underneath most local setups. llama.cpp is the pragmatic choice on a laptop; vLLM assumes real GPU hardware and is built for throughput, not a single developer's machine.
• Continue, Cline, and similar editor extensions — these can be pointed at a local Ollama or LM Studio endpoint instead of a cloud API, giving you inline completion and chat without leaving the machine.
• Jan and Open WebUI — local chat front ends if you want a ChatGPT-style interface talking to a model that never leaves your disk.

The catch is capability, not connectivity. A 7B or 14B coding model running on a MacBook is genuinely useful for autocomplete, boilerplate, small refactors, and explaining a function. It is not going to plan a multi-file migration, reason through a gnarly race condition, or hold a large codebase's context the way Opus or Sonnet does. Anyone who tells you a local 8B model replaces Claude Code for real agentic work is not measuring against real agentic work.

The middle ground: local first, cloud when it matters

Given that full offline coding-agent capability isn't real yet, the more useful question is: how much of a normal coding session can be handled locally before you actually need the frontier model. In practice that's a lot — trivial completions, formatting-adjacent edits, quick lookups, repeated questions you've already asked this week. The rest — architecture decisions, hard debugging, anything where a wrong answer costs you more than the tokens — still wants Opus or Sonnet or GPT.

I built Probe0 around that split because I got tired of every request in a session going to the cloud by default, including the ones a local model on the same machine could've handled. It's a local proxy — no Probe0 server exists — that every coding agent CLI on your machine routes through: Claude Code, Codex, Cursor, all of them, via one certificate installed once. No per-tool config after that.

The piece that's actually relevant here is Local Routing: it sends eligible requests to a model already running in your Ollama or LM Studio instance instead of the cloud, and if the local model's answer looks weak, it auto-retries on the cloud rather than shipping a bad response. Paired with an exact-match cache and a semantic cache that both live entirely on local disk, a meaningful share of a session's traffic never leaves the laptop. It's not offline. It's fewer round trips to a network you may not want to depend on, and a lower bill on the ones you do take. Everything else — Model Tiering, Spend Guard, a full request ledger with real cost per call — is there because once you can see where a session's tokens actually went, that middle ground gets easier to tune instead of guessed at.

Worth saying plainly: if you want a tool built for a team or for genuinely air-gapped compliance work, Probe0 isn't it. It's macOS-only, single-developer, private beta, and it only speaks to whatever providers your coding agents already call — it's not a 100+ provider gateway. Ollama and LM Studio remain the right foundation either way; Probe0 just decides when your agent should bother them versus the cloud.

A realistic setup if privacy or connectivity is the real driver

If the actual goal is 'my code should never leave this machine,' local-only is achievable — you just give up the frontier-model ceiling to get there.

• Install Ollama, pull a coding-focused model sized to your RAM (Qwen2.5-Coder 14B is a reasonable mid-range pick, 32B if you have the memory to spare).
• Point Continue or Cline at the local Ollama endpoint instead of a cloud key.
• Use it for the tasks it's actually good at: completion, small isolated edits, explaining unfamiliar code, quick syntax questions.
• Keep a cloud agent (with a real API key) available for the sessions where you need multi-file reasoning or long-context planning, and accept that those sessions require a network.

The honest framing isn't 'offline or not.' It's which parts of a coding session actually need a frontier model, and routing only those.

Nobody has shipped a fully offline agent that plans, edits, and self-corrects at Claude Code's level, because that capability doesn't fit on consumer hardware yet. What's real today is a spectrum: pure local tooling at one end, pure cloud agents at the other, and a growing set of routers and proxies in the middle that try to keep the parts of your workflow that don't need a frontier model off the network entirely.