What happened
Kindling AI’s merged pull request #2, titled “Select the trellis codebook by tensor name,” changes how EXLR8 identifies and decodes trellis-coded weights. The format previously treated the mcg hash as a constant. The change adds a second codebook, mul1, which the author says encodes measurably better at K4. Rather than relying on a metadata field, the format uses the tensor name: trellis.gate continues to mean mcg, while trellis.gate.mul1 selects mul1.
The distinction is consequential because decoding codes with the wrong codebook can produce plausible-looking but incorrect weights without an error. The pull request says that a reader that ignores a metadata field could silently corrupt the result; a tensor name, by contrast, is part of the lookup and can make an unknown codebook fail to resolve. Keeping the bare name for mcg means existing files and readers that use that codebook are unaffected.
The reference loader previously read trellis bytes by offset and did not inspect tensor names. The change makes it derive the codebook from each trellis file’s tensor names and pass that choice through decoding. The writer validates the codebook string and names tensors accordingly, including in its write path and index rebuild. A format note added with the merge says each trellis file chooses its own codebook, so different widths in one layer can use different choices.
The pull request reports exact agreement between mul1 decoder and encoder values for 1,048,576 values at each of K2, K3 and K4, with zero differences; mcg was used as a control. It also describes a change to the byte-sum operation: using __dp4a produced bit-identical output across all 65,536 states. On GB10 (sm_121), with the real MoE kernel, the author reports that the revised mul1 path ran 1–4% faster than mcg at batch sizes up to 512. The merged change was tested on real GLM-5.3-Flash files; the author reports every checksum passing and about 1% lower relative squared error against BF16 for a mul1 K4 layer than for the corresponding mcg K4 encode.
What the archive adds
New Runtime’s earlier coverage, Kindling AI’s EXLR8 v2 preview quantization of GLM-5.3 (October 22, 2026), noted that availability of a quantization does not establish quality or economical inference. This is a new implementation fact in that thread: the format now permits a second codebook, with author-reported error and speed measurements, but those results remain bounded to the stated tests.
Trend signal
This update supports agent economics moves to completed work only weakly: it reports a modest inference-kernel speed gain, but not cost per verified task or broader workload economics. The more immediate signal is that quantization quality and decode cost are being co-designed at the file-format and kernel level; this PR alone does not establish a wider pattern New Runtime tracks.
Why now
The pull request says the existing constant-codebook assumption was no longer adequate once mul1 showed better K4 encoding. The merge therefore makes the choice explicit in each trellis tensor name and documents that choices can vary across files in a layer.
Why it matters
For teams evaluating EXLR8, this separates a quantization’s representation from the decoder’s assumptions. A file can now identify the codebook needed to interpret its values, avoiding the particularly difficult failure mode of plausible but silently wrong weights. Keeping the existing mcg name also reduces disruption for current files, while per-file selection gives format users room to choose different codebooks across layer widths.
The reported gains are modest and specific: about 1% lower relative squared error against BF16 for one K4 comparison, plus a small speed improvement on the stated GB10 setup. That makes the practical lesson less “switch every model” than “validate the exact writer-reader-kernel path.” Teams should check that their loader recognizes the tensor naming convention, that checksums pass, and that quality and throughput hold on their own model and hardware before treating the new option as a production win.
Limits and uncertainty
The speed and error figures are reported by the pull-request author, not independently reproduced here. They are tied to GB10 (sm_121), the real MoE kernel and GLM-5.3-Flash files; the post does not establish performance across other GPUs, models, batch sizes or runtime stacks. The reported error measure is relative squared error on rotated weights, not KL divergence. The merge establishes implementation behavior, but broader reader compatibility and production results are not demonstrated by these measurements.
Reader takeaway
EXLR8 can now mark mcg or mul1 in each trellis tensor name, and the decoder follows that choice. The change makes codebook mismatches more detectable and reports a small K4 quality and speed edge for mul1 on GB10. Treat it as a format capability to test in your own stack, not a universal quantization recommendation.