Spark-X2.6-1.7B's one-row loop fix checks out byte for byte; its 92.9% is measured on the four prompts it was fitted to

A new checkpoint on Hugging Face, graydini/Spark-X2.6-1.7B-noloop-headrow-GGUF, claims to cure Spark-X2.6-1.7B's "but wait…" reasoning loop by changing one row of the output head: 2,048 weights out of 1.7 billion, no training. Its author, the Hugging Face user graydini, reports that looping drops from 0.875 to 0.062 on a branch-point test, a 92.9% reduction, and that GSM8K accuracy goes from 0.200 to 0.433. A sibling repo does the same for the 4B model. The surgery is exactly as small as advertised; we diffed the file. The headline number is measured on the same four prompts the edit was fitted to.

The edit is real and tiny

We downloaded the edited Q4_K_M file and the official XHToken/Spark-X2.6-1.7B-GGUF Q4_K_M it was made from. Their SHA-256 hashes match the two in the repo's edit_report.json. Of 1,768,720,512 bytes, 1,973 differ, all inside a 2,176-byte span: the Q8_0-encoded row 4 of output.weight. In this tokenizer, token 4 is </think>. No other tensor changes. Dequantized, 2,046 of the row's 2,048 weights moved. The change matches the published delta4_17.f32 vector (norm 0.2226) to within the 3% error you'd expect from re-quantizing to 8 bits.

The idea is simple. Spark-X2.6-1.7B has an untied head, so the logit of </think> is just that row dotted with the final hidden state. At the point where the model has its answer and starts second-guessing, </think> sits far down the ranking. Add a vector along that hidden state to the row, and closing the thinking block becomes likely there and, the author shows, stays unlikely early in a derivation (P ≈ 6×10⁻⁹ to 0.001 at the early positions checked).

The 92.9% is in-sample

The README spells out how the delta was computed. The author captured the hidden state h_p at the conclusion point of each of four looping prompts (tool-ambig-2, tool-ambig-3, math-multi-1, math-multi-2) and solved for the minimum-norm vector that raises log P(</think>) at all four by a chosen amount:

H = stack(h_p)                      # 4 × 2048 conclusion residuals
Δ = [14, 14, 14, 18]                # nats; math-multi-2 gets a larger target
δ = Hᵀ (H Hᵀ)⁻¹ Δ                   # min-norm solution, δ · h_p = Δ_p

The validation then continues those same four prompts from the same branch points, 12 seeds each: 42 of 48 runs loop before, 3 of 48 after. The targets were tuned on that test too. A uniform +14 left math-multi-2 looping 9 of 12 times, so its target went up to +18, which cut it to 2 of 12. By construction, the edit pushes </think> up at exactly the states being scored. The result shows the fit worked, not that the loop is gone on prompts it has never seen.

The held-out evidence is the standard-benchmark table, and it is thin: 60 GSM8K problems (12 correct before, 26 after; a Fisher exact test gives p ≈ 0.01), and 91 to 100 items on each multiple-choice suite, where the changes are one or two questions. The GSM8K jump is plausible for this kind of fix. A model that never leaves its thinking block under greedy decoding never prints an answer, but the report doesn't say how many of the 14 extra solves came from runs that simply finished. The README also lists limits of its own: tool-selection looping "can still occur" on broader agent tasks, and arithmetic answers can be re-stated instead of ending.

A familiar move, on a smaller scale

This is the fourth loop fix by weight surgery we've seen this month. GPT-6 Astra's edit to Qwen3.5-0.8B trimmed a looping direction from two down_proj tensors, and held up in a rerun. Nathan Barry then matched it with a linear program, and the Tree-Ising preprint (arXiv:2611.14210) recast the same repair as an annealing problem. The Spark edit goes further down the network, to a single readout row, and is the easiest of the lot to inspect: one 8 KB vector, a Python script and ggml's quantizer rebuild the checkpoint bit for bit on a CPU. What none of them has published yet is a test on loops the fix was not fitted to. For this one, that would be a few dozen fresh looping prompts and a GSM8K run that counts unterminated outputs. Both are cheap to run.