Evidence at a glance
Removing the Assumption of Connectivity
An article titled “Coding From the Himalayas With an Offline AI Agent” describes a principal engineer at Thomson Reuters trying to keep using a coding agent amid network and power outages in the Himalayan foothills. The subject is not a new model, but a local workflow built from OpenCode, Ollama, and Qwen3.5 9B: the agent works with project files while the model runs on the same laptop.
The useful question for engineering leaders is a practical one: which parts of development require a network, and which can be completed using local files, models, and tools? The answer is not that all development can happen offline. Some work can, provided its dependencies are ready and the task can be completed within a mostly self-contained environment. Being disconnected does not prove an agent is capable; whether the task can close its loop locally is the real test.
The Agent, Runtime, and Model Have Different Jobs
The division of labor matters more than simply installing a model on a computer. OpenCode manages the agent workflow: it can read project files, propose edits, and run commands. Ollama loads Qwen locally and serves the model, while Qwen generates responses or tool calls from the available context. The model is not the agent. Turning a request into a sequence of file reads, code changes, and test runs also depends on how the agent manages tools and permissions.
The article uses OpenCode because it can connect to a local Ollama service from the terminal and prompt the user to review commands and changes. That adds a human checkpoint, but it does not make every action safe by default. In practice, users still need to check which files the agent can access, which commands it can run, and whether requests actually go to the local service. The material supports a local-connection design; it does not establish that every configuration keeps the entire workflow offline.
Published Scores Are Not Laptop Results
The model-card figures in the article help explain the choice of the 9B model, but they do not tell us how well it runs on a particular laptop. LiveCodeBench v6 measures code generation, while BFCL-V4 evaluates function calling, which matters when an agent has to select a tool and provide its arguments. These are published scores cited in the material, not results from the local setup:
| Model | LiveCodeBench v6 | BFCL-V4 | |---|---:|---:| | Qwen3.5 4B | 55.8 | 50.3 | | Qwen3.5 9B | 65.6 | 66.1 | | gpt-oss-20b | 74.6 | Not reported |
The 9B model scores higher than the 4B model on both measures, making it a reasoned starting point. But the table says nothing about generation speed, success across the full OpenCode workflow, or performance on a particular codebase. The material also lists approximate download sizes: 3.3–4.0 GB for 4B, 6.6–7.6 GB for 9B, and 17–20 GB for 27B. Download size is not the same as required runtime memory; an estimate cited in the article puts a 6.6 GB 9B build at a 12–16 GB memory budget. The available material does not specify the device, quantization, or actual speed, so the model-card scores should not be treated as hardware guarantees.
Small Tasks Can Close the Loop; Larger Projects Remain Unproven
In the walkthrough described by the material, the agent works on a small Python example involving expense totals. The program originally returned only the latest expense; the change makes it return the cumulative amount. The article reports that the agent ran the tests, after which the author reran them independently: all five passed, and the example total was 25.50. This illustrates a practical offline task: locate a bounded issue in an existing project, edit local files, and check the result with tools already installed on the machine.
The point is not to prove that a local model can independently handle a large codebase. It is to show how a task can form a reviewable local loop. If the code, dependencies, and test tools are present, explaining a function, investigating a failing test, or making a small refactor need not involve a cloud service at every step. Five tests in a small example cannot stand in for a large repository, a multi-module change, or complex debugging. The available material provides no local task success rate, runtime measurements, or validation on broader projects.
Treat Offline as a Task Boundary, Not a Product Label
For an engineering team, the useful move is not to announce that it has an “offline coding agent,” but to identify which tasks can actually close locally. Before disconnecting, prepare the model, project, dependencies, and test tools. Work that requires downloading a new package, looking up a web page, or reaching an uncached service still needs a network. During deployment, disconnect deliberately, confirm that the agent has not switched to a cloud provider, and check whether any other enabled feature makes network requests. Using Ollama or open-weight models does not replace that verification.
A sensible fit is the existing review process: let the agent make a bounded change, verify it with local tests, and have an engineer inspect the diff and command history. This gives people another way to work while traveling, during unstable connectivity, or when code needs to stay on the machine. The tradeoff is that the team owns the resource budget, preparation, and capability limits. Treat an offline agent as a useful local execution option, not an equivalent replacement for a cloud agent. First verify that your own project can complete one specific task while disconnected, then decide whether to expand its role.