Local inference means a model can run on your machine. An offline workflow means the complete task can finish without reaching a remote service. A desktop application can satisfy the first description while still using cloud search, remote embeddings or online tools for parts of the work.
This guide provides a proposed test protocol, reviewed September 14, 2026. It is not a benchmark of an installed workstation. Use non-sensitive sample files and a test environment, then record exactly which task and configuration you evaluated.
- 01Test the complete task.Generating an answer locally does not establish where retrieval, tools or document processing happen.
- 02Prepare dependencies before disconnecting.A missing model download is a setup dependency, which differs from a remote inference requirement.
- 03Limit the conclusion.Offline success for selected tasks does not certify all future behaviour or prove the absence of data retention.
- 04Attempted is not transferred.A failed connection attempt still reveals a dependency; record attempts and successful transfers separately.
01 — Practical guidanceDefine what must remain local
Write the boundary before choosing a tool. Does the requirement cover prompts and answers only, or also documents, embeddings, logs and tool calls? Is communication with another machine on the office network allowed? A workflow can be disconnected from the internet while still accessing a local network service.
Ollama’s FAQ distinguishes local operation from cloud-hosted models and documents a local-only configuration. This is an example of why the product name alone is insufficient evidence: the same application can expose more than one execution mode.
A hardware purchase should follow the workload, not replace this boundary analysis. More RAM or a faster GPU cannot make an external search API operate offline. Our local workstation economics guide addresses cost after the dependency requirements are understood.
02 — MethodMap the dependencies behind one answer
Trace a single representative task from input to saved result. The table separates setup dependencies from dependencies that may be used every time. Mark each row local, remote, unused or unknown only after checking the selected configuration.
A desktop window is an interface, not evidence of where computation occurs. Similarly, a file stored locally can be uploaded by a connector. Inspect the actual tool configuration and data path rather than inferring locality from where the user clicked.
| Stage | Question to answer | Evidence to record |
|---|---|---|
| Model preparation | Are model files already available locally? | Model identity, location and download requirement. |
| Inference | Which endpoint processes the prompt? | Selected model and runtime configuration. |
| Document processing | Where are parsing and OCR performed? | Tool identity and processing destination. |
| Retrieval | Where are embeddings and the search index created? | Embedding endpoint and index location. |
| Tools | Can search, connectors or actions contact services? | Enabled tools and required destinations. |
| Output and logs | Where are results and diagnostic records stored? | Storage paths, sync settings and retention choices. |
03 — The evidenceUse the runtime’s documented local-only controls
The reviewed Ollama documentation provides disable_ollama_cloud in its server configuration and the alternative environment variable OLLAMA_NO_CLOUD=1. It says to restart Ollama after changing the configuration and identifies a log message confirming cloud features are disabled. Follow the current documentation for the installed version.
That setting disables Ollama cloud models and web search. It does not establish that a separate desktop frontend, browser extension or tool server has stopped making its own network requests. Treat each connected component as a separate dependency in the assessment.
Before applying a configuration change, save the existing setting and identify how to restore it. Perform the experiment on your own test environment without interrupting other people’s work. A narrowly scoped test is easier to interpret than changing a machine’s network policy while unrelated applications are active.
04 — The decisionRun a controlled offline check
Prepare a harmless document with distinctive text and a clear expected result. Download the intended local model in advance. Then record the runtime version, selected model, enabled tools and which network boundary you will disconnect. Avoid using a cached answer as the test case.
Run the same task online and offline, saving outputs and errors. Use fresh sample content so successful completion requires processing the test input. If you inspect network activity, distinguish attempted connections from successful transfers; a failed request may still reveal a dependency.
The protocol below is a proposed assessment sequence. It is not evidence that we performed the experiment. A useful record should be repeatable by someone else with the same configuration.
- Prepare the model and synthetic input while connected. Record the configuration.
- Run a baseline task and save the result and relevant logs.
- Disconnect the defined external network path in the test environment.
- Run a fresh task using the synthetic input, including the retrieval or tool steps you actually need.
- Record successes, failed dependencies, attempted connections and saved output locations.
- Restore the original network state and classify each finding without extending it beyond the test.
05 — The failure caseInterpret both success and failure narrowly
If generation succeeds but document retrieval fails, the test supports local generation and exposes a retrieval dependency. It does not prove that the model itself is remote. If the entire task succeeds, the evidence supports that task under that configuration and network boundary.
An offline test cannot by itself establish what the software retained, whether it will upload queued information after reconnection or whether a future update changes its behaviour. Those questions require configuration review, logs and the relevant security assessment. Avoid calling a brief disconnect test a privacy audit.
For AI implementation planning, decide whether each remote dependency is acceptable, replaceable or a reason to change the workflow. The VRAM reference can then help size the local model rather than being asked to solve an architectural dependency.
If the task uses agents and local tools, compare the boundaries with the agent sandbox reference. Local execution and isolation are related decisions, but they are not the same property.
As-of date. September 14, 2026. Sources reviewed for this article; the article is dated September 13, 2026.
Method. Ollama documentation review plus six original dependency questions and a proposed offline assessment sequence. No runtime, network capture or hardware performance measurement was performed.
Sources. Ollama FAQ.
Limits. A task-level connectivity test is not a security certification. Separate frontends, tool servers, local networks and post-reconnection behaviour remain independent assessment boundaries.
06 — The failuresFour offline tests that proved the wrong thing
The protocol is strict about scope because a loose offline test produces a confident wrong answer. The illustrative tests below each reached a conclusion the evidence did not support. They are patterns the dependency table describes, not inspected installations.
The interface inference
A desktop window generated an answer, so the team recorded the workflow as local. The window is an interface; the embeddings and search behind the answer were remote. Nobody traced the task from input to saved result.
The flag assumed global
OLLAMA_NO_CLOUD was set and confirmed in the log, and the team declared the stack offline. The setting disables Ollama cloud models and web search; the separate frontend and a tool server kept making their own requests.
The cached answer
The offline run reused the same prompt as the baseline and returned the same answer quickly, so it passed. The answer came from a cache; fresh synthetic input would have exercised retrieval and shown the dependency.
The privacy audit
A brief disconnect test succeeded and the write-up called the workflow private. The test showed one task completing across one network boundary; retention, queued uploads after reconnection and future updates were never examined.
Each conclusion overreached by exactly the distance between what was tested and what was claimed. The record in the next section is designed to keep those two the same length.
07 — The methodWhat the test record should hold
The protocol says a useful record should be repeatable by someone else with the same configuration, and that sets the fields. Before the test: the runtime version, the selected model and its local location, every enabled tool and connector, the frontend in use, and the exact network boundary that will be disconnected, with the existing settings saved so they can be restored. During the test: the baseline run’s output and logs while connected, then the offline run on fresh synthetic input, with outputs, errors and every attempted connection recorded separately from every successful transfer.
After the test, the record classifies each row of the dependency table as local, remote, unused or unknown for that configuration, and it says in one sentence what the test establishes: which task, which configuration, which boundary. An illustrative record reads: generation completed offline on the stated model; document retrieval failed with a connection attempt to a remote embedding endpoint; the frontend attempted a telemetry call that did not complete; retention and post-reconnection behavior were not tested. That is a deployment decision someone can act on, because it says what to replace and what remains unknown.
The record ends with the restore step, confirming the original network state and configuration came back, and with the scope statement the interpretation section asks for. If the task later changes, the record shows which dependency rows need re-testing rather than requiring the whole protocol again.
Local means the model runs on this machine. Offline means this task completed without reaching a remote service. Private means retention, uploads and updates were examined. The test this guide proposes can establish the second for one task; it does not establish the third.
08 — Next stepOffline is a test result, not an interface setting
Run the protocol once on the task that matters most, with the record above filled in as you go. The rows that come back remote or unknown are the deployment decision, and the scope sentence at the end is what stops the result being quoted as more than it is.
Make offline a tested property of the task
Record the whole path from input to saved result, then test the workflow across the network boundary that matters. Keep successful local execution, failed remote dependencies and untested privacy questions separate. That produces a usable deployment decision rather than a claim based on a desktop interface.