Ollama v0.34.2 fixes MLX speculative decoding memory growth; v0.34.1 shipped broader MLX changes

Two releases in two days

Ollama published v0.34.1 on September 14 and followed up with v0.34.2 the next day. Both release notes mention MLX and memory, which has led some readers to treat the second release as an emergency patch for the first. A dev.to analysis of the two changelogs argues that reading is not supported by the official text: the entries describe different mechanisms, and neither one links the two as a single regression.

What v0.34.1 shipped

According to the changelog, v0.34.1 covered several areas:

• ollama create with MLX safetensors is no longer marked experimental. At the same time, building GGUF models now depends on llama.cpp tools for conversion and quantization.
• A broadly worded improvement to MLX memory handling on Apple silicon, with no detail on the conditions that triggered the problem or which part of the pipeline it touched.
• Repetition detection now waits for 100 repeated tokens before firing, intended to cut false positives in output such as OCR text.
• The /api/tags endpoint got faster on large model libraries, from 3.1 seconds down to 294 ms cold, based on the project's own tests attached to the changelog.
• The typical_p parameter is deprecated: it can no longer be set on new models, though existing GGUF models keep it.

What v0.34.2 adds

The follow-up release, one day later, contained:

• A narrowly scoped fix, quoted verbatim: "Fixed excessive memory growth during long generations with MLX speculative decoding."
• A first-run setup flow when running ollama, offering sign-in or a local-only path, with that state shared with the desktop app on macOS and Windows.
• An ollama://apps link that opens the Apps page of the desktop app directly on those two platforms.
• A llama.cpp update, with no version number or detail given in the changelog.

Two memory mentions, not one bug

The shared vocabulary of "MLX" and "memory" invites the regression interpretation, but as the dev.to analysis points out, the wording diverges. v0.34.1 speaks in general terms about MLX memory handling. v0.34.2 names a precise scenario: memory growth during long generations under speculative decoding, which is a specific inference technique rather than overall memory management.

Neither changelog states that v0.34.2 repairs something v0.34.1 broke, and neither confirms the two items are fully independent. The release notes simply do not clarify the relationship. Several questions therefore stay open: whether the memory growth predated v0.34.1 or arrived with it, why memory ballooned during speculative decoding in the first place, what the llama.cpp bump actually contains, and how the /api/tags timings were measured beyond the project's own reported numbers.

Who needs to update

The memory fix in v0.34.2 applies to one combination: MLX models on Apple silicon, long generations, and speculative decoding enabled. Users running GGUF models through llama.cpp are outside the fix's scope, based on what the changelog describes. For everyone else, v0.34.1's changes — stable safetensors support, the repetition threshold, the typical_p deprecation, the /api/tags speedup — come along automatically when upgrading to v0.34.2, not because v0.34.2 repeats or repairs them.

Why it matters

MLX is the backend that matters for local inference on Apple hardware, and unbounded memory growth during long generations is exactly the kind of defect that takes down long-running jobs — summarisation, agents, batch transcription — before anyone notices a leak. For that audience, v0.34.2 is a concrete, documented fix worth installing promptly.

The pairing also illustrates a release-notes hygiene problem. When consecutive releases touch the same subsystem with vague, overlapping language, users cannot tell whether they are looking at one bug patched twice or two separate issues. Anyone running Ollama in a production local-model setup should treat the two entries as distinct until the project says otherwise, and read changelog benchmark numbers with the caveat that they come from the project itself.