Offline Coding Agent on a Laptop: OpenCode, Ollama and Qwen3.5 9B With the Wi-Fi Off

A new Latent Space piece, Coding From the Himalayas With an Offline AI Agent, answers a practical question: can a coding agent do useful work when the internet is off? The author, Rittika Jindal, a principal engineer at Thomson Reuters, lives in the Himalayan foothills where network and power outages are common. On a Mac laptop, using OpenCode, Ollama and Qwen3.5 9B, an agent read a local project, diagnosed a bug, changed one line and ran the tests, all with Wi-Fi disconnected.

It is a small test, and the write-up is honest about that. It is also a clean, reproducible recipe for the offline workflow, which is why it is worth walking through. For a wider view of local setups, see our guide to running open-source models locally and wiring them into OpenCode.

TL;DR

The setup, step by step

According to the article, the workflow is deliberately boring, and that is the point:

1. Download everything while online. Pull the model, the harness, and the project's dependencies in advance.
2. Configure the agent for local only. The project's opencode.json points only to the local Ollama endpoint, asks before edits or shell commands, and blocks web tools.
3. Start Ollama with cloud features disabled and a 64k-token context window.
4. Verify the agent responds. The author confirmed Ollama's local API answered while an external request to example.com failed with a DNS error, proof that the machine really was cut off.
5. Disconnect Wi-Fi and run the task.

The permission prompts matter as much as the model. An offline agent still runs shell commands on your laptop, so asking before edits and commands is the guardrail, not an inconvenience.

Why Qwen3.5 9B rather than 4B or 27B?

The author picked the 9B over the 4B for stronger published coding and tool-calling scores. Qwen's model card, which the author did not re-measure locally, reports LiveCodeBench v6 and BFCL-V4 scores of 65.6 and 66.1 for the 9B, against 55.8 and 50.3 for the 4B. gpt-oss-20b is listed at 74.6 on LiveCodeBench, with no BFCL score reported. These are the vendor's published numbers, so treat them as a rough guide to relative strength, not a promise of performance on your code.

Sizes are the practical constraint:

Download size is not RAM. One guide the author cites budgets 12 to 16 GB of memory for the 9B build, and a 64k context may need more. Other applications competing for memory also reduce room for the model. If quantization terms are unfamiliar, our quantization guide explains the trade-offs.

What the agent actually did

The test project was a small expense calculator. Given five expenses, one of them a refund, the correct total is 25.50, but the program printed 8.00, and three of five tests failed.

A bug under a magnifier next to a green check, illustrating the offline coding agent diagnosing and fixing a failing test

The agent found the bug, though it first suggested pytest rather than the project's unittest. The fix was one line: total = Decimal(amount) became total += Decimal(amount), an accumulator that was overwriting instead of adding. All five tests then passed.

Two honest observations follow. First, the diagnosis was right, which is what you would want from a 9B model on a small, well-bounded task. Second, the pytest detour is the classic small-model failure: it reached for a common tool instead of reading the project's conventions. That is why the author recommends giving the agent the exact test command.

Lessons the author draws

• Prepare the project and its dependencies in advance, and run the exact setup once while online.
• Give the agent the project's exact test command to avoid detours.
• Keep tasks small and self-contained, then review the diff and run the original tests yourself.
• Watch memory pressure, since large contexts and other apps reduce room for the model.
• Document failed attempts and permission prompts, not just the final passing output.

Those are good habits for any agent workflow, online or off. The last one is underrated: a record of what failed teaches you what the model cannot yet do.

What this does not prove

The author is explicit about the limits. A one-line fix in a small project does not show how the model handles a large repository or an unfamiliar framework. The CSV report and log analyzer exercises have not been run offline yet. The test is also one task on one machine, with no timing or token-speed numbers reported, so we cannot say how long the run took.

The article also cites a research preprint on OpenCode that used cloud models on 50 Terminal-Bench Pro tasks and reported pass rates of about 46 to 50 percent, with OpenCode using roughly 40 times Goose's tokens per solved task. The author notes these results do not predict local 9B performance, and we agree: different models, different tasks, and a token-hungry harness matters more when your context window is 64k and your hardware is a laptop. For related evidence on harness overhead, see what a harness buys in tokens.

How to design your own offline test

The article gives the shape of the experiment but not every command, so here is how we would structure a version of it, using only the steps it describes. We have not run this ourselves.

Two extensions are worth adding that the article lists as not done yet: a task that touches several files, such as the CSV report exercise, and a log-analysis task that needs the agent to read larger inputs. Those are where a 9B model on a 64k context is most likely to struggle, because the context fills with file contents and the model loses track of the goal.

A second extension is a negative test. Ask the agent to do something that requires the internet, such as installing a package that is not cached, and check that it fails cleanly instead of hanging or inventing a result. An offline agent that degrades gracefully is more valuable than one that only works on the happy path, and the blocked web tools in the author's configuration make this easy to observe.

Finally, keep notes on failures. The author recommends documenting failed attempts and permission prompts, and that record is what turns a demo into evidence about where a small local model stops being useful for your own code.

How it compares with other local setups

This recipe sits at the small end of a spectrum we have covered. Verge's local AI diary describes a larger Mac Studio setup with Hermes Agent and Qwen. Running Qwen 3.6 27B with llama.cpp and OpenCode shows what a bigger model buys you, and our list of top open-weight models for a laptop helps you choose by memory budget. If you are deciding between a laptop and a dedicated GPU, MacBook vs dedicated GPU for local LLMs covers the trade-off.

Should you try it?

If you have intermittent connectivity, work with sensitive code that cannot leave the machine, or simply want a fallback when a hosted service is down, yes: the setup is an afternoon, and the small-task result is encouraging. Start with a bounded bug in a project whose tests you trust, keep permission prompts on, and review every diff. If you expect the agent to refactor a large codebase, plan on a bigger model and more memory, or accept that a hosted frontier model will still do that work better.

The takeaway is modest but useful: the minimum viable offline coding agent now fits on a laptop, and the main risks are memory, scope and your own discipline about reviewing what it changes.

Related reading

• Survival LLM: an offline emergency assistant tested on 22 questions

• How to run open-source models locally and wire them into OpenCode

• Verge local AI diary: Hermes Agent, Qwen and a Mac Studio

• Qwen 3.6 27B with llama.cpp and OpenCode

• Top 10 open-weight models for a laptop

• What does a harness buy? Tokens, mostly

• MacBook vs dedicated GPU for local LLMs

• External: Latent Space: Coding From the Himalayas · OpenCode · Ollama

Details reflect the Latent Space article of October 27, 2026; versions and model scores may change.