Ollama Models: Pick, Pull and Run Them Locally

Ollama models are the open-weight models listed at ollama.com/library, and you run one with ollama run <name>. The first run downloads the files, later runs start from disk. Pick the tag by file size against your memory, then raise the context length if you plan to use an agent. This page covers the library, the commands, sizing, quantization, context and cloud models. We checked Ollama's docs and library on 31 October 2026.

If you have not installed Ollama yet or want the full runtime story, start with our Ollama hosting profile. Here we stay on the models themselves.

How the Ollama library works

The library is a catalog of model families. Each family has one page, and each page has tags. A tag is a specific build of the family: a parameter size, sometimes a quantization, sometimes a variant such as instruct or base. When you type ollama run qwen3-coder, Ollama uses the latest tag, which the page marks as an alias for one of the real sizes.

You can see this on the qwen3-coder page. Its tags are latest, 30b and 480b. The latest tag and the 30b tag point to the same 19 GB model, and 480b is 290 GB. All three list a 256K context window and text input. So ollama run qwen3-coder and ollama run qwen3-coder:30b give you the same files.

Each library entry also carries capability labels. The ones we saw on the listing were tools, thinking, vision, embedding, audio and cloud. They tell you what the model can do before you download it. A tools model can be called by an agent that wants function calls. A vision model accepts images. An embedding model returns vectors and does not chat.

What the names mean

One caution. The listing order and which models are popular change often. We list the models below as they appeared on 31 October 2026, and you should look at the library page itself before you commit to a download.

Pull and run a model

Install Ollama first. The quickstart does not print install commands for each system. It links to the download page and tells you to open the app. On Linux, the Linux page gives a script:

curl -fsSL https://ollama.com/install.sh | sh

The Linux page also says that if the server is not running you start it with ollama serve. After that, the commands below cover most days.

ollama pull qwen2.5-coder:7b
ollama run qwen2.5-coder:7b
ollama ls
ollama ps
ollama stop qwen2.5-coder:7b
ollama rm qwen2.5-coder:7b

pull downloads a model. run starts an interactive session and pulls first if the model is missing. ls lists what you have on disk. ps lists what is loaded in memory right now. stop unloads a model, and rm deletes it from disk. The CLI page documents run, pull, ls, ps, stop, rm, create, signin, signout, serve and launch.

Where the files go and how long they stay loaded

The FAQ gives default storage folders. On macOS it is ~/.ollama/models. On Linux with the standard installer it is /usr/share/ollama/.ollama/models. On Windows it is C:\Users\%username%\.ollama\models. Set OLLAMA_MODELS to use a different folder. On Linux, the ollama user needs read and write access to it.

A loaded model stays in memory for five minutes after the last request. You change that server-wide with OLLAMA_KEEP_ALIVE, or per request with the keep_alive API parameter. Ollama listens on 127.0.0.1 port 11434 unless you set OLLAMA_HOST.

Calling a model from code

The local server needs no API key. The quickstart shows a chat request:

curl http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:e2b",
    "messages": [
      {
        "role": "user",
        "content": "Say hello in one sentence."
      }
    ],
    "stream": false
  }'

The reply text is in message.content. Ollama's docs also say OpenAI and Anthropic compatible clients work against the cloud API, with a subset of the features. Our LiteLLM page covers putting a gateway in front when several tools need one endpoint.

Pick a model by RAM or VRAM

For the hardware side in more depth, see our GPU requirements for LLMs guide; for setup from scratch, how to run an LLM locally and the Ollama setup guide.

Ollama's documentation gives no sizing formula, so we will say plainly what it does and does not state. It states one data point: the gemma4:e2b download is about 7.2 GB, and the quickstart recommends 8 GB of available VRAM, or unified memory on a Mac. It says Ollama can use system RAM when VRAM is short, with slower answers. It says larger context windows need more memory.

What you can do with that is read the file size on each tag. The size is the floor for memory use, because the weights have to sit somewhere. Context adds to it. Treat the table below as our reading of the published tag sizes, not as an Ollama guarantee.

The "fits in" column is our estimate from the file sizes, with headroom for the operating system and the KV cache. A 19 GB file does not run well on a 16 GB machine. A Mac shares one pool between the system and the GPU, so a 32 GB Mac has less than 32 GB for a model.

We have no separate VRAM-by-model-size page live yet, so the published tag sizes above are the source to trust.

Check where the model is running

Run ollama ps after you load a model. The PROCESSOR column shows 100% GPU, 100% CPU, or a split such as 48%/52% CPU/GPU. A split means the model did not fit in VRAM and part of it runs on the CPU. The context length docs say that for best performance you should avoid offloading the model to CPU.

GPU support in short

The GPU page lists these rules. NVIDIA cards need compute capability 5.0 or higher and driver 550 or newer, and cards from 5.0 through 6.2 need driver 570 or newer. On Linux, AMD cards need the ROCm v7 driver. On Windows, AMD support is limited to some Radeon RX 7000 series cards and Radeon PRO W7500 through W7900. Apple devices use Metal. Vulkan is available on Windows and Linux and is on by default when the backend is installed. Set OLLAMA_VULKAN=0 to turn it off.

Pick a model by task

Match the capability label to the job first, then the size.

Coding

Use a code-specific family or a recent general model that lists coding and tools support. The next section lists what the library shows. Agents need tools support in practice, since they call functions to edit files and run commands. Pick a tag with tools if you plan to use one.

Chat and reasoning

The general families on the listing include llama3.1, llama3.2, llama3.3, qwen3, qwen3.5, gemma3, gemma4, mistral, phi4 and gpt-oss. The deepseek-r1 and qwen3 entries carry the thinking label, which means they can produce reasoning traces. gpt-oss is described as OpenAI's open-weight reasoning and agentic models, in 20b and 120b sizes, and has a cloud label. Our GPT-OSS 120B model page has the profile.

Vision

Models with the vision label take images. The listing shows llava, llama3.2-vision, minicpm-v, qwen2.5vl, qwen3-vl and gemma3. glm-ocr is described as multimodal OCR for complex documents. Vision models are usually larger than text-only models of the same family, so check the tag size before you pull.

Embeddings

Embedding models turn text into vectors for search and retrieval. The listing shows nomic-embed-text, mxbai-embed-large (335m), bge-m3 (567m, multilingual) and qwen3-embedding (0.6b, 4b, 8b). The CLI page gives a one-line example with a different embedding model, ollama run embeddinggemma "Hello world". These models are small, and you can run them next to a chat model.

Coding models in the library

This is the set the library page showed on 31 October 2026. We list only what the listing says.

The first four are code-specific by their own descriptions. The last four are general models whose blurbs mention coding. We make no claim about which is best, because the library page carries no benchmark numbers and we ran none. If you want a closer look at one of the newer families, the Qwen3.8 27B model page on our site is a starting point.

Two practical notes. First, older families such as codellama and deepseek-coder show no tools label, which matters if your agent needs function calling. Second, qwen2.5-coder lists a 32K context window on its tags, while qwen3-coder lists 256K. The window a model supports and the window you actually run are different things, as the context section shows.

Quantization tags

Quantization stores a model's weights with fewer bits. The file gets smaller and uses less memory, and the answers can get slightly worse. The library shows this directly in tag names.

On the qwen2.5-coder tags page the 0.5b-base variant alone has these builds, with published sizes: q2_K at 339 MB, q3_K_S at 338 MB, q3_K_M at 355 MB, q3_K_L at 369 MB, q4_0 at 352 MB, q4_1 at 375 MB, q4_K_S at 385 MB, q4_K_M at 398 MB, q5_0 at 397 MB, q5_1 at 419 MB, q5_K_S at 413 MB, q5_K_M at 420 MB, q6_K at 506 MB, q8_0 at 531 MB and fp16 at 994 MB. The pattern is clear: lower numbers are smaller, and fp16 is the uncompressed reference.

To pull a specific build, add it to the tag:

ollama pull qwen2.5-coder:0.5b-base-q4_K_M

What the default tag uses

The qwen2.5-coder:7b page shows Q4KM quantization, 7.62B parameters and a 4.7 GB blob. That is a 4-bit build. We did not find a page statement that every default tag uses Q4KM, so check the model details of the tag you pull.

Import and make your own

Ollama does not quantize GGUF files during import. The import page says to quantize first with a GGUF tool such as llama.cpp's llama-quantize, then import the result with a Modelfile that starts with FROM /path/to/file.gguf. The Modelfile reference lists other FROM forms: an existing model such as FROM llama3.2, a split GGUF with FROM ./model-*.gguf, and a safetensors directory. We did not find a quantize flag on the pages we read, so we do not describe one.

Quantizing the KV cache

Separately from the weights, the context cache can be compressed. OLLAMA_KV_CACHE_TYPE defaults to f16, applies to all models, and takes effect with Flash Attention on. The FAQ says q8_0 uses about half the memory of f16 with minimal quality loss, and q4_0 uses about a quarter with a loss that can show up at long context sizes. It adds that models with high GQA counts, Qwen2 for example, may be affected more. OLLAMA_FLASH_ATTENTION=1 forces Flash Attention on and 0 turns it off. Ollama uses it automatically when the backend and device support it.

Context length settings

Context length is how many tokens the model can hold in view at once: your prompt, the files an agent reads, and the reply. It is the setting that most often trips up coding use.

The context docs say the default depends on your VRAM:

Cloud models default to their maximum. The same page recommends at least 64000 tokens for web search, agents and coding tools. That is far above the 4k default on a typical laptop, so an agent can fail in odd ways until you raise it.

Change it in the Ollama app with the context length slider in settings. If you run the server yourself, set it at start:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

The Modelfile reference documents PARAMETER num_ctx as "the size of the context window used to generate the next token," with a default of 2048. Note that this default differs from the VRAM-based default on the context page. The context page does not mention num_ctx, so we cannot say how the two interact. If you build a model with a Modelfile, set num_ctx there explicitly and confirm with ollama ps.

Check what you got

Run ollama ps and read the CONTEXT column next to PROCESSOR. The docs example shows 131072 with 100% GPU. A bigger window costs memory, so watch for the CPU split. The docs advice is blunt: use the maximum context length for a model where you can, and avoid offloading to CPU.

Concurrency multiplies the cost

Two server settings change memory use. OLLAMA_NUM_PARALLEL sets parallel requests per model and defaults to 1. The FAQ says RAM scales with that value times OLLAMA_CONTEXT_LENGTH. OLLAMA_MAX_LOADED_MODELS caps how many models stay loaded and defaults to 3 times the GPU count, or 3 for CPU-only. OLLAMA_MAX_QUEUE defaults to 512 queued requests before the server returns a 503.

Cloud models

Some library entries run on Ollama's servers. In the app or CLI you use a tag with the cloud suffix, such as gemma4:cloud. Over the API you use the exact model name from the model list, such as gemma4:31b. Cloud models need no download.

To use the API, create a key at ollama.com/settings/keys and export it:

export OLLAMA_API_KEY="your_api_key"

Requests go to https://ollama.com/api/chat with an Authorization: Bearer header. The cloud docs list the available models at https://ollama.com/api/tags. For the app or CLI, run ollama and follow the prompts to sign in. The CLI page also lists ollama signin and ollama signout.

What is cloud-hosted

The cloud filter on the search page showed these on 31 October 2026, with the library's own descriptions:

The search page listed more than these. We picked the ones that mention coding or agents, or that are big enough that few people run them locally.

Pricing for cloud use

Ollama's pricing page lists these plans:

Usage is billed per million tokens at each model's rate, with off-peak rates outside 12:00 to 18:00 UTC on weekdays and all day on weekends. Included usage resets monthly and does not roll over. Requests past the concurrency limit queue, and a full queue rejects new ones. The page says running models on your own hardware is always unlimited. The cloud docs list no specific usage limits and point to your usage page for numbers.

Privacy

The cloud docs say Ollama processes cloud prompts and responses only to answer your requests and does not use them to train models. They link a privacy policy for the details. If you want local models only, set OLLAMA_NO_CLOUD=1 or "disable_ollama_cloud": true in ~/.ollama/server.json, then restart. The FAQ says this removes cloud models and web search. Retired cloud models are flagged in your usage settings, and downloaded local models are not affected.

Use Ollama models with coding agents

Our local coding agent with Ollama guide walks through a full agent setup end to end.

Ollama has a launcher for coding tools. ollama launch sets up a supported app and starts it with an Ollama model, for example ollama launch claude --model qwen3.5. The integrations page lists Claude Code, OpenCode and the DeepSeek Harness as coding agents you can launch this way. It also lists Claude Desktop, ChatGPT Desktop, OpenClaw, Hermes Agent and a VS Code extension. The cloud docs add ollama launch codex to the examples.

Claude Code by hand

The Claude Code integration page gives a manual route too. Set these variables, then pass a model:

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
claude --model qwen3.5

That page says to set the context length to 64k or higher for larger repositories. It names qwen3.5 for the local example, gemma4:cloud for non-interactive runs and kimi-k2.7-code:cloud and glm-5.3-flash for cloud connections, and gives no recommended list. See our pages on Claude Code and OpenCode for what each agent does on its own.

Other agents

Cline, Continue and Aider all let you point at a local model server. We cover the setup differences on the agent pages for Cline, Continue and Aider. Check each agent's own docs for the exact base URL field, since Ollama's integrations page does not list them.

A checklist for agent use

1. Pick a model with the tools label.
2. Set the context to 64k or more, and confirm with ollama ps.
3. Check that PROCESSOR shows 100% GPU, or accept slower runs.
4. Keep OLLAMA_NUM_PARALLEL at 1 unless you need parallel sessions.
5. Use a cloud tag if your hardware cannot hold a coding model of the size you want.

Ollama or another runtime

Ollama is one of several ways to run open weights. Our Ollama vs LM Studio comparison covers the desktop app route, and the LM Studio profile has the details. If you plan to serve many users, read Ollama vs vLLM. For the lower-level engine under many local tools, see llama.cpp vs Ollama.

Our take

Start small and measure. For a first coding model on a 16 GB machine, the published sizes point at a 7b or 14b tag. For a 24 GB GPU, a 30b tag with a trimmed context is the upper end. Beyond that, a cloud tag is simpler than buying hardware. These are our readings of the documented sizes. We did not run these models and we are not claiming speed or quality results.

Two settings deserve attention before any tag choice. Raise the context to at least 64k for agents, and check ollama ps for CPU offload. Most complaints about local models in agents come from the 4k default, which the docs themselves flag.

Limits and gotchas

• The library changes. Names, sizes and labels on this page are from 31 October 2026.
• The docs do not give a memory formula, so any "fits in" claim is an estimate.
• num_ctx has a 2048 default in the Modelfile docs and a VRAM-based default on the context page. We could not reconcile the two from the docs.
• Cloud model names differ between the app (:cloud) and the API (exact names from the tag list).
• Cloud use needs sign-in and, past included usage, paid credits.
• Models you download keep working if a cloud model is retired.