Ollama published two releases back to back: v0.34.1 on September 14 and v0.34.2 on September 15. Both changelogs touch MLX and both mention memory. That invites reading them as an emergency fix for the same issue. The official text doesn't say that.
What changed in each version
v0.34.1 (September 14), per its official changelog:
ollama createwith MLX safetensors is no longer experimental. Creating GGUF models now requires llama.cpp tools for conversion and quantization.- General improvement to MLX memory handling on Apple Silicon ("Improved MLX memory handling on Apple Silicon").
- Token repetition detection now requires 100 repeated tokens before triggering, to reduce false positives in cases like OCR.
/api/tagsreports a measured improvement on large model libraries: from 3.1 seconds down to 294 ms cold, according to the tests included in the changelog itself.- Deprecation of
typical_p: it can't be set on new models, but existing GGUF models keep it.
v0.34.2 (September 15), one day later:
- First-run setup when running
ollama, with the option to sign in or continue locally. That state is shared with the desktop app on macOS and Windows. ollama://appslink to open the Apps page of the desktop app directly on macOS and Windows.- Specific fix: "Fixed excessive memory growth during long generations with MLX speculative decoding".
- llama.cpp update (no version detail given in the changelog).
Why these aren't the same fix
The friction point is the shared wording: "memory" and "MLX" show up in both entries. But the text of each changelog describes different mechanisms.
v0.34.1 talks about "Improved MLX memory handling" in general terms, without specifying under what condition the problem occurred or which part of the pipeline it touched.
v0.34.2 points to a precise case: memory growth during long generations when using MLX speculative decoding. That's a specific inference mechanism, not the general memory handling the previous version mentioned.
Neither changelog says one fixes what the other broke. There's no text linking the two entries as the same regression, and there's no confirmation either that they're fully independent. The documents simply don't clarify it.
Who the v0.34.2 fix matters to
The memory fix in v0.34.2 is scoped to one scenario: MLX speculative decoding on long generations. That runs on Apple Silicon with the MLX backend.
If the use case is GGUF models on llama.cpp, that fix doesn't apply according to what the changelog says: the described problem is specific to MLX speculative decoding, not the GGUF backend.
What can't be concluded from this evidence
- There's no confirmation of whether the memory growth fixed in v0.34.2 was introduced by the v0.34.1 changes or already existed before that.
- The internal mechanism isn't explained: the changelog says it was "fixed," not why memory grew during speculative decoding.
- There's no detail on which llama.cpp version was bumped in v0.34.2 or what that bump brings.
- The
/api/tagsnumbers (3.1 s → 294 ms) come from the project's own changelog, with no described test methodology.
Who needs to update today
Based on the available information: those running MLX models on Apple Silicon with long generations and using speculative decoding have a concrete, documented fix in v0.34.2. For the rest of the changes — stable safetensors, the repetition threshold, typical_p deprecation, the /api/tags improvement — those were already in v0.34.1, and updating to v0.34.2 includes them by inheritance, not because v0.34.2 repeats or fixes them.
Original source:
Looking for this approach on your team?
Explore my technical case studies or discuss a senior role, architecture and technical leadership.
Related Articles
DeepSeek Reasonix: A Technical Read on a Native Coding Agent with Aggressive Caching
DeepSeek Reasonix shows up as a native coding agent with aggressive caching and low cost. Before you adopt it or dismiss it, there's a more useful question: what specific problem does it actually solve in a real stack, and what reproducible experiment confirms that?
Sep 03 2026 · 9′ · Opinion · LLM · ia
Qwen3 locally with Ollama: what changed in the architecture and whether it's worth switching
Qwen3 landed with thinking mode and real improvements in code generation. But before you replace the model already running in your Ollama setup, there are technical questions you need to answer first. I answer them here without selling hype.
Aug 02 2026 · 9′ · Tutorials · TypeScript · Inferencia Local
My Homelab AI Dev Platform: What Problem It Actually Signals and Where the Limits Are
The homelabber community is building local AI dev platforms and the discussion is genuinely interesting. I have some observations that go beyond the initial excitement — and a checklist so you can decide whether the experiment is actually worth it.
Jun 16 2026 · 9′ · Opinion · TypeScript · LLM
Comments (0)
What do you think of this?
Drop your comment in 10 seconds.
We only use your login to show your name and avatar. No spam.
No comments yet. Be the first — your take matters most when we're few.