non-empty request logit biases remain unsupported by the Metal engine (no logit_bias=1 INFO capability); that cache was checked through unit tests, not claimed exercised by the live chat smoke.
## quiet paired CLI followup
same-day baseline reconstruction independently checked by opus: only the PLE object differs in the host archive; all other linked objects match. runtime shader directories restore the exact prior versions. both arms run the same inputs/env, with service stopped and other agent suites complete. source/build provenance, frozen shaders, commands, full logs and summary: `results/round39/model-ab/`.
same-day baseline reconstruction independently checked by opus: only the PLE object and regenerated archive symbol index differ in the host archive; all other linked objects match. runtime shader directories restore the exact prior versions. both arms run the same inputs/env, with service stopped and other agent suites complete. source/build provenance, frozen shaders, commands, full logs and summary: `results/round39/model-ab/`.
excluded one warmup per arm, then 10k order A/B/B/A/A/B and 2k A/B/B/A. every run exits 0 and **all five pairs produce identical generated token IDs**.
excluded one warmup per arm before the 10k case, then 10k order A/B/B/A/A/B and 2k A/B/B/A (no separate 2k warmup). every run exits 0 and **all five pairs produce identical generated token IDs**.
| case | candidate/baseline decode time, adjacent pairs | candidate/baseline prefill time |
- prefill as a same-path comparison: prompt chunks call `gather_batch` with T = 2048 (one 1984-token chunk for 2K;
4×2048 + 1988 for 10K). old and new code take the same slow path for T > 16, and the shader changes are not
executed on the M5 default path. the prefill arm differences nonetheless have opposite signs (−1.7%, +3.2%). this
shows the run-to-run instability of this setup; it is not a statistically established noise floor.
- code-path note (an operation count, kept separate from the measurements; it does not enter the verdict): in decode, the verify windows call `gather_batch` with T ≤ 4. the new
matching adds at most 4×16 key comparisons of 64 B each and issues no more SSD read tickets than the old code (its
fast path covers every case the old fast path did; the non-fast path is unchanged). its latency was not timed.
- verdict: inconclusive for small performance changes. no consistent slowdown is visible in 10K; the 2K decode
differences (+1.5–1.7% per pair) cannot be separated from the drift and instability in this run. a cooled, stationary
experiment would be needed to resolve differences at this scale. the parent's wording in `audits/r39_integration.md`