This post is for developers who point an OpenAI SDK client or a coding agent at a local Ollama server through its /v1 endpoints. It shows which temperature and top_p those requests ran with before Ollama 0.40.14, what they run with now, and what to check after upgrading. Nothing was run for this post: the pull request, release, source code, issues, registry files and docs were read on 2026-11-05, and GitHub times below are UTC.
Models carry their own sampler values in PARAMETER lines
The fix concerns values a model ships with, so it helps to see them first. Ollama runs open models locally or in the cloud, and models are built from a Modelfile. The Modelfile reference says the PARAMETER instruction “defines a parameter that can be set when the model is run”. When nothing sets a value, the same page gives Ollama’s defaults as temperature 0.8 and top_p 0.9.
Published models keep these values in a small JSON file in the registry. This is the one for qwen3.6, tag latest:
{"draft_num_predict":2,"min_p":0,"presence_penalty":1.5,"repeat_penalty":1,"temperature":1,"top_k":20,"top_p":0.95}For an installed model, ollama show takes a --parameters flag, defined in cmd/cmd.go with the help text “Show parameters of a model”.
Before 0.40.14, an omitted temperature, and on two endpoints top_p, became 1.0
This is the behaviour that replaced a model’s values without any error. The /v1 endpoints are Ollama’s OpenAI-compatible layer, which the compatibility docs describe as supporting a subset of the OpenAI API. Pull request #19432, the change that fixed it, says these endpoints sent 1.0 when a client omitted temperature or top_p. It adds that /v1/completions also always sent 0 for both penalties. The reporter of issue #18690 explained why that mattered: request options are applied after the model’s own options, “so the injected 1.0 always wins”.
The diff in pull request #19432 shows the three endpoints differed. For chat and completions, the fix deletes an else branch like this one:
if r.Temperature != nil {
options["temperature"] = *r.Temperature
- } else {
- options["temperature"] = 1.0| Endpoint (before 0.40.14) | Omitted temperature | Omitted top_p | Omitted penalties |
|---|---|---|---|
/v1/chat/completions | 1.0 | 1.0 | left unset |
/v1/completions | 1.0 | 1.0; an explicit 0 also became 1.0 | 0 |
/v1/responses | 1.0 | left unset | none in the docs’ field list |
On /v1/responses, the old code left top_p alone, with a TODO saying OpenAI defaults to 1.0 “but we don’t follow that here in case the model has a different default”. Its replies still reported top_p and temperature as 1.0 when the request omitted them.
Named models ran well away from their shipped values
How far a model drifted depended on what it ships. The table compares registry values with what pull request #19432 says each model got on /v1 when the client sent nothing.
| Model | Ships (temperature / top_p) | Got on /v1 |
|---|---|---|
| lfm3 | 0.1 / 1 | 1.0 temperature |
| qwen3-coder | 0.7 / 0.8 | 1.0 / 1.0 |
| deepseek-r1 | 0.6 / 0.95 | 1.0 / 1.0 |
| qwen3.6 | 1 / 0.95 | top_p 1.0 |
On /v1/completions, qwen3.6’s presence_penalty of 1.5 was also reset to 0. The pull request says qwen3.8, gemma4 and nemotron-3.5 ship top_p 0.95 and got 1.0; this post did not check their registry files.
Users measured the same gap. A commenter on issue #17744, on Ollama 0.33.3, saw top_p go “from 0.950 to 1.000” by switching endpoints. On 0.34.4, a commenter on issue #18690 measured qwen3:0.6b at 0.6 / 0.95 on /api/chat and 1.0 / 1.0 on /v1/chat/completions.
The fallback goes back at least to the v0.3.0 source
The fallback’s age shows how long clients may have run this way. The v0.3.0 source already falls back to 1.0 for temperature and top_p in both the chat and completions paths. It also multiplied a temperature the client did send by 2. That tag is the earliest one checked, not proof of when the fallback began.
Issue #17744 was opened on 2026-08-14 by a reporter on Ollama 0.32.9. It says a model whose Modelfile sets PARAMETER temperature 0 “decodes greedily on /api/chat but samples on /v1/chat/completions”. The reporter adds that coding agents often send no temperature, naming the pi coding agent; the issue says it was written by an AI agent.
Pull request #17763, opened on 2026-08-15, removed the fallback for chat temperature alone. It was never merged and was still open on 2026-11-05. Issue #18690, opened on 2026-09-28, assumed that pull request had fixed temperature. A commenter corrected this the next day: it was still open, so the fallback was still in 0.34.4.
Ollama 0.40.14 leaves omitted fields unset
This is the version to check for. Pull request #19432 was opened and merged on 2026-10-31 by dhiltgen, as commit c1db5f9e. Omitted fields are now left unset on /v1/chat/completions, /v1/completions and /v1/responses, so /v1 behaves like /api/chat. Values a client sends still win, including 0, and new tests cover omitted, null and explicit-zero values. /v1/responses replies now report null for an omitted top_p or temperature.
The current source sets each sampler option only when the request carries it:
if r.TopP != nil {
options["top_p"] = *r.TopP
}Release v0.40.14 was published on 2026-11-03 at 01:40 UTC as a full release, and was the latest release on 2026-11-05. Its notes say clients that send no temperature or top_p now get the model’s own values instead of 1.0. The comparison of v0.40.13 and v0.40.14 is 8 commits ahead, 0 behind, and lists c1db5f9e, so v0.40.13 does not have the fix.
Models with no packaged values now get 0.8 and 0.9
The upgrade changes results even for models that ship no sampler values. The Modelfile reference gives Ollama’s defaults as temperature 0.8 and top_p 0.9. The commenter on issue #18690 found that, with the fallbacks removed, a model with no parameters got 0.8 / 0.9 rather than 1.0 / 1.0. A client that pinned temperature or top_p as a workaround keeps those values after upgrading, because sent values still win. Removing them lets the model’s PARAMETER lines apply on /v1, as on /api/chat.
Limits
No figure here was measured for this post. The values for qwen3.8, gemma4 and nemotron-3.5 come from the pull request text alone. The release date of v0.3.0 was not fetched. Neither issue, nor pull request #17763, has a maintainer comment explaining why the 1.0 fallback existed, apart from the TODO in the responses code.
The compatibility docs list temperature, top_p and the penalties as supported, but say nothing about what happens when a request omits one. The fix changed no docs file. Whether Ollama Cloud’s own /v1 endpoint used the same code is not established, and whether OpenAI SDKs send temperature by default was not researched.
Replies from /v1/chat/completions and /v1/completions do not echo sampler values, so the reply cannot show which values ran. The commenter on issue #18690 read them from server logs with OLLAMA_DEBUG=1.