Ollama updates Apple Silicon runtime with MLX, NVFP4, and cache reuse

• Ollama says its Apple Silicon runtime now uses MLX, with a "large speedup" across Apple Silicon and specific acceleration on M5, M5 Pro, and M5 Max for both time to first token and tokens per second, according to the launch thread and the performance post.
• The update also adds NVIDIA's NVFP4 format, which Ollama says preserves model quality while cutting memory bandwidth and storage needs, giving local runs closer "production parity" with providers already serving NVFP4, as described in the NVFP4 post.
• For coding and agent workflows, Ollama reworked prompt caching to reuse cache across conversations, place "intelligent checkpoints," and keep shared prefixes alive longer, per the caching post.
• This is still a preview: the accelerated path currently targets Qwen3.5-35B-A3B coding builds, requires a Mac with more than 32GB of unified memory, and exposes launch commands for Claude Code and OpenClaw in get-started instructions.

Ollama's Apple Silicon path now runs on MLX, which the company describes in the launch thread as its fastest implementation yet on Mac. The concrete claim is not just a framework swap: in the performance post, Ollama says M5, M5 Pro, and M5 Max use new GPU Neural Accelerators to improve both prefill and decode.

The most specific benchmark details come from Ollama's own notes around Qwen3.5-35B-A3B. In the performance post, it says the comparison used an NVFP4-quantized Qwen3.5-35B-A3B model versus the previous q4_K_M path on Ollama 0.18, and that Ollama 0.19 should push that further to 1,851 tokens/sec prefill and 134 tokens/sec decode with int4. The linked blog post gives roughly similar preview numbers and frames the gain around unified memory plus MLX integration.

The other implementation change is NVFP4 support. In the NVFP4 post, Ollama says the format maintains accuracy while reducing memory bandwidth and storage requirements, which matters because the same quantization format is already used by some inference providers. That makes local testing less of a format mismatch than running a separate desktop-only quantization path.

Ollama's cache logic changed in three ways that matter for agent workloads. In the caching post, it says cache is now reused across conversations, which should increase cache hits when branching from a shared system prompt in tools like Claude Code. It also says Ollama now stores snapshots at "intelligent locations" in prompts, reducing repeated prompt processing, and uses "smarter eviction" so shared prefixes survive longer even when older branches are dropped.

That is a practical change for local coding loops because the bottleneck is often repeated prompt prefill, not just decode speed. Ollama explicitly ties the update in the launch thread to "coding agents like Claude Code, OpenCode, or Codex," and the cache changes in the caching post are the part of the release most directly aimed at those branch-heavy sessions.

The preview currently centers on one model family: Qwen3.5-35B-A3B coding builds. In get-started instructions, Ollama says users need a Mac with more than 32GB of unified memory and provides direct commands for ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4, ollama launch openclaw --model qwen3.5:35b-a3b-coding-nvfp4, and ollama run qwen3.5:35b-a3b-coding-nvfp4.

Support is broader in intent than in shipping scope. In the future-models post, Ollama says it is working on more supported architectures and an easier import path for custom models fine-tuned on supported architectures. For now, the release is best read as a preview runtime upgrade with one accelerated coding model, plus a roadmap for wider model coverage.