Ollama Config Generator

Generate a Modelfile, Ollama server tuning and coding-agent connection settings

A one-off ollama run is easy. Making a local model behave the same way tomorrow is not. Context length, temperature and system prompt are all session-scoped by default, so every new terminal starts from the model's defaults again. The settings that make a local model actually useful — a large context window, a system prompt suited to your work, a quantised KV cache so the context fits — only stick if you write them down somewhere Ollama reads at start-up.

This generator produces those persistent artefacts. You configure a model once in a short form and it emits four things: a complete Modelfile, the commands to build and manage the model, the server environment variables to put in your shell profile, and the environment settings that point an OpenAI-compatible coding agent at your local instance. Each tab has copy and download buttons. It is deterministic and instant, generated in your browser from form values — no model is called, nothing is uploaded, and no key is required.

The four files it produces

The Modelfile

This is the core output and the reason to use the tool rather than typing commands. A Modelfile is a small declarative file that describes a model derived from a base model, and ollama create turns it into a named model that carries your settings permanently.

The generated file always contains a FROM line naming the base tag, then a PARAMETER num_ctx line and a PARAMETER temperature line, then a SYSTEM block if — and only if — you supplied a system prompt. The system prompt is wrapped in triple double quotes so a multi-line prompt survives intact.

The practical difference this makes: a model built from a Modelfile with PARAMETER num_ctx 64000 has that context window every time it is run, by anyone, from any terminal, with no flags. The same setting applied with an interactive /set command lasts until you close the session. If you find yourself re-typing configuration, that is the signal you wanted a Modelfile.

The form fields

The model list is coder-oriented — the presets are qwen3-coder:30b, qwen2.5-coder:14b, qwen2.5-coder:7b, deepseek-coder:6.7b, codellama:13b-instruct and llama3.1:8b, each labelled with the approximate download size so you can match the choice to your machine before pulling. The custom option takes anything Ollama accepts as a tag, including a Hugging Face GGUF reference with an explicit quantisation. Leaving the custom box empty produces the placeholder your-model:latest, which is a prompt to fill it in rather than a working tag.

Server tuning, and why these three

The server env tab starts with a comment noting that these are set before ollama serve, and then emits only the overrides you actually enabled. If you enable none, it says so explicitly rather than emitting an empty file — defaults are fine for a single local user, and the output tells you that.

• OLLAMA_HOST=0.0.0.0:11434 makes the server accept connections from other machines. Ollama binds to localhost by default, which is why a laptop cannot reach the model running on a desktop until this is set. It also means anything on your network can then use your model, so set it deliberately.
• OLLAMA_FLASH_ATTENTION=1 enables flash attention: faster and less memory-hungry on long contexts, on supported GPUs.
• OLLAMA_KV_CACHE_TYPE quantises the key-value cache. At a 64K or 128K context the KV cache is a substantial share of resident memory, and q8_0 roughly halves it. This one has a dependency worth remembering: a quantised KV cache needs flash attention, so enable both or neither.

The relationship between the context field and the cache setting is the practical lever here. Choosing 128K without touching the cache type is how a model that fit yesterday stops fitting today. If you want a long context on constrained memory, take the context up and the cache down together.

Connecting a coding agent to a local model

The fourth tab solves a specific, common problem: you have an agent that speaks the OpenAI API — Codex, Qwen Code, Aider and others — and you want it to use your local model instead of a hosted one. Ollama exposes an OpenAI-compatible endpoint, so this is a matter of three environment variables:

• OPENAI_BASE_URL="http://localhost:11434/v1" — and the /v1 suffix is required. Pointing a client at the bare port is the single most common failure here, and it usually manifests as a 404 rather than anything that names the cause.
• OPENAI_API_KEY="local" — Ollama does not authenticate, but most clients refuse to start without a key set, so any non-empty string works.
• OPENAI_MODEL — set to whichever tag you configured above.

One caveat the generator cannot handle for you: if you built a customised model with ollama create my-coder, the model your agent should ask for is my-coder, not the base tag. The connect tab emits the base tag you selected in the form. Edit that line if you are running your built model, or your agent will use the base model with none of your Modelfile settings.

A complete worked sequence

• Configure the form — say qwen2.5-coder:7b, a 32K context, temperature 0.2 and a short system prompt.
• Download the Modelfile tab into your project directory as Modelfile.
• Run the pull command from the Commands tab to fetch the base model.
• Run ollama create my-coder -f Modelfile to build your version, then ollama run my-coder to confirm it works.
• If you enabled any server tuning, add the server-env lines to your shell profile and restart the Ollama server so it picks them up.
• Add the connect lines to the same profile, changing the model name to my-coder, and start your agent.

The generated commands also include ollama list, ollama ps and a stop line for the tag, which are the three you reach for when something is loaded that you did not expect. The install commands at the top of the tool cover Homebrew and the shell installer script, if Ollama is not on the machine yet.

What it does not generate

• No service definition. There is no systemd unit, launchd plist or Windows service output. The environment variables are emitted as shell exports for a profile; if you run Ollama as a managed service you will need to set them in the service definition instead, which is a different mechanism entirely.
• No TEMPLATE, ADAPTER, LICENSE or stop-token directives. The Modelfile covers FROM, two PARAMETER lines and SYSTEM. Other directives are valid Modelfile syntax and can be added by hand.
• Only two parameters. Sampling controls beyond temperature — top-p, top-k, repeat penalty and the rest — are not exposed.
• No memory estimate. The model options carry approximate download sizes, but the tool does not calculate whether your chosen context and cache settings will fit.
• No verification. Nothing checks that the tag exists, that the server is running, or that the port is free.

If your task is a single command rather than a persistent setup — running one model once, checking what is loaded, clearing disk space, or getting a quantisation suffix right — the Ollama command builder is built around the CLI and covers a wider set of subcommands, models and quantisation levels.

What a large context actually costs

num_ctx is the field people change first and understand last. It is not a quality setting — it is an allocation. Raising it reserves memory for the key-value cache in proportion to the context length, on top of the model weights themselves, and that memory is committed whether or not you ever fill the window.

Which is why the two settings in this form that look unrelated are in fact one decision. Going from 8K to 128K is a sixteen-fold increase in the cache the model must hold. Switching the cache type from f16 to q8_0 roughly halves the per-token cost of that cache, and q4_0 roughly halves it again. If a long context is genuinely necessary for your work — reading whole files, long refactors — take the context up and the cache precision down together, and enable flash attention, which the quantised cache requires anyway.

If it is not necessary, do not pay for it. A coder model at 32K with an f16 cache will usually be faster and more reliable on a constrained machine than the same model at 128K that spends its time swapping.

Where to put the exports

Both env tabs emit plain export lines, which means they take effect in shells started after you add them to your profile — ~/.zshrc, ~/.bashrc or equivalent. Two consequences catch people out.

• The server must be restarted to see server variables. Adding OLLAMA_FLASH_ATTENTION to your profile does nothing to an ollama serve process that is already running, and nothing at all if the server was started by a desktop app rather than your shell. Stop it and start it again from a shell that has the variables set.
• The connect variables are read by the agent, not by Ollama. They must be present in the environment of the terminal where you launch the coding agent. Setting them and then launching the agent from a different window is the usual reason a client still talks to a hosted API.