oMLX 0.7.2 came out on 21 October 2026 at 09:07 UTC, less than 24 hours after 0.7.1. oMLX is a language-model server for Apple Silicon Macs built on MLX, Apple’s machine-learning framework; if it is new to you, start with what oMLX is and how it differs from Ollama and LM Studio. This release speeds up DeepSeek V4.1, brings Lightning MTP to distributed inference, opens Splash to Qwen3.8-Flash-Next GGUFs and fixes a bug that re-ran the whole prefill on every Claude Code turn. Here is what changes, who it matters to, how to upgrade for each install method and what to check first. There is also a Spanish version.

Key takeaways

  • If you use Claude Code against oMLX, 0.7.2 stops moving the notes Claude Code sends after a tool result into the leading system block, so a turn no longer reprocesses the whole conversation.
  • DeepSeek V4.1 decodes 72 to 86 % faster on oQ2e, oQ2.5e and oQ3e with MTP off, according to the maintainer’s runs on a 512 GB M3 Ultra.
  • Lightning MTP now works in clusters of two or more Macs with DeepSeek V4.1 and GLM-5.3, and turns on only when the checkpoint ships a draft head.
  • You upgrade from the app itself (DMG), with brew upgrade omlx, or with git pull and make install. There is no PyPI package.
  • Before upgrading, check two behaviour changes: DeepSeek V4.1 uses 4 to 7 GB more memory at a 16K prompt, and clusters turn MTP on by default.

What oMLX 0.7.2 brings and who it affects

0.7.2 is small in code and large in effect for three specific profiles. Between 0.7.1 and 0.7.2 there are 32 commits touching 136 files, with 5181 lines added and 1187 removed, according to the comparison of both tags on GitHub[1]. The maintainer, jundot, explains the hurry in the 0.7.2 release notes[2]: "It’s only been a day since 0.7.1, but these were worth shipping now."

The changes split like this:

Profile What changes in 0.7.2
You use Claude Code with a local model Notes after a tool result no longer force a full prefill
You run DeepSeek V4.1 on oQ2e, oQ2.5e or oQ3e Fused decode kernels and prefill in 8192-token chunks
You split a model across two or more Macs Lightning MTP on pipeline or tensor splits, without the 1 tok/s stall
You try GGUF models with Splash Qwen3.8-Flash-Next as GGUF and downloads of multi-part GGUFs
You use the web UI from the keyboard or in dark theme Keyboard-reachable menus, WCAG AA contrast and a visible memory meter

If you run a Qwen or Gemma model on MLX on one Mac and do not use Claude Code, 0.7.2 mostly brings UI and API fixes. On my 128 GB M5 Max the admin dashboard already reports v0.7.2.

How much faster DeepSeek V4.1 gets on oQ2e to oQ4e

DeepSeek V4.1 gains the most, because 0.7.1 applied its fused kernels only to the MXFP weights of oQ4e. The oQ2e, oQ2.5e and oQ3e quants (the 2, 2.5 and 3-bit variants of oMLX’s oQ format) still took a slower generic path. With 0.7.2 they use the fused kernels too, Lightning MTP verification shares work across the tokens it checks, and prefill runs in 8192-token chunks (PR #4722).

The chart shows the MTP-off decode the maintainer publishes for the -mtp checkpoints of DeepSeek-V4.1-Flash-1017[3]. oQ3e goes from 22.9 to 42.7 tokens per second, 86 % more:

DeepSeek V4.1 Flash, decode with MTP off at a 16K prompt tok/s · higher is better
oQ2e
oMLX 0.7.1: 23.0
oMLX 0.7.2: 39.5
oQ2.5e
oMLX 0.7.1: 22.8
oMLX 0.7.2: 39.5
oQ3e
oMLX 0.7.1: 22.9
oMLX 0.7.2: 42.7
oQ4e
oMLX 0.7.1: 32.8
oMLX 0.7.2: 38.7
Show the data table
QuantoMLX 0.7.1oMLX 0.7.2
oQ2e23.039.5
oQ2.5e22.839.5
oQ3e22.942.7
oQ4e32.838.7

Maintainer's figures from the 0.7.2 release notes: 512 GB M3 Ultra, DeepSeek-V4.1-Flash-1017 -mtp checkpoints, 16K prompt. I have not measured them on my Mac.

With Lightning MTP and CED on, the notes give a 16K prefill of 949 to 1010 tokens per second, against 700 to 773 on 0.7.1. According to the maintainer, it holds around 900 up to a 128K prompt. The price is memory: peak usage at a 16K prompt rises by 4 to 7 GB because of the 8192-token chunks.

What changes if you use oMLX with Claude Code

For anyone coding with Claude Code against a local model, this is the fix you notice every day. Claude Code sends notes after each tool result: hook context, loaded rules and reminders. Up to 0.7.1, oMLX moved them into the system block at the start, which changed the beginning of the prompt and invalidated the prefix cache (PR #4712).

The effect was that every turn reprocessed the whole conversation. For example, with 50,000 tokens of history and a prefill of about 1000 tokens per second, that is almost 50 s of waiting before the first token of each reply. Now the notes stay where they are and the prefix cache serves what was already processed.

0.7.2 adds two more changes for this case:

  • Classifier requests from Claude Code’s auto mode get a 256-token thinking budget, so a reasoning model answers before the classifier’s deadline
  • Splash also keeps later system messages in place and receives the preserve_thinking option

Claude Code connects to oMLX through its Anthropic-compatible endpoint, /v1/messages, with ANTHROPIC_BASE_URL pointing at your server. The details are in the guide to the oMLX API key, port and endpoints.

Lightning MTP in distributed inference across Macs

Distributed inference now runs Lightning MTP, oMLX’s multi-token prediction per step, on DeepSeek V4.1 and GLM-5.3 (PR #4732). It works with pipeline splits (each Mac loads some layers) and tensor splits (each Mac loads part of every layer). It turns on by the same rule as on a single Mac: when the checkpoint ships a draft head and the model setting does not turn it off.

The chart collects the sampled decode the maintainer publishes, with MTP off and on, on two M3 Ultras joined by Thunderbolt. The big gain is on tensor splits, where GLM-5.3 doubles its speed:

Sampled decode on two M3 Ultras, Lightning MTP off and on tok/s · higher is better
DeepSeek V4.1 Flash oQ4e, pipeline
MTP off: 28.7
MTP on: 32.4
DeepSeek V4.1 Flash oQ4e, tensor
MTP off: 13.3
MTP on: 24.3
GLM-5.3 Flash oQ4e, pipeline
MTP off: 37.0
MTP on: 42.6
GLM-5.3 Flash oQ4e, tensor
MTP off: 13.7
MTP on: 27.7
Show the data table
Model and splitMTP offMTP on
DeepSeek V4.1 Flash oQ4e, pipeline28.732.4
DeepSeek V4.1 Flash oQ4e, tensor13.324.3
GLM-5.3 Flash oQ4e, pipeline37.042.6
GLM-5.3 Flash oQ4e, tensor13.727.7

Maintainer's figures from the 0.7.2 release notes: TCP ring over Thunderbolt (not RDMA), 512 generated tokens, temperature 1.0, top_p 0.95, top_k 20, measured before the PR #4722 kernels. I have not measured them.

The same release fixes a stall that held DeepSeek V4.1 at around 1 token per second across two Macs. A pipeline stage waiting for its turn let its GPU clock down and slowed the next step. With 0.7.2 that setup decodes at about 28 tokens per second with MTP off, according to the maintainer in issue #4720[4].

The cluster wizard also warns in two cases that used to fail silently. The first is a Thunderbolt Bridge with a self-assigned 169.254 address, which sent the cluster over the LAN or Wi-Fi. The second is a link running over Wi-Fi.

Qwen3.8-Flash-Next GGUF models on Splash

Splash is the external engine oMLX uses to serve GGUF models while keeping them in its model list, API and dashboard. With Splash 1.4.0, Qwen3.8-Flash-Next GGUFs run, and oMLX offers to download the incoai/Qwen3.8-Flash-Next-DFlash2[5] draft when it is missing (PR #4719).

The notes state that Splash 1.4.0 streams experts from the SSD when memory is short, and that the Q2_0 GGUF ran on a 64 GB M5 Pro. There are also two download fixes:

  • Multi-part GGUFs, at the repo root or in folders like Q2_0/, download, list and delete as one model, together with their vision projector
  • mlx-community OptiQ checkpoints that keep their vision weights in a subfolder are staged the way Splash expects and start without the 409 error

Other fixes in 0.7.2

The rest of the release is narrow fixes. These are the ones most likely to affect you:

  • SpecPrefill: a SpecPrefill request no longer shifts the RoPE positions of requests decoding beside it, and sliding-window models stop processing the last prompt token twice
  • DFlash: ParoQuant Qwen3, Qwen3-MoE and Qwen3.5 models can be DFlash targets
  • API: omlx launch accepts an IPv6 host, and the API rejects zero or negative values for max tokens, rerank top_n, embedding dimensions and TTS sampling fields
  • Attachments: files the browser sends as application/octet-stream are converted by their extension
  • Benchmarks: throughput tg rows decode the full length instead of stopping at the model’s end of turn
  • Homebrew: formula updates no longer collide when two releases ship back to back

I checked the API change on my Mac running 0.7.2. A request to /v1/chat/completions with max_tokens set to 0 or -5 returns HTTP 422 with the message "Input should be greater than 0". If one of your clients sent 0 to mean "no limit", it now fails.

How to upgrade oMLX to 0.7.2 for each install method

The method depends on how you installed oMLX, and in every case you should check the version when you finish. 0.7.2 needs macOS 15 Sequoia or later, Python 3.11 to 3.13 and an Apple Silicon Mac, according to the oMLX README[6].

macOS app (DMG)

The app has a built-in updater: open it from the menu bar and accept the update when it offers it. To download it by hand, the release page has two images: oMLX-0.7.2-macos26-27.dmg (875 MB) for macOS 26 and 27, and oMLX-0.7.2-macos15-sequoia.dmg (838 MB) for macOS 15. Drag the app into Applications and replace the old one. The macOS 26 and 27 download had 2947 downloads at 15:40 UTC, against 155 for the Sequoia one.

Homebrew

The formula in the repository has pointed at 0.7.2 since 09:07 UTC the same day. Update the index, then the package, and restart the service:

brew update
brew upgrade omlx
omlx restart
omlx --version

omlx restart delegates to brew services on a Homebrew install, and omlx --version should print 0.7.2. If you installed with --with-custom-kernel, Homebrew keeps that option on upgrade, so it rebuilds the native kernels and needs full Xcode. The rest of the lifecycle (install, uninstall, logs) is in the oMLX Homebrew guide.

From source

On an install from the repository, fetch the new tag and rebuild the kernels, because the sparse attention kernel changed in PR #4722:

cd omlx
git fetch --tags
git checkout v0.7.2
make install

make install reinstalls the server and the web UI and builds the native kernels. Without full Xcode, use make install-no-kernels; to rebuild only the kernels, make kernels.

The release page also ships Python wheels (omlx-0.7.2-cp311, cp312 and cp313, macOS 15 universal2), but the README does not document installing from them. There is no omlx package on PyPI either: its API returned 404 at 15:45 UTC.

What to check before upgrading

The 0.7.2 notes flag four behaviour changes:

  • DeepSeek V4.1 memory: prefill in 8192-token chunks raises the peak by 4 to 7 GB at a 16K prompt. With the SSD cache on, blocks are 8192 tokens too, and a change inside the last 8192 tokens recomputes from that boundary
  • Clusters: Lightning MTP turns on for deployments whose checkpoint ships a draft head. Turn it off in the model settings to keep the old behaviour
  • Benchmarks: tg rows decode the full length, so generation tok/s is not comparable with earlier runs of models that used to stop early
  • Source installs: run make install or make kernels after updating

If you are jumping from 0.7.0, also read the 0.7.1rc1 release notes[7]. oMLX moved to MLX 0.32.4 and removed about 150 OMLX_* debug variables.

The app stopped linking omlx into /opt/homebrew/bin, and models without saved sampling settings now take the values in their generation_config.json. When I moved my Mac from 0.6.4 to the 0.7 series, MTP was silently switched off on the -mtp models and I had to turn it back on by hand. Check that setting after you upgrade.

Known issues in 0.7.2

At 15:45 UTC on release day, no open issue reported a new 0.7.2 bug. These are the open ones around it:

  • Lower speed after 0.7.1 (issue #4735[8]): an M5 Max user with Qwen3.8-27B-MTPLX drops from over 30 to 9 tokens per second. The maintainer tested 0.7.1rc1, 0.7.1 and 0.7.2 on a 128 GB M5 Max with the same checkpoint and could not reproduce it
  • DeepSeek V4.1 on two M5 Ultras (issue #4720): the 1 token per second stall is the one 0.7.2 fixes, and the maintainer has asked for a re-test
  • CUDA workers in the cluster (issues #4739 to #4743): five reports about a Mac coordinating a DGX Spark, opened on 21 October but written against 0.7.1. If you use an NVIDIA node, wait before upgrading the cluster

Frequently asked questions

Is upgrading to oMLX 0.7.2 worth it if I already run 0.7.1?

Yes, if you use Claude Code, DeepSeek V4.1 or a cluster of two or more Macs: those are the three cases with measurable changes. With one Mac and Qwen or Gemma models on MLX, the gain is API and UI fixes, and you can wait for the next release.

Does 0.7.2 change my settings or my downloaded models?

The notes mention no settings or model migrations. The only change to default behaviour is Lightning MTP in clusters. If you are jumping from 0.7.0, the 0.7.1rc1 changes do affect environment variables, DFlash settings and sampling values.

Can I install oMLX 0.7.2 with pip?

There is no omlx package on PyPI. The release page ships wheels for Python 3.11, 3.12 and 3.13, but the documented methods are the app, Homebrew and make install from source.

Conclusion

oMLX 0.7.2 is not a maintenance release for anyone using Claude Code with local models: the repeated-prefill fix changes how long you wait on every turn. For DeepSeek V4.1 and clusters of two or more Macs, the maintainer’s figures show gains of 13 to 102 %, which I have not measured on my machine. Upgrade with the method you installed with, check omlx --version and watch memory if you run DeepSeek V4.1 with long prompts.

The benchmarks and tuning on an M5 Max are in the guide on how to install and tune oMLX on an M5 Max with 128 GB. The other change of the week for local models on a Mac is Ollama 0.40 running MLX by default.

Sources: [1] oMLX 0.7.2 release notes[2], [2] oMLX 0.7.1 release notes[9], [3] oMLX 0.7.1rc1 release notes[7], [4] Comparison of v0.7.1 and v0.7.2[1], [5] oMLX README, installation[6], [6] Issue #4720 on DeepSeek V4.1 in a cluster[4], [7] Issue #4735 on generation speed[8], [8] DeepSeek-V4.1-Flash-1017 on Hugging Face[3], [9] incoai/Qwen3.8-Flash-Next-DFlash2 draft[5], [10] Homebrew manual[10], [11] oMLX website[11].

Sources

  1. comparison of both tags on GitHub
  2. 0.7.2 release notes
  3. DeepSeek-V4.1-Flash-1017
  4. issue #4720
  5. incoai/Qwen3.8-Flash-Next-DFlash2
  6. oMLX README
  7. 0.7.1rc1 release notes
  8. issue #4735
  9. oMLX 0.7.1 release notes
  10. Homebrew manual
  11. oMLX website