Does your ‘local AI’ work without the internet?

Installed here. Thinking where?

A desktop icon is a location for a shortcut. It is not a privacy policy.

This experiment asks a narrow question: can one downloaded model answer a new prompt while this computer has no internet connection? It does not audit every application, prove the absence of telemetry, or establish what might be transmitted after reconnection.

Start with a spare computer if the one you use for calls, remote access, or work needs to stay online. Read these instructions and save the downloads before disconnecting.

Prepare a small local setup while online

Use a computer you control and non-sensitive test material. Save any work that needs connectivity before disconnecting. Ollama is the example runtime here; if you already use something else, apply the same test questions rather than treating installation as the objective.

Follow the official Ollama quick start. Choose a model offered for local download that fits your computer’s resources and intended license use. Download and run it once while online. Record the runtime version, exact model tag, and available hardware. An unfinished download is a setup failure, not evidence that inference requires a server.

Use ollama ls to identify installed models. Your later ollama run command must use that exact local model name, not a cloud model. This guide intentionally avoids promising that a particular model will fit every machine.

In a terminal, use ollama --version to record the client version. After selecting an appropriate local model, download it with ollama pull YOUR_LOCAL_MODEL. Replace that placeholder with the actual tag you chose. Do not paste it literally.

Separate the runtime from connected extras

Ollama’s FAQ documents local-only configuration through OLLAMA_NO_CLOUD=1 or its server configuration. Follow the platform-specific setup instructions, then restart the service so the setting applies. Keep its default loopback binding for a single-computer trial. Do not expose an API to the network to complete this test.

If your usual interface has web search, remote tools, cloud fallback, or another model provider, list those dependencies separately. Begin with the runtime’s direct local interface. A local model and a cloud-backed search tool are two different components.

Download the fictional prompt pack and read the expected checks. Submit only the task wording; keep the expected-answer checks outside the model prompt. Use the same instructions for the online and offline runs. The pack contains no private documents and gives you something more useful to assess than whether the chat window looks alive.

Record the old configuration before changing it. At the end, reconnect the network and restore any settings you deliberately changed if that is your intended normal setup. Do not change firewall rules or expose the local API.

Disconnect and ask something fresh

1. Save the online baseline output and the model identity.
2. Disconnect the test computer from all internet paths you use: Ethernet, Wi-Fi, and any cellular or tethered connection. Do not disable security software or change firewall rules.
3. In a browser on that same test computer, try a fresh, uncached request to a known HTTPS site and confirm it fails. An already open page is not a connectivity check. This is a practical connectivity check, not a complete network audit.
4. Close the chat session. Restart the local runtime while still disconnected.
5. Start the installed model again. For Ollama, run ollama run YOUR_LOCAL_MODEL, replacing the placeholder with the exact name from ollama ls.
6. Submit the test pack, then its fresh-input variation. Record whether an answer arrives and whether it meets the stated checks.

A successful restart and fresh answer are stronger evidence of offline operation than reopening a cached conversation. If the interface needs authentication or a missing file, record that dependency instead of silently reconnecting.

Grade useful work, not confident prose

The practice pack asks for extraction, a calculation, and a short rewrite. Score each task against its explicit expected result. Keep the exact wrong answer when a check fails. Record a rough elapsed time separately from correctness; the first answer after a restart may include model loading.

If one interface fails but direct local inference works, report those as separate outcomes. If a model runs out of memory, record the error and try a smaller locally downloadable model only as a new test. Change one variable at a time.

When finished, restore your normal connectivity deliberately. Continue to use made-up or public material until you understand the whole application’s behavior. Offline success establishes a capability under the tested conditions; it is not permission to feed the system everything you own.

For the broader decision about usefulness, see the first local-AI experiment. Sometimes the best result is a small reliable job, performed without asking a remote server’s opinion.

What we have checked here

Documentation checked October 21, 2026. The worksheet, prompt download, page layout, and links were verified as publication assets. The offline model run, accuracy scores, and timing remain not measured. Software being installed is not an offline test result.

When you run the experiment, record the model, runtime version, network check, restart, exact answers, errors, and conditions. A model answering offline establishes that capability in those conditions. It does not audit the rest of the application or what happens after reconnection.