Ollama Preview Fixes Sampling Defaults Override, Letting Compatible APIs Honor Model Settings

Ollama released the v0.40.14-rc0 preview on November 3, including a fix that affects generation consistency: when using compatible APIs, sampling parameters not specified by the client will remain unset, allowing parameters bundled with the model to take effect. The fix was merged on October 31 and is now included in a downloadable preview release. Release notes

Maintainers said the compatible endpoints previously filled in temperature and top_p with 1.0 when those fields were omitted; /v1/completions also filled in both penalty parameters with zero. Because request options are applied last, these inserted values could override settings in the model package. For example, LFM3, which has a bundled temperature of 0.1, might actually run at 1.0 when called through a compatible endpoint. The fix covers the chat, text completions, and Responses endpoints. Explicitly supplied values, including zero, still take precedence. Fix details

This difference is directly relevant to how models are deployed. Ollama's Modelfile can store runtime parameters with PARAMETER; temperature and top_p affect generation diversity. As a result, even if engineers use the same weights and prompt, rewriting defaults when switching interfaces may change the output distribution. Ollama also provides ollama show --modelfile to inspect a model package's settings. Modelfile documentation

For existing integrations, check whether the client actually sends sampling parameters. The official compatible API examples allow requests that provide only a model and messages; after the fix, those requests may produce different generation behavior. Based on the fix's logic, if a framework already fills in sampling values, the server will still use those explicit values. Upgrading alone will not restore the model settings. Compatible API documentation

At the time of review, the release was still marked as a preview, and public information provided no quality benchmarks comparing behavior before and after the fix. Engineering teams should compare both paths—omitted parameters and explicitly specified parameters—using a fixed model version and test cases, and monitor for a stable release. What can be confirmed now is a correction to parameter precedence; it does not establish that accuracy will improve across all tasks.