Thomson Reuters engineer runs an offline coding agent on Qwen3.5 9B in the Himalayas

In the Himalayan foothills, the internet drops out as regularly as the power. That is where Rittika Jindal, a Principal Engineer at Thomson Reuters, lives. She set out to find how much of a coding-agent workflow survives with the internet cut off entirely. The answer was concrete. A stack of OpenCode 1.19.4, Ollama and the open Qwen3.5 9B model, all on a single Mac, finds a bug, proposes a fix and runs the tests while Wi-Fi is off. The example is small: a one-line fix after which all five tests pass. But the stack is reproducible, and the write-up goes down to the exact commands.

How the offline stack is put together

The division of roles is simple. Ollama holds the model and runs a local service. OpenCode reads the project files, proposes edits and runs commands. The opencode.json config points both the main and the auxiliary model (model and small_model) at Qwen3.5 9B, and baseURL points to http://127.0.0.1:11434/v1. Only the local provider is enabled, web tools are blocked, and the agent asks permission before editing files or running shell commands. Ollama starts with OLLAMA_NO_CLOUD=1 and a context length of OLLAMA_CONTEXT_LENGTH=65536. The model is downloaded with ollama pull qwen3.5:9b while the internet is still available. OpenCode is launched with the --pure flag, which disables external plugins.

Among alternatives, the author mentions Aider. It also works with Ollama and suits people who want a more guided editing workflow.

Which model to pick and how much memory it needs

For the choice, the author used published results from the Qwen model card rather than her own measurements on the laptop. LiveCodeBench v6 tests code generation. BFCL-V4 scores function calling, meaning the agent's ability to pick a tool and fill in the right arguments.

• Qwen3.5 4B: LiveCodeBench v6 — 55.8; BFCL-V4 — 50.3; download 3.3–4.0 GB.
• Qwen3.5 9B (used in the test): 65.6 and 66.1; download 6.6–7.6 GB.
• Qwen3.5 27B: download 17–20 GB; the article gives no benchmarks.
• gpt-oss-20b: LiveCodeBench v6 — 74.6; BFCL-V4 not published.

She chose the 9B version because its tool calling is noticeably better than the 4B's. Download size, however, does not equal RAM requirements. For the 6.6 GB build of Qwen3.5 9B, Voltti budgets 12–16 GB of memory, and a configuration with a 64k context may need more. You also need headroom for other applications.

The article separately examines the agent harness itself. The preprint The Scaffold Effect in Coding Agents compared OpenCode, Goose and OpenHands-SDK on 50 Terminal-Bench Pro tasks with two cloud models:

• Qwen3.6 Plus: Goose — 48% [34–62%], OpenCode — 50% [36–64%], OpenHands-SDK — 50% [36–64%].
• MiniMax M2.5: Goose — 38% [24–52%], OpenCode — 46% [32–60%], OpenHands-SDK — 46% [32–60%].

The 95% confidence intervals overlap, and the authors warn that most of the differences are not statistically clear. Token consumption, though, differs sharply: OpenCode spends roughly 40 times more tokens per solved task than Goose. With a cloud API, that is direct cost. With a local model, it means generation time and pressure on the context window. These figures do not predict how a 9B model will behave on a laptop, since the tests used cloud models.

What the test with Wi-Fi off showed

The test project is an expense calculator: five expenses, including a refund, with a correct total of 25.50. The starting program prints 8.00, the value of the last expense, because the function overwrites the sum on every iteration. Three tests fail: decimal arithmetic, refunds and a real-data example. Empty input and a single item pass.

Online, the agent received a diagnostic prompt and read the code, but first suggested pytest even though the project uses the built-in unittest. The permission prompt for running a command let the author see it before it executed. Her takeaway: next time, specify python3 -m unittest -v in the prompt.

After checking Ollama with curl on localhost, the author turned Wi-Fi off. A request to an external address failed with Could not resolve host. The agent proposed the fix `total = Decimal(amount)` → `total += Decimal(amount)`, asked permission to edit, and ran the tests. The author then ran the check herself: all five tests are green, and the test file was not changed.

Two other exercises, a CSV report and a log analyzer, with seven tests each, are in the repository, but there are no offline runs for them yet. The CSV task will be the fairer exam: the agent has to write a function, not fix a single line.

The practical takeaway for anyone working on a train, on a plane or in an area with poor coverage: everything you need must be on disk before you lose the connection. That means the model, the project dependencies and the documentation. Run exactly the configuration you will use offline. Give the agent the exact test command and keep tasks narrow: one bug or one small feature. Review the diff and run the original tests yourself. Watch memory: a 64k context and open applications eat whatever is left after the model. This experiment has not yet tested a large repository or an unfamiliar framework.