Ollama 0.40.6 makes runner ownership a process-lifetime boundary

Ollama 0.40.6, released October 16, adds a Windows-specific cleanup boundary that matters for local agent workloads: runner processes are assigned to a singleton Windows Job Object configured with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.

What the primary sources show

The release notes identify four changes, including “prevent orphaned runners” on Windows and support for Q2_0 GGUF tensor and file types. The merged implementation in PR #18500 adds AddRunnerToJob, guards singleton-job initialization and process assignment with a mutex, and assigns runner PIDs with AssignProcessToJobObject. The job handle is intentionally kept open for Ollama’s lifetime; when Ollama exits, Windows closes the handle and terminates assigned runners. The change covers both llama-server and MLX subprocess call sites.

The same PR adds a Windows test that starts two helper processes, assigns only one to the job, closes the job handle, and asserts that the assigned process exits while the unrelated process remains alive. That is a useful boundary test: cleanup is scoped to processes Ollama owns, rather than implemented as a broad process kill.

The release also carries PR #18967. Ollama’s GGUF reader now recognizes Q2_0 (tensor type 42 / file type 41), closing a compatibility gap between upstream llama.cpp and ollama create/model loading. The PR reports successful creation and execution of Bonsai 2 2B/4B/9B/27B on Apple silicon, including thinking, vision, and tools; that result is the contributor’s report, not an independent run here.

Why agent builders should care

For a local agent, a runner that survives the supervisor is durable state of the wrong kind: it consumes resources after the control plane is gone and can make the next run ambiguous. A Job Object makes the ownership rule executable at the operating-system boundary, while the test demonstrates that the boundary is narrow. Q2_0 support is a separate but practical reproducibility improvement: a model artifact that upstream runtime code can execute should not fail solely because the serving layer’s format registry lags behind.

Verification and limits

Directly verified: the 0.40.6 GitHub release date and notes; the merged PR descriptions; the Windows Job Object implementation and its two-process isolation test; and the GGUF enum/string additions in the repository at the cited source paths. I did not run the Windows-only test in this environment, and I did not independently reproduce the Bonsai 2 model runs. The claims about those executions are therefore attributed to PR #18967 rather than presented as observed results.