Ollama's OpenAI API default temperature is 1.0, not 0.8

What temperature does Ollama’s OpenAI-compatible API use by default? 1.0, and top_p 1.0 too, whenever the request leaves them out. Ollama’s own /api/chat uses 0.8 and 0.9 for the same model, and llama.cpp’s llama-server uses 0.8 with top_p 0.95 and min_p 0.05. I read those values from the servers’ own logs and then measured what they do to a JSON extraction task. With nothing set, 67 of 80 replies through /v1/chat/completions passed the schema, against 77 of 80 through /api/chat and 79 of 80 through llama-server. With only temperature: 1.5 set, /v1 fell to 39 of 80. The other two routes held at 73 and 75.

So if you point the OpenAI SDK at Ollama and set nothing, you are not getting Ollama’s documented defaults. You get a hotter, untruncated sampler, and small models feel it.

This is the fifth post on running local models on a CPU. The last one found that llama-server’s truncation samplers (top_k, top_p, min_p) decide whether high temperature breaks JSON, and ended with a question I had not tested: Ollama’s defaults differ, so what does Ollama actually do? This post is the answer.

What temperature does Ollama’s OpenAI API use by default?

Ollama 0.40.3 runs llama.cpp’s llama-server underneath (I showed that here) and starts it with --log-verbosity 4. At that level llama-server logs the sampler chain and every parameter for each request. So instead of trusting docs, I sent one short request per condition to each server and saved what got logged. Same GGUF file everywhere, and an Ollama Modelfile with nothing but FROM, so no model-specific PARAMETER lines were involved.

Server and route	Client sends	temperature	top_k	top_p	min_p
llama-server /v1/chat/completions	nothing	0.8	40	0.95	0.05
Ollama /api/chat	nothing	0.8	40	0.9	0
Ollama /v1/chat/completions	nothing	1.0	40	1.0	0
llama-server /v1/chat/completions	temperature 1.5	1.5	40	0.95	0.05
Ollama /api/chat	temperature 1.5	1.5	40	0.9	0
Ollama /v1/chat/completions	temperature 1.5	1.5	40	1.0	0

Repeat, presence and frequency penalties were off in every case. This is what the /v1 log line looked like with an empty request:

sampler chain: logits -> ?penalties -> ?dry -> ?top-n-sigma -> top-k -> ?typical -> ?top-p -> ?min-p -> ?xtc -> ?temp-ext -> dist
repeat_last_n = 64, repeat_penalty = 1.000, frequency_penalty = 0.000, presence_penalty = 0.000
top_k = 40, top_p = 1.000, min_p = 0.000, xtc_probability = 0.000, xtc_threshold = 0.100, typical_p = 1.000, top_n_sigma = -1.000, temp = 1.000

The ? marks samplers that are switched off by their value. On /v1, top_p, min_p and temperature scaling are all no-ops, so the only truncation left is top_k 40. The native route’s chain shows top-p without the question mark.

The source explains it. Ollama’s OpenAI translation layer fills in OpenAI’s own defaults when the fields are missing (openai/openai.go, unchanged on the main branch as of early October):

if r.Temperature != nil {
	options["temperature"] = *r.Temperature
} else {
	options["temperature"] = 1.0
}
// ...
if r.TopP != nil {
	options["top_p"] = *r.TopP
} else {
	options["top_p"] = 1.0
}

1.0 is OpenAI’s documented default for both fields, so this is a deliberate compatibility choice, not a typo. But Ollama’s Modelfile docs list the defaults as temperature 0.8 and top_p 0.9, and nothing on the OpenAI compatibility page says the /v1 routes use different ones.

Does the default change the output?

To find out, I reused the task from the JSON output and JSON temperature posts: 20 hand-labelled support emails, each to be turned into a JSON ticket with a name, an order id, a category, a list of items and a refund flag. The schema went into the system prompt and nothing constrained the output. A reply counts as valid if it passes the schema after I strip a Markdown fence, and right if all five graded fields match my labels.

Two models, bartowski’s Q4_K_M files: Qwen 3.5 0.8B, which was the most sampling-sensitive model last time, and Qwen 3.5 2B, the most accurate small one. Thinking was off on every route (think: false on /api/chat, reasoning_effort: "none" on Ollama’s /v1, enable_thinking: false on llama-server). Every sampled condition ran twice per email with its own seed, so each cell below is 80 replies across both models.

The requests send as little as possible, because the point is what a client gets by default:

# bench.py: Ollama's OpenAI route with nothing but the messages
p = {"model": model, "messages": messages, "max_tokens": 300, "seed": seed,
     "reasoning_effort": "none", **samplers}   # samplers = {} or {"temperature": 1.5}

Condition	Effective samplers	Valid	All 5 fields right
llama-server, temperature 0	greedy	39/40	33/40
Ollama /api/chat, temperature 0	greedy	39/40	32/40
llama-server, nothing sent	0.8, top_p 0.95, min_p 0.05	79/80	53/80
Ollama /api/chat, nothing sent	0.8, top_p 0.9	77/80	56/80
Ollama /v1, nothing sent	1.0, top_p 1.0	67/80	41/80

Per model, the /v1 defaults cost both of them. Qwen 3.5 0.8B got 33 of 40 valid and 14 right through /v1, against 39 valid and 23 right on llama-server. Qwen 3.5 2B got 34 valid and 27 right, against 40 and 30. The native route and llama-server were within noise of each other (more on what noise means here below).

The failures through /v1 were not dramatic. Most replies still looked like tickets, just wrong in small ways: a key called item instead of items, an order id that does not match ORD- plus five digits, a category of "information" that is not in the enum, a quantity of 0. The field that suffered most was items, right in 54 of 80 replies through /v1 against 69 of 80 on llama-server.

What happens when you only set temperature?

This is the common case: a client or a tutorial sets temperature and nothing else. On llama-server and on Ollama’s native route, the truncation samplers stay on. On /v1, top_p stays at 1.0.

Condition	Effective samplers	Valid	All 5 fields right
llama-server, temperature 1.5	1.5, top_p 0.95, min_p 0.05	75/80	48/80
Ollama /api/chat, temperature 1.5	1.5, top_p 0.9	73/80	45/80
Ollama /v1, temperature 1.5	1.5, top_p 1.0	39/80	21/80
Ollama /api/chat, 1.5 + top_p 0.95 + min_p 0.05	same as llama-server	74/80	47/80

About half the /v1 replies failed the schema, with the same small errors as before plus stranger ones: an empty {} in the items array, "category": "items", an extra "other": [] key, and a fence labelled ```java. Qwen 3.5 0.8B got 18 of 40 valid and 5 right. Twice it opened a <think> block even though thinking was off, and once it wrote a full “Thinking Process” until it hit the 300-token limit. Qwen 3.5 2B got 21 of 40 valid.

Two things in this table matter more than the headline:

• top_p 0.9 was enough. Ollama’s native route at 1.5 has no min_p, only top_k 40 and top_p 0.9, and it stayed within a few replies of llama-server. What sank /v1 was top_p 1.0, which lets the long tail of unlikely tokens back in. top_k 40 alone did not hold the line; all three Ollama rows had it.
• Matching the samplers matches the results. The last row sends llama-server’s top_p and min_p through Ollama’s native route. It landed at 74 valid, next to llama-server’s 75. The server is not the variable. The sampler values are.

That last row also tells you how big noise is in this test. Its sampler settings are identical to the llama-server 1.5 row, and the right-answer counts still differed by up to 5 per model (Qwen 3.5 0.8B: 19 vs 14 of 40). So treat differences of a few replies as noise. The 36-reply validity drop on /v1 is not.

Does a Modelfile PARAMETER fix the /v1 defaults?

No, not for these two. This is already reported as ollama/ollama#17744 for an older version, so I checked it on 0.40.3 with a Modelfile that sets six sampler parameters:

PARAMETER temperature 0.2
PARAMETER top_k 20
PARAMETER top_p 0.8
PARAMETER min_p 0.05
PARAMETER presence_penalty 1.5
PARAMETER repeat_penalty 1.05

ollama show --parameters lists all six. Here is what the sampler actually got:

Request	temperature	top_p	top_k	min_p	presence_penalty	repeat_penalty
/api/chat, no options	0.2	0.8	20	0.05	1.5	1.05
/v1, no sampler fields	1.0	1.0	20	0.05	1.5	1.05
/v1, temperature 0.5	0.5	1.0	20	0.05	1.5	1.05
/v1, top_p 0.8	1.0	0.8	20	0.05	1.5	1.05

Only temperature and top_p get replaced. Everything else in the Modelfile survives on /v1, including presence_penalty, which is also an OpenAI field: the code only sets the penalties when the request includes them. That refines a guess in the issue thread that every OpenAI-named field gets a default. And it gives a workaround: min_p in a Modelfile does reach /v1, so PARAMETER min_p 0.05 restores truncation even when a client sends only a temperature.

This also matters for models from the Ollama library, which ship their own sampler settings. According to another open issue, gemma4:26b ships temperature 1, top_k 64 and top_p 0.95. Through /v1, its temperature stays at 1.0 by coincidence, but top_p becomes 1.0. I only tested imported GGUF files here; the follow-up on library models counts how many ship their own values (59 of 225) and measures what /v1 does to them.

Are llama-server and Ollama the same engine?

Close enough that the routes, not the engines, explain the gap. At temperature 0, Ollama’s bundled llama-server (it pins llama.cpp b11351) and my upstream build b11554 gave the same text for 37 of 40 emails and the same parsed object for 38 of 40. One of the differences was "Coffee Mug" against "coffee mug". Ollama’s native route logs temperature 0 with its usual top_k and top_p still listed, but that does not matter: with temperature 0 the most likely token always wins.

What broke along the way

• The machine was busy. At 03:00 other programs were holding about two and a half of the four logical CPUs (load average near 10), and Qwen 3.5 0.8B generated at 1.7 to 3.2 tokens/s in the first requests. At that rate three models would have taken most of the morning, so I dropped Gemma 4 E2B from the plan and ran only the two Qwen models. The load eased later, and the whole run took about 103 minutes. Nothing here depends on speed, but it does mean one model family. In the last test, Gemma 4 E2B barely changed in any sampling condition, so the size of this effect depends on the model.
• The first test request already showed it. My smoke test (one email per condition) got a clean ticket from every condition except /v1 at 1.5, which answered (00, "ORD-72938")?. One reply proves nothing, but it told me the bench was measuring something real before I spent an hour and a half on it.
• Caveats. 20 synthetic emails written by me, one schema, Q4 quantization, thinking off, CPU only. Ollama 0.40.3 was the version on this machine; the latest release is 0.40.8, and the code that sets the /v1 defaults is the same on the main branch.

How do you get the same output from both endpoints?

• Set temperature and top_p in every /v1 request. If you want what /api/chat does, send 0.8 and 0.9. For extraction, temperature 0 is still the safe choice, and it gave the same results on both servers.
• Put PARAMETER min_p 0.05 in the Modelfile if a client sends only a temperature and you cannot change it. It survives on /v1 and brings back the truncation that kept llama-server’s JSON valid at 1.5.
• Don’t trust ollama show --parameters for /v1 traffic. It shows what the native route will use. To see what a request really got, read the sampler params lines in Ollama’s server log.
• Comparing Ollama and llama.cpp? Use the same route and send the sampler values explicitly, or you are comparing defaults, not runtimes. The speed comparison found the same thing for context size and threads.

Everything is in the project folder: the bench, the probe that records the logged sampler values, the Modelfile probe, all 640 replies and every miss. With the llama.cpp build, Ollama and models from the 10-model post, ONLY="Qwen 3.5 0.8B" ./run.sh and python3 grade.py reproduce the tables.