Ollama on Windows: install one runtime and verify one useful task
Plan a native Windows Ollama installation, separate storage from memory requirements, verify a first local model and diagnose common setup problems.
Ollama has a native Windows application, so a basic local experiment does not require adding Linux, Docker and a browser interface at the same time. Start with the native runtime and one appropriately sized model. Confirm that a useful task completes before adding another layer. This makes installation failures, resource limits and client-connection problems easier to distinguish.
A successful installation proves that software is present. It does not prove that a large model fits comfortably in memory or that a long coding session will be responsive. This guide provides a Windows-specific sequence, a storage worksheet and a small acceptance procedure. For genuinely local inference, use a local expense ledger; the cloud budget calculator applies only when the chosen workload uses hosted Ollama models.
Check the official requirements before downloading models
The Windows documentation currently specifies Windows 10 22H2 or newer, Home or Pro. It lists NVIDIA driver version 551.61 or newer and separate AMD acceleration requirements. The standard installer operates in the user's account without requiring Administrator rights. The binary installation needs at least 4 GB, with additional model storage required.
Check your actual operating-system version, available disk space, RAM and GPU resources. A GPU brand alone does not establish supported acceleration or sufficient memory. Use the current official hardware guidance for the specific card rather than a generic internet claim that all cards with a certain amount of VRAM behave identically. If you cannot verify acceleration, plan a small test instead of assuming full GPU execution.
Separate storage from working memory
| Resource | What it holds | Question before setup |
|---|---|---|
| Installation disk space | Runtime binaries and updates | Is there enough room for installation and maintenance? |
| Model storage | Downloaded model artifacts | Which drive owns the files and has expansion room? |
| RAM and GPU memory | Active runtime, model and working context | Can the representative workload run without severe pressure? |
| Other active applications | Browser, editor and background work | Will the computer remain useful while inference runs? |
Free disk space is not substitute VRAM, and a model's download size is not a complete memory requirement. Active context and concurrent work also matter. Do not conclude that a 20 GB file will behave well merely because a drive has 20 GB free. Keep room for the operating system and updates, and choose the smallest experiment that can answer your actual capability question.
Install the native application first
Use the official Windows installer reached from Ollama's website and follow its prompts. Avoid third-party repackaged downloads. After installation, start a fresh terminal if the command is not yet available, then confirm you are using the intended runtime. The application runs in the background, and its local API is served at the documented loopback address. Do not widen access while establishing the first local connection.
Do not install a second server in another environment as a reflex when the first command fails. Native Windows, WSL and containers are different execution and networking contexts. If an existing project intentionally uses one of those alternatives, follow that project's deployment instead of creating a competing instance. For a new personal test, keeping a single runtime reduces uncertainty about which process a client reaches.
Choose model storage before collecting a large library
The platform reference documents the user environment variable OLLAMA_MODELS for a custom model location and instructs you to quit and relaunch the app after changing environment settings. Choose a persistent drive with adequate space and stable access. Changing a setting should not be treated as proof that existing files have moved; inspect your storage plan and use an explicit migration process if you already have models.
For an illustrative capacity plan, reserve 6 GB for runtime and update headroom, 18 GB for two chosen model artifacts and 10 GB of additional margin. That totals 34 GB of planning space, not an official requirement or a recommendation for a specific model. Replace every number with your actual chosen downloads and maintenance needs. A larger library is not automatically a more useful setup.
Download and test one suitable model
The official CLI reference documents model download, listing and running commands. Select an actual available model that fits your intended task and resources, then use its exact identifier. Avoid copying a large model from a coding-agent example without checking the hardware implications. A small model can establish that the runtime works even if it is not your final quality target.
Start with an invented short prompt whose answer you can judge. Next try a representative task, such as summarizing a short note or explaining a small code snippet. Record whether the answer completes, whether it is correct enough for the purpose and whether the machine remains responsive. Check ollama ps while a model is active to inspect running-model information. Do not label a download completion as a successful inference test.
Use the right diagnostic for the symptom
If the command is not recognized, investigate terminal environment and the intended installation. If a connection is refused, inspect whether the background app is running and whether the client targets the correct host. If a model cannot be found, compare the exact identifier with the available inventory. If generation is extremely slow, examine workload size, active context and resource pressure instead of adding an API key.
For platform-specific failures, the Windows guide distinguishes application, server and upgrade logs. Select the log that matches the stage that failed. A server error and an updater error need different evidence. Redact private paths, prompts and credentials before sharing excerpts. Reinstalling may eventually be appropriate, but deleting model storage should not be the first response to an unexplained warning.
Add a browser interface only after the narrow path works
Once the native runtime completes your representative test, add an interface if it improves your workflow. Repeat the same model and prompt through the interface before enabling document retrieval, tools or remote models. See the Open WebUI connection guide for the distinction between browser, backend and model-server addresses. A new interface can add its own context settings and data storage.
If a coding agent is the real goal, proceed to a disposable repository and a narrow test rather than immediately giving it your primary project. The OpenCode guide and Codex CLI guide describe task acceptance. A machine that answers a short chat may need a different model or workload scope for long tool-assisted coding.
Turn observations into a cost decision
Record incremental electricity, any dedicated equipment purchase and time spent keeping the setup usable. For a machine already owned, the purchase may be irrelevant to a one-evening experiment. For a new dedicated workstation, ignoring it would distort the comparison. The total-cost guide explains the boundary without assigning your hardware a fictional benchmark.
If you switch to a cloud model because the local task does not fit, record that switch. A Windows client and local daemon can still route hosted work. Verify authentication and model selection, then include only that hosted consumption in a cloud-plan comparison. Keep any local preprocessing or interface-hosting expense outside the token line to avoid double counting.
Frequently asked questions
Do I need WSL for basic Ollama on Windows?
No; the official native application supports the basic path described here. Existing Linux-based workflows may have separate reasons to use WSL, but it is not required simply to begin a native experiment.
Does enough disk space mean the model fits in memory?
No. Storage and active memory solve different problems. Test the chosen model with realistic context and other applications running before deciding the setup is comfortable for daily work.
How should I update later?
Preserve a small baseline and update one layer at a time. The update checklist separates runtime, model, interface and driver changes.