The tuning methodology behind the last two months of Strix Halo posts is now a public repo: strix-halo-optimize, a Claude Code skill for full-stack LLM inference tuning on gfx1151 machines. Kernel boot parameters, unified-memory math, backend containers, llama-server configuration, benchmarking, quant selection.

Its credentials arrived fast, in both directions. On its first day it found the +22% prefill win now running in production here. It also produced two false findings in the same session, and its findings log then caught an inflated number in this blog's own post about that session, which is why the tuning post now carries a same-day correction from +25-30% to +22%. Both halves of that record are the subject of this post.

What it is

Two things, deliberately separated. A methodology: probe → baseline → research live sources → change one variable → benchmark → keep or revert → journal, with a blast-radius ladder (env vars and server flags are free; boot parameters, firmware, and BIOS need explicit user sign-off). And a dated facts snapshot, in which every claim is tagged with how it is known: [measured] on real hardware, [reported] by a dated source, or [assumed]. The tags exist because tuning knowledge in this ecosystem rots within months and reputable sources contradict each other. iommu=pt was the recommended boot flag until amd_iommu=off benchmarked faster. rocWMMA flash attention was the ROCm tip in 2025 and is now explicitly discouraged on current builds. This blog's own forced-governor advice lasted four months before a measurement retracted it. The methodology is the durable part; the facts ship with an expiry mindset.

It also optimizes for a target I have not seen another tuning guide commit to: several parallel coding agents with long contexts, served from one llama-server. Prefill throughput at depth first, generation under concurrency second, KV-cache budget as the scarce resource, and an explicit rule that a config 5% faster but holding half the context per slot is a regression. Single-user chat latency is not the goal, and the skill says so.

The first unsupervised run, honestly

On 2026-08-27/28 the skill ran on its target hardware against the production 35B MoE. It found the ubatch win. It also wrote up two levers as regressions on evidence that could not support the claim, because a GPU power-state change (incident response to a hard crash) had slipped between baseline and follow-up runs, and nothing noticed. The state change was later measured at 2.4-4.9% on this machine, larger than some of the deltas being judged.

Here is the part I find genuinely instructive. Every one of those failures was a missing mechanism, not missing prose:

  • The skill said to journal every run. Seven runs produced no journal.
  • The skill said a small win inside run-to-run noise is not a win. The parallel benchmark had no way to repeat a run, so the noise floor could not be measured.
  • The skill said to A/B the one ROCm env toggle. The script recorded that variable but offered no way to set it, so the test was run by hand and its provenance was lost.

The rules existed. They were written down clearly, in the exact document the agent was operating from. They still did not happen, because prose does not enforce itself. This is the same lesson this blog reached about system prompts and permissions: instructions steer, mechanisms stop. It applies to skills with full force, and the fixes were accordingly all code, not wording. Every run now fingerprints host state (kernel, firmware, boot cmdline, GPU power state) and prints a banner voiding the baseline when state changed. -r N repeats a sweep and prints per-row spread. -e VAR=VAL sets an env var and records it in the same motion, removing the reason to bypass the tool. Failed runs get a FAILED marker instead of a directory that looks like a result. The journal the skill demands is written by the script.

Testing a skill like software

The repo's findings log holds one more thing worth stealing: the fixes were regression-tested behaviorally. Two skill copies, pre-fix and post-fix, fresh subagent per run, identical prompts, evidence discoverable in files rather than stated in the prompt. On the confound scenario the result was clean: pre-fix agents shipped the confounded number 3 out of 3 times; post-fix agents caught the state change and refused, 3 out of 3. On a subtler scenario (a 4% single-run delta) the prose rewrite showed no reliable improvement, and the log says so plainly, noting that the apparent early win dissolved with two more repetitions per side: small samples manufacture effects, in skill evals exactly as in benchmarks. What did improve there was actionability: pre-fix agents advised re-running three times while the tool had no repeat flag; post-fix agents advise a flag that exists.

The findings log itself is append-only by policy: entries are never edited to match later results, because a measurement does not become wrong, it becomes irrelevant. That policy is what caught this blog's inflated number within a day, and it is the same reason the SkDD post's compounding argument works at all: a skill accumulates value only if what it accumulates is trustworthy.

If you have this hardware

The repo assumes Fedora, Toolbx containers from kyuz0/amd-strix-halo-toolboxes, and Claude Code running on the machine itself so it can probe and benchmark directly. The memory math generalizes beyond 128 GB machines. What it wants most is replications: the findings log is one machine deep, and every [measured] fact would be stronger as two. If you run the sweeps on your own box, the contribution format is in CONTRIBUTING.md.

The pitch, compressed: the facts will rot, the methodology will not, and the methodology is only real where it is enforced by the tooling. Fork the facts, keep the mechanisms.