Ollama 0.40.14: The OpenAI-Compatible Endpoints Stopped Forcing Temperature 1.0 and top_p 1.0

If you call a local model through Ollama's OpenAI-compatible endpoints and never set temperature or top_p, Ollama v0.40.14 may change your results. According to the pull request behind it, those endpoints used to fill in 1.0 for both when the client left them out, replacing the defaults packaged with the model. From v0.40.14, omitted fields are left unset, so /v1 behaves like /api/chat. Values you send still win, including 0.

I read the v0.40.14 release notes, the pull requests it lists, and the OpenAI compatibility and Modelfile docs at the tag. I did not install it or compare outputs. Everything below is what those documents say.

What the release changed

The release notes list these items:

• ollama launch claude applies the model's output token limit for Claude Code, so cloud models no longer run into the 128k default cap.
• Cloud web search responses on /api/chat are decoded correctly, including compressed responses.
• OpenAI-compatible endpoints no longer override a model's packaged sampler defaults.
• /v1/responses preserves readable input content, including prior assistant refusals, instead of flattening it.
• The Ollama app can retry ChatGPT disconnect failures.
• ollama launch codex verifies ChatGPT routing before configuring and reports a clear error when routing is unavailable.
• Faster top-k sampling on MLX for large vocabularies.

The compare view between v0.40.13 and v0.40.14 lists eight commits. One more is a CI change that pins buildx to work around a deadlock. The sampler change is the one most likely to affect a running app.

The sampler defaults change

The pull request is titled "openai: don't override model sampler defaults" and was merged on October 31, 2026. Its description says that when a client omitted temperature or top_p, the OpenAI-compatible endpoints sent 1.0 for them. It also says /v1/completions always sent 0 for both penalties.

The diff matches that. In the Go code, the chat request conversion used to set temperature and top_p to 1.0 in the else branch, and those branches are removed. On the completions request, the penalty and top_p fields became pointers, and each option is set only when the client sent it.

The pull request author gives examples of what this meant, and these are their claims, which I did not test:

• lfm3 ships temperature 0.1 but ran at 1.0 on /v1.
• qwen3-coder (0.7 and 0.8) and deepseek-r1 (0.6 and 0.95) got 1.0 for both.
• qwen3.8, qwen3.6, gemma4 and nemotron-3.5 ship top_p 0.95 and got 1.0.
• On /v1/completions, qwen3.6's presence penalty of 1.5 was reset to 0.

The fix covers /v1/chat/completions, /v1/completions and /v1/responses. It says OpenAI SDK clients that do not set sampler options now run models with the lab's recommended settings, the same as /api/chat.

What this means in practice

The practical reading is that the same client code can now produce different behavior after you upgrade. A script that never set temperature used to get 1.0 on /v1. Now it gets whatever the model package says. For some models that is lower and more focused. For a model that ships a high value, it could be the reverse.

The Modelfile docs at the tag show a different layer. The parameter table lists temperature with a default of 0.8 and top_p with a default of 0.9. Those are the fallbacks the docs describe when a model package sets nothing. I did not trace how the server combines the packaged values, the Modelfile and the fallbacks, so I cannot say which one wins in every case.

Responses input and refusals

The second pull request, "openai: preserve readable Responses input content", merged on October 29. Its description names three problems when an app resends chat history through /v1/responses:

• Readable reasoning and images in agent messages could be lost.
• A previous assistant refusal could cause the request to fail.
• An image with only a file_id could be silently skipped.

The fix preserves readable reasoning, assistant refusals and inline images. A file_id-only image that cannot be resolved is replaced with an explicit notice in the model's input, so the conversation can continue. Valid inline image data supplied next to a file_id is used, and missing or malformed image sources return errors. The same conversion is used for normal requests and compaction.

The docs at the tag say Ollama supports only the non-stateful flavor of the Responses API: no previous_response_id and no conversation. The cloud section adds that the cloud API does not support stateful Responses, built-in web search through /v1/responses, or custom or freeform tool-call replay. So an app that resends its own history is the supported pattern.

The Claude Code limit, and a number that does not match

The release notes say ollama launch claude now applies the model's output token limit so cloud models no longer run into "the 128k default cap". The pull request text says something different: that Claude kills the connection after 32k at the moment, and that the change bumps the cap to 128k output tokens. I did not find which number is the old default. The release note and the pull request description do not agree, so treat both numbers as unverified.

What I would check

These are my untested suggestions.

• Before upgrading, log the sampler options your clients actually send. If you send none, expect different outputs after the upgrade.
• If you need reproducible behavior, set temperature, top_p and seed explicitly in the client instead of relying on either default.
• If you resend history through /v1/responses, replay a conversation that contains a prior refusal on v0.40.13 and v0.40.14 and compare.
• For evals, record the Ollama version next to the model tag. A change in server defaults can look like a change in the model.

What I would not conclude

• That every model gets better or worse. The change moves the default from 1.0 to the packaged value, and that value differs per model.
• That the pull request examples apply to your model tag. I did not read the model manifests.
• That the 128k and 32k figures are settled. The two sources disagree.

Frequently asked questions

What changed in Ollama v0.40.14?

The release notes list changes to the Claude Code launch limit, cloud web search decoding, OpenAI-compatible sampler defaults, Responses input handling, ChatGPT retry and routing checks, and MLX top-k sampling.

Does Ollama still force temperature 1.0 on /v1?

Per the pull request, no. When a client omits temperature or top_p, the fields are left unset on /v1/chat/completions, /v1/completions and /v1/responses.

What happens if I set temperature to 0?

The pull request says values a client sends still win, including 0.

Which endpoints are affected?

The pull request names /v1/chat/completions, /v1/completions and /v1/responses.

Does /v1/responses support stateful conversations?

Not according to the docs at the tag. There is no previous_response_id and no conversation support.

What happens to an image that only has a file_id?

Per the pull request, an unavailable file_id-only image is replaced with an explicit notice in the model's input, so the rest of the conversation can continue.

Did you run it?

No. I read the release notes, the pull requests and the docs at the tag. I did not install Ollama or compare outputs.

Sources

All read on November 4, 2026.

• Ollama v0.40.14 release notes
• Ollama pull request 19432, don't override model sampler defaults
• Ollama pull request 19192, preserve readable Responses input content
• Ollama pull request 19410, use model output limits for Claude Code
• Ollama pull request 19470, check ChatGPT routing before configuring
• OpenAI compatibility docs at v0.40.14
• Modelfile docs at v0.40.14

Not read: the model manifests, the Go server code that merges packaged options, and the MLX, cloud search and app changes beyond their release lines.