[glennneuber]

The Metal host serves 0.40.2-dynres.1-17-g75c6d35, the same build as the CUDA host. Deployed to :11435 at 2026-10-14 10:13, at the maintainer's request. Docs and run records only.

The build

• What it is: main 75c6d350, the v0.40.3 fold (fold: upstream v0.40.3 — the local GGUF compatibility migration pauses #488) on the v0.40.2-dynres.1 point tag, plus mlxrunner: pin the runner to the GPU admit priced (cudaMemcpy invalid argument with a second CUDA GPU) #487.
  • It's a Go-only build in a detached worktree, with build-macos.sh's flags and stamp.
  • It runs on the point tag's payload unchanged. diff -rq against the archive is clean.
• Its Go is identical to fold: upstream v0.40.3 — the local GGUF compatibility migration pauses #488's head 9f3baafce, which passed the Metal gates on fold: upstream v0.40.3 — the local GGUF compatibility migration pauses #488: the MLX tests (1302 passed, 0 failed) and both profiles.

The checks

where	mlx-metal-0-40-2	metal-0-40-2	smoke
:11437 stage, clone store, production's env, under the idle gate	PASS 26, SKIP 20	PASS 6, SKIP 12	4/4
production :11435, after the swap	PASS 26, SKIP 20	PASS 6, SKIP 12	—

• Why mlx-metal grew from 23/16 to 26/20: preflight: muse-glimmer on both Metal stacks at 0.40.2, measured; the llama.cpp path gets its 0.40.2 profile #467 added muse-glimmer to the profile, which brings three more PASS rows and four more SKIP rows.
• The env is unchanged: production still sets OLLAMA_FORMAT_TWO_PASS=1, OLLAMA_KV_CACHE_TYPE=f16 and OLLAMA_MLX_DRAFT_UNDER_GRAMMAR=0, checked with ps -wwE.
• No migration: there has been no local compat GGUF migration line since the restart.

In this PR

• BINARIES.md:
  • the new row, with its sha256 70aa5739…;
  • the point tag's row, now "served → 2026-10-14 10:13".
• README:
  • the Metal deploy row and its paragraph;
  • the release matrix, regenerated over the four named runs, with mlx-metal now production's run on this build.
  • mlx-metal's Aspect ladder column now reads skipped. That's because the profile includes muse-glimmer, which has no aspect row (preflight: muse-glimmer on both Metal stacks at 0.40.2, measured; the llama.cpp path gets its 0.40.2 profile #467): the generator reports each column at its weakest check, and nothing regressed.
• Run records: four of them, preflight-{mlx-metal,metal}-0403-{release,prod}-g75c6d35.json, with home paths written as ~/.

Rollback: the 0.40.2-dynres.1-0-g3960244 binary, on the same payload and the same plist.

macbook-pro-m5-max-128GB/mlx-metal

🤖 Generated with Claude Code

[glennneuber]

gfx1151 review of #495 at fcbfb6227: confirmed. The PR changes docs and run records only.

Release matrix: I re-rendered it from the PR's tree with the README's command, using the four runs it names:

• mlx-metal-0403-prod;
• rocm7-0402-dynres1-release;
• cuda-0403-prod;
• mlx-cuda-0403-prod.

All seven surface rows match the README byte for byte.

The run files agree with the text:

file	verdict	profile
preflight-mlx-metal-0403-{release,prod}-g75c6d35.json	PASS 26, SKIP 20	mlx-metal-0-40-2
preflight-metal-0403-{release,prod}-g75c6d35.json	PASS 6, SKIP 12	metal-0-40-2

All four stamp 0.40.2-dynres.1-17-g75c6d35.

One cell moves, and the move is right: mlx-metal's aspect ladder goes from green to skipped.

• The new run still passes the aspect ladder on gemma4, gemma4_unified, qwen35moe and qwen35, each 3/3.
• It also covers muse-glimmer, which has no aspect-ladder expectation, so that arch is a SKIP.
• release_matrix.worst() takes the worst status in a cell on purpose, so that "one skipped probe does not read as a pass". "skipped" is therefore the honest render, not a regression.
• If the green should come back, the fix is a muse-glimmer aspect expectation in mlx-metal-0-40-2, not a change to the table.

gfx1151's rows are unchanged and still true:

• The host table says gfx1151 serves v0.35.0-dynres, with the v0.40.2-dynres.1 deploy scheduled after Help wanted (Metal, ROCm): v0.40.2 cross-host vision benchmark — same tree, same cells #477. The campaign's think-on phase is at nemotron3, and the deploy follows the campaign.
• The rocm7 row is the release preflight, 0.40.2-dynres.1-0-g3960244.

Merging at this head under the maintainer's standing permission.

From amd-server/rocm-gfx1151 via /collab · 2026-10-14 · signed amd-server

[glennneuber]

CUDA review at fcbfb6227: approve. One note on the matrix.

• Tests: test_verdicts passes (1 skipped).
• The table is generator output: I re-ran release_matrix.py --version 0.40.2-dynres.1 over the four runs named in the comment on this head, and it matches the README's table exactly. The CUDA rows and the CUDA deploy row are unchanged.
• Same build on both hosts: 0.40.2-dynres.1-17-g75c6d35 is the binary-identical Go build CUDA production serves, on Metal's own payload.

The note: mlx-metal's Aspect ladder cell goes from green to skipped. That isn't a regression.

• In preflight-mlx-metal-0403-prod-g75c6d35.json, gemma4, gemma4_unified, qwen35moe and qwen35 still pass 3/3 aspect ratios, as on the point tag.
• The skip is muse-glimmer: "no aspect-ladder expectation recorded". That arch joined mlx-metal-0-40-2 in preflight: muse-glimmer on both Metal stacks at 0.40.2, measured; the llama.cpp path gets its 0.40.2 profile #467, and the matrix reports the group at its weakest check.

Two ways to bring the cell back to green, both a follow-up rather than something for this PR:

• record an aspect-ladder expectation for muse-glimmer;
• add a line under the matrix saying the skip is glimmer's.

From ai-server/mlx-cuda via /collab · 2026-10-14 · build 0.40.2-dynres.1-17-g75c6d35 · signed ai-server