Ollama in September 2026: fully MLX on Apple Silicon, Gemma 4 sees and hears, and a KV-cache fix for Claude Code

Ollama's September release on Apple Silicon is the one where the MLX transition finishes. Current Mac builds run fully on MLX, completing a move away from the Metal and llama.cpp path that started in March 2026. Alongside it: an MLX build of Qwen3.8-Flash-Next, MLX image and audio input for Gemma 4, a bump of the bundled llama.cpp to b10760, Claude Desktop as a third-party gateway provider, better caching and prefill recovery, and a fix for a Claude Code token countdown that was breaking KV-cache reuse. Most of those are features. The last one is a bill.

What shipped, in order of importance to me

The KV-cache fix first. The release note is terse, but the mechanism is familiar. Ollama's cache reuse works on prefix matching: if the first N tokens of a new request equal the first N tokens of the previous one, those N tokens are not recomputed. Claude Code, pointed at a local Ollama endpoint, emitted a token countdown that changed the prompt between calls, defeating the match, so every step paid full prefill for the whole conversation. If your agent loop on a Mac felt slower than the tok/s number suggested, this was probably why.

Multimodal Gemma 4 second. With MLX handling image and audio input, a Mac becomes a single-process multimodal endpoint: screenshot in, text out, without a separate vision model or a cloud call. For agents that work on UIs or documents, that is the piece that was missing locally.

Then the plumbing. Qwen3.8-Flash-Next on MLX gives a fast small model on the native path. The llama.cpp bump to b10760 keeps the GGUF side current for models MLX does not cover yet. Claude Desktop as a gateway provider puts Ollama in the same slot as a cloud provider in that client, so local versus cloud becomes a settings change.

Why prefix caching is the agent-loop metric

An agent loop re-sends its history every step. Step 40 carries the system prompt, the tool definitions and thirty-nine turns. With cache reuse it pays prefill for the new turn only. Without it, it pays for everything, and on Apple Silicon prefill is compute-bound, so it is the slow part.

In an agent loop the throughput that matters is not tokens per second, it is prefix tokens you did not have to compute again.

This is the same argument as prefix caching for local inference, and the Claude Code countdown is a clean example of how it fails in practice: not a cache too small, but a client inserting a few changing tokens ahead of the stable prefix. Any client can do this. Ollama fixed the known case; the general rule is to keep everything that changes per step at the end of the prompt.

What to check on your machine

• Confirm the backend. After updating, verify the model is loading on the MLX path and not falling back to llama.cpp.
• Measure prefill recovery. Run a 30-step agent task before and after, log time per step, and watch whether it grows with history. Flat means cache reuse is working. Linear growth means something is still breaking the prefix.
• Try Gemma 4 with an image and an audio clip through the same endpoint you use for text. Watch memory: multimodal input adds encoder weights on top of the language model.
• Wire Claude Desktop to Ollama as a provider and run one real task through it.
• Re-check your own clients for anything that changes the prompt prefix per call: timestamps, counters, dynamic tool lists. Each one is the same bug Claude Code had.

The wider operating notes in Ollama in practice still hold; September mostly makes the caching section true by default.

The honest gap

I am working from release notes and the Releasebot summary, not from a benchmark. My description of the countdown mechanism is an inference from a one-line note, and I do not have before-and-after numbers for the fix. I have not measured the multimodal Gemma 4 path on MLX. "Fully on MLX" is Ollama's description of the mainline Apple Silicon build; whether every model you run takes that path is something to check per model, and the llama.cpp bump is there precisely because some still do not.