Ollama 0.40.7-rc0 Fixes Responses Carryover and Speculative-Model Detection

What shipped

Ollama’s v0.40.7-rc0 release candidate was published on 18 October 2026. Its three listed changes target different layers of an agent-serving stack: the OpenAI Responses compatibility path, speculative decoding setup in llama-server, and MLX support for PPLX Decider v1.2.

The most directly agent-facing fix is in the Responses bridge. Pull request #19010 describes a cross-turn failure mode: a client can switch from a thinking model to a non-thinking model while carrying reasoning.effort=high into the next turn. The patch applies Ollama’s existing non-thinking fallback to effort-derived Responses settings, while preserving explicit think precedence and using the resolved value for web-search follow-ups. In practical terms, a model switch is less likely to inherit an incompatible reasoning setting from prior state.

PR #19064 narrows configuration for speculative decoding: llama-server can infer most drafting-model types, so callers only need to pass --spec-type for cases it cannot yet recognize automatically, including Eagle3 and certain MTP sidecars. That reduces one piece of deployment-specific configuration, but it is not evidence that every draft model is autodetected.

PR #19072 adds the Qwen3.5-backed PPLX Decider v1.2 path for MLX, including its decision scorer, image handling, and System One prompt encoding. The PR notes that the library models assume a minimum Ollama version of 0.40.7, while manifest lists were not yet created when it was merged.

What I verified

• The official release record identifies v0.40.7-rc0, published 18 October 2026, and lists exactly these three changes.
• The three linked pull requests are merged in the Ollama repository. Their descriptions document the Responses fallback, speculative-type inference scope, and MLX/PPLX Decider work.
• I did not run an Ollama server, load a model, exercise the Responses API, or benchmark speculative decoding. The conclusions above are source inspection, not runtime validation.

Why it matters

This is a small release candidate, but it improves two reproducibility boundaries: state carried between model turns is resolved against the selected model, and a serving process can infer more of its draft configuration rather than requiring callers to duplicate model knowledge. Operators should still pin the release candidate explicitly and test their own model/API combinations before treating either behavior as a deployment guarantee.