Ollama 0.32: MLX under the hood and an agent loop in the terminal

Ollama v0.32.0 shipped on July 11, and the release note that matters most is not a model. It is the fact that on Apple Silicon Ollama now runs on MLX instead of the llama.cpp Metal backend, and that the same binary ships an interactive agent mode. The MLX switch actually landed back in v0.19; the number Ollama quotes for the transition is decode going from roughly 58 to 112 tok/s. What is new in 0.32 is everything built on top of that: an agent loop, skills, and by the July 25 build a fix for the memory leak that made the MLX path annoying to run for more than an afternoon.

What shipped, release by release

• v0.32.0 (July 11): interactive agent mode, billed as 'Chat, Code and Work', the MLX backend on Apple Silicon, new models Laguna XS 2.1 from Poolside (33B total, 3B active MoE) and Kimi K2.7 Code, plus faster snapshots.
• v0.32.3 (July 23): a skills system, an agent TUI, and unlimited tool rounds. This is the point where Ollama stops being an inference server with a chat wrapper and becomes a runtime that can drive a task to completion.
• July 25 build: a fix for the recurring MLX model-cache leak that grew memory across requests, 8-bit quantization for selected model families, Laguna support on MLX, better Gemma 4 tool calling and multi-turn, and a faster cache snapshot.

Why MLX changes the agent math

An agent loop is decode-bound. Every tool round is a short prompt followed by a burst of generated tokens, and the user is waiting on each burst. That is exactly where MLX is strongest on M-series hardware. The independent numbers from this window: MLX generates 20-87% faster than llama.cpp below 14B parameters, and still leads by 10-20% at 14B and above thanks to unified memory. MLX-Swift wins decode by 1.4-1.8x on the Qwen and Gemma kernels. I covered the mechanics in Metal vs MLX for local models; Ollama adopting MLX as the default is that argument settled by the most popular local runtime.

The other half is that a local agent has zero per-token cost, which is the whole pitch for privacy-first, on-device tooling.

Ollama on MLX is not a faster chat box. It is the first mainstream local runtime where the agent loop, the skills, and the fast decode path all live in one process.

What I would actually do with it

• Upgrade to the July 25 build or later before you measure anything. The cache leak inflated memory across requests and will distort any long-session benchmark.
• Run your own decode benchmark with a fixed prompt, median of three runs, on the models you actually use. The 58 to 112 tok/s figure is a vendor number for one model on one machine.
• Try Laguna XS 2.1 for the agent loop. A 33B MoE with 3B active parameters is the shape that fits interactive latency on a machine with modest unified memory.
• Keep an eye on the llama.cpp side too: there is an open issue reporting a ~13% throughput regression on M3 Ultra between the March builds and current ones, suspected to be Metal kernel commits. If you benchmark both backends, pin versions.
• Use the skills system to encode your repo conventions once instead of re-prompting every session. See Ollama in practice for the deployment baseline this now sits on.

The honest limitation

The MLX advantage is a short-context advantage. Both the arXiv comparison (2511.05502) and independent benchmarks agree that past roughly 40K tokens of context the gap closes and llama.cpp holds its own. An agent that has read half your repo into context is a long-context workload, so the 'MLX is faster' headline stops applying exactly when the agent gets useful. For a long-context RAG or code-navigation loop, measure llama.cpp on the same task before you commit. The recommended split for 2026 still holds: Ollama for the daily driver, MLX for raw decode speed, llama.cpp when you need control and portability. The new agent mode does not change that split; it just makes the daily driver a lot more capable.