Ollama Command Builder

Compose Ollama CLI commands with the right model tag and quantisation

The hard part of the Ollama command line is never the verb. ollama run is obvious. What is not obvious is the argument after it: whether the model you want is llama3.1:8b or llama3.1:8b-q8_0, whether the quantisation suffix is spelled q5_K_M or Q5_K_M, whether it exists in the Ollama library at all or has to be pulled from Hugging Face as hf.co/org/repo:Q4_K_M — and whether the result will fit in the memory you have.

This builder composes that command for you. Pick an action, pick a model, pick a quantisation, and it produces the exact command line, an inline estimate of the memory the choice needs, and a warning when the model is not in the Ollama library and the tag falls back to Hugging Face syntax. It runs entirely in your browser against a curated model list — there is no lookup against ollama.com or Hugging Face, and nothing you select is sent anywhere.

The nine actions it builds

Four of these — serve, list, ps and the model-free forms — take no model argument, and the builder hides the model picker when you select one of them. The other five all operate on a tag, which is where the interesting work happens.

How the tag is resolved

This is the part worth understanding, because it explains why two models that look equally popular produce very different commands.

The builder keeps a curated map from its internal model ids to Ollama library tags — entries such as llama3.1:8b, gemma3:27b, qwen3-coder:30b, deepseek-r1:14b, phi4:14b, mistral-small:24b, gpt-oss:20b and mixtral:8x7b. If the model you pick has an entry, you get a library tag. If it does not but the model has a Hugging Face repository, you get Hugging Face GGUF syntax instead, and the tool raises a warning telling you it is pulling a community GGUF and that you should verify the repo and quant tag exist on the model's Hugging Face page. That warning is the honest signal that the command is a best guess rather than a curated fact.

A custom model with no repository at all falls back to the placeholder your-model:latest, with its own warning telling you to substitute a real tag.

Quantisation suffixes, spelled correctly for each source

The same quantisation is spelled differently in an Ollama library tag and in a Hugging Face GGUF reference, and this is a reliable source of "manifest not found" errors. The builder applies the right casing automatically:

Note the asymmetry in the library column: the quantisation family letter stays uppercase (q5_K_M) while the leading q is lowercase, which is how the library tags are actually spelled. Note too that Q4_K_M produces no suffix on either side. The bare tag already points at it, so llama3.1:8b and llama3.1:8b-q4_K_M would fetch the same weights — the builder emits the clean form.

Worked through: picking Llama 3.1 8B at Q4_K_M gives ollama run llama3.1:8b. Switching the quantisation to Q8_0 gives ollama run llama3.1:8b-q8_0. Picking a model with no library entry gives something of the form ollama run hf.co/org/repo:Q5_K_M, with the same quantisation expressed in Hugging Face's uppercase convention.

The memory estimate

Alongside the quantisation selector the tool shows an estimate of the memory the current model-and-quantisation choice needs, computed from the model's parameter count and the bytes-per-parameter of the chosen quantisation. It is there to catch the mistake before the download, not after: a 70B model at Q8_0 is a very different proposition from the same model at Q4_K_M, and the difference is visible before you commit to fetching several gigabytes. Treat it as an estimate for planning — actual resident memory also depends on your context length and what else is loaded.

Flags versus session settings — the distinction that catches people

Not every option you want is a command-line flag. Three of the run flags genuinely are, and the builder appends them to the command:

• --keepalive with a duration such as 5m, or -1 to keep the model resident indefinitely, or 0 to unload immediately after the response.
• --format json to force valid-JSON output.
• --verbose to print timing information after each response.

Context window, temperature and system prompt are not flags on ollama run. If you set them and the action is run, the builder emits them separately as interactive commands to paste once the session has started — /set parameter num_ctx …, /set parameter temperature … and /set system … with the prompt safely single-quoted — and raises a warning explaining exactly this: these have no run-flag, so either paste the /set lines after the model starts, or bake them into a custom model with create. Expecting --num_ctx to exist is one of the most common Ollama frustrations, and it is a real gap in the CLI rather than a mistake on your part.

Chaining commands into a script

Each composed command can be committed as a step, and the steps accumulate into a single script you can copy in one go. The natural sequence is pull, then create, then run — or a maintenance pass of list, ps and rm. The preview block always shows the current selection appended to the committed steps, so the script you copy is the whole thing including what you are still editing. Individual steps can be removed without disturbing the rest.

Custom models and server tuning, briefly

Selecting create also renders the Modelfile the command expects, with a FROM line for the resolved tag plus whatever parameters and system prompt you set, and there is a panel of Ollama server environment variables that renders as export lines on Unix or setx lines on Windows. Both are here so the command you build is runnable end to end. If persistent configuration is your actual task rather than a one-off command, the Ollama config generator is built around it and goes considerably further.

Troubleshooting

Limits worth knowing

• The model list is curated. A brand-new model may not appear, and its library mapping may not exist yet even if it does.
• Nothing is verified against a live registry. The builder produces correctly-formed commands; whether a specific tag has been published is between you and the registry.
• The memory figure is an estimate from parameter count and quantisation, not a measurement of your machine.
• The commands cover the everyday CLI surface listed above, not every flag Ollama accepts.

Choosing a quantisation level

Quantisation is the main lever between "this model does not fit" and "this model fits but is worse", and the selector labels each level with a quality rating so the trade is visible while you choose rather than after you download.

The memory estimate is driven by bytes per parameter, which is what makes the choice concrete: FP16 costs about 2 bytes per parameter, Q8_0 about 1, and Q4_K_M around 0.6. That is why the same model at the default quantisation is roughly a third the size of its unquantised form, and why stepping from Q4 to Q3 buys far less than stepping from Q8 to Q4 did.

The practical heuristic: prefer a larger model at Q4_K_M over a smaller model at Q8_0 when both fit, and only drop below Q4 when the alternative is not running the model at all. Start at the default, and move up only if you can measure a difference in your own work.