Every number here was produced by bash scripts/run_all.sh and is reproduced by it. The generated tables live in results/SUMMARY.md; this page is the reading of them, including the parts that did not work.

Read METHOD.md first if you intend to quote anything. In particular: the pooled accuracy over the synthetic corpus is an average over four deliberately unlike task families, and its value depends on the mix. The per-family table is the result.

In one paragraph. Blink recognises the form of a decision; it does not read text the way a pretrained language model does. Where the answer is carried by form — which queue a ticket's wording points at, whether a claim's verb agrees with the state's — blink-tiny is near perfect and well calibrated (routing 0.998, judgment 0.999, ECE 0.028). Where the answer requires reading — binding a name to the right sentence, comparing quantities, natural language inference — it is at or a little above chance, and a frozen 4B model is far ahead (WANLI, SemIf's 256 rows: 0.44 against 0.64). The gap is pretraining, not capacity: twenty times the parameters did not close it (§5). Use Blink where form suffices, check that on your own data, and treat its confidence as the thing to branch on.

Machine. Apple M5 Pro, macOS 27.0, Apple clang, single-threaded. -std=c99 -O3 -ffp-contract=off. Exact command lines and checksums are in results/MANIFEST.json.

Weights are mapped read-only and never copied, so the container bytes are paid once per machine rather than once per process or per session. Bytes per parameter sits slightly above 1.0 because the fp32 per-row scales, the layer norms, the depthwise convolutions and the FiLM modulation are not quantized.

64 concurrent sessions over one model:

The resident growth tracks the arenas and nothing else. That is the whole claim about memory: the marginal cost of one more concurrent decision is one arena, whose size you choose by declaring limits.

Single-threaded, p50 over up to 2,000 samples or 1.5 seconds, whichever comes first, after 50 warm-up iterations. decide re-encodes everything; cached_state holds the state and the menu and changes only the question; new_menu holds the state and supplies a fresh option list.

blink-tiny

blink-small

SIMD. The NEON kernel against the same build with -DBLINK_SCALAR_ONLY=1 (make scalar):

Three things to read off these tables.

The state cache is the throughput story. The cached path costs the question and the head, neither of which depends on how long the state was, so the ratio grows with the state length. A KV prefix cache in a frozen LLM gives the same shape of win (SemIf: 2.33 → 20.03 decisions/s), but approximately; here the reuse is exact, because the state and the question are separate sequences and nothing is being approximated. tests/c/test_session.c checks it with memcmp.

Cost is linear in the state, not quadratic. There is no self-attention over bytes; the only quadratic terms run after the pool, over a sequence a quarter or an eighth as long.

Projections run four rows at a time, and batching questions fills the groups. Every int8 projection goes through blink_matmul_i8_rows, which widens each weight row to fp32 once per group of four input vectors instead of once per vector; the widening, not the multiply, is what a W8A32 product pays for. Each vector keeps its own accumulators in the original order, so the output is bit-identical to the one-vector kernel (tests/c/test_kernels.c checks it with memcmp) and every number in section 3 is unchanged. Against the previous build this took 1.3–1.5× off every path. cached_batch8 scores eight questions per blink_score_batch call, which encodes them side by side so that short questions still fill the groups; it adds about 8% on blink-small and almost nothing on blink-tiny, whose per-question cost is dominated by work a batch does not share (the FiLM product, the queries and the head). The batch is bit-identical to scoring the questions one at a time, checked in tests/c/test_session.c. The price is a fixed four-row scratch in the arena, visible in section 1 as a few KiB more at every limit.

make ACCELERATE=1 (macOS) sends the projections, the layer norms and the attention reads through Accelerate, which runs matrix products on the Apple silicon matrix unit. Same machine, one thread, 4 options (results/bench-latency-accelerate.jsonl):

blink-small gains more because its products are larger: 192 wide against 64, which is where the matrix unit pays for its overhead.

The default build's profile explains the ceiling. On a blink-tiny decide, 60% of the time was the int8 projections; with those moved, what is left is embeddings, layer norms and attention, and moving those to vDSP and BLAS brought the remaining time down again, from 238 µs to 172 µs.

The price is described in the README (Accelerate backend): Accelerate allocates inside its large products, 16 times per blink-tiny decision (measured by interposing malloc; the default build makes zero); the model holds a 352 KiB fp32 copy of the projections; the arena is 335 KiB instead of 260 KiB; results agree with the default build to fp32 rounding rather than bit for bit. On the synthetic test split, 4,000 rows, no argmax changes and the largest probability difference is 1.5e-6. The accuracy tables in §3 are from the default build, and they hold for this one to that precision.

make W8A8=1 quantizes the input of every projection to int8, one scale per row, and multiplies with integer instructions: SDOT, or I8MM on non-Apple cores that report it. This one has I8MM, but SDOT is the default on Apple silicon for the reason below; BLINK_W8A8_KERNEL=i8mm selects the other. Same machine, one thread, 4 options (results/bench-latency-w8a8.jsonl, the SDOT default):

On this core the two instructions are level, which is why SDOT is the default on Apple silicon. SMMLA does twice the products per instruction, but a plain loop issues SDOT faster (measured 140 against 193 GMAC/s at the instruction level), and both kernels reach about 170 GMAC/s on blink-small's projections, where loads rather than arithmetic set the pace. Against the Accelerate backend, W8A8 is slower on a fresh decision (221 µs against 172 µs for blink-tiny) and level or faster once the state is cached, and it keeps what Accelerate gives up: nothing allocates while scoring (checked by interposing malloc), the arena grows by 1 KiB rather than 75, and it needs no framework. The I8MM kernel reads a copy of the projections rearranged into SMMLA's layout at open time, 88 KiB for blink-tiny and 1.3 MiB for blink-small; SDOT needs none, which on a core where the two are level decides it.

Accuracy. Every published model, evaluated on its own test split with both builds by the same harness (BLINK_LIBRARY=build-w8a8/libblink.dylib):

Top-1 moves by −0.15 to +0.42 points, in both directions and inside the between-seed spread; calibration is unchanged. The decisions that change are almost all in the two synthetic families the model does not learn, comparison and selection, where it sits at chance with near-uniform probabilities (the largest shift there is 0.016) and a rounding picks a different near-tie. On blink-tiny s27, the worst case, 31% of comparison and 34% of selection rows change against 0.1% of judgment and none of routing. These models were trained with fake quantization of the weights only; quantization-aware training of the activations is not done.

The projection kernels have x86-64 SIMD paths, chosen at run time so one binary runs on any x86-64 machine: SSE2, which x86-64 guarantees, and AVX2 with FMA when the CPU reports both (BLINK_X86_SIMD=scalar|sse2|avx2 forces one). In the W8A8 build the integer products get the same two levels. SSE2 sign-extends to int16 and uses pmaddwd; AVX2 moves the weight's sign onto the input (vpsignb) and uses vpmaddubsw, which cannot saturate at these magnitudes. So both are exact and byte-identical to the scalar integer kernel, as SDOT and I8MM are.

No x86 machine was available for this work. Everything below ran on the Apple M5 Pro through Docker's linux/amd64 emulation, which is Rosetta and reports SSE2 through AVX2 and FMA, without AVX-512 or VNNI. Correctness carries over; speed does not. bash scripts/x86-docker-test.sh reruns all of it (tests, parity, timings), and on an x86 host its timings become real.

• The C suite passes at every level (scalar, SSE2, AVX2, forced in turn), for W8A32 and W8A8, with the SIMD compiled out, at -O0, and under AddressSanitizer and UndefinedBehaviorSanitizer, with GCC 14. The row-blocked product stays bit-identical to the one-vector product within each level.
• On 300 test rows of blink-tiny, SSE2 and AVX2 agree with the float64 reference to 6e-7 (the tolerance is 1e-5) and with NEON to 1e-6, with no argmax change. In the W8A8 build, SSE2 and AVX2 give identical bytes and agree with the Arm W8A8 build to 9e-8.

Timings under the emulator, p50, 4 options. They are only meaningful relative to each other within a row, and not even that for AVX2:

SSE2 is 2.0–2.9× the scalar loop. AVX2 comes out slower than SSE2 here only because Rosetta executes each 256-bit instruction as 128-bit Arm ones.

On real x86 hardware it is the other way round. The x86 SIMD levels step in CI times each level on a GitHub-hosted ubuntu-latest runner, built with GCC. That is a shared virtual machine whose CPU model the run does not record, so the absolute numbers are indicative, but the ratios within the run are meaningful. blink-tiny, 256-byte state, 4 options, p50 (first run, commit a1bdc6c):

SSE2 is 2.1–2.2× the scalar loop and AVX2 2.7×, so AVX2 is the right default where the CPU has it.

SemIf reports 20.03 decisions/s for a frozen Qwen3.5-4B with parallel suffixes on an RTX 3090, against 2.33 for fresh scoring. blink-small reaches roughly 3,200 decisions/s on one CPU core, 3,400 with blink_score_batch. This is not a like-for-like comparison — different models, different hardware, different tasks, and a four-billion- parameter model is doing something a 7.8-million-parameter model cannot. It is here to say what changes when the model is small enough to embed, not to claim a win.

Two open projects expose the same interface as Blink: jevlike, a small PyTorch model trained from scratch, and SemIf, which reads option logits out of a frozen 4B LLM. Blink is measured against both.

Speed. One decision over a 256-byte state, a question and four options, batch one. Blink and jevlike were measured on the same machine, one CPU thread each; the SemIf figures are the ones it publishes, on GPUs.

Memory.

How to read the two tables:

• On a fresh decision the default build is slower than jevlike. jevlike is Python, but its arithmetic runs in PyTorch's native kernels, which on Apple silicon use the CPU's matrix unit. Its model is also a byte embedding and one attention read, with no encoder in between. Blink spends that time on the encoder, and it shows in the accuracy below: at matched capacity it is ten points ahead on top-1 and seven times better calibrated.
• The Accelerate backend closes that gap. With the projections on the same matrix unit, blink-tiny is faster than jevlike on a fresh decision too (172 µs against 188 µs), still on one thread. The W8A8 backend gets to 221 µs without allocating and without a framework.
• Blink is faster once the state is encoded. Encoding a state once and asking it many questions is the common case in software, and the reuse is exact. Blink then answers 3.5× faster than jevlike at matched capacity, and 5.9× with the Accelerate backend.
• Memory is where the runtimes differ most. jevlike's weights are small, but a PyTorch process needs about 80 times Blink's whole footprint. SemIf needs gigabytes and a GPU, and on a fresh decision it is about a thousand times slower.
• A frozen 4B model reads language that Blink cannot. These tables compare cost, not capability.

Blink's figures come from make bench (results/bench-latency.jsonl, and results/bench-latency-accelerate.jsonl and results/bench-latency-w8a8.jsonl for the two optional backends) and from /usr/bin/time -l on blink answering one decision. jevlike's come from eval/bench_external.py (results/bench-external-w*.json), on the checkpoints trained by scripts/experiments/queue_external.sh. SemIf's are quoted from its published RTX 3090 and MLX results; the fresh latency is the inverse of its fresh rate.

Accuracy, measured head to head: same corpus, same harness, three runs each (details; measured on Blink's previous option head, the current one scores 0.6334 ± 0.0171):

On SemIf's 256-row WANLI subset, rebuilt from the identifiers it publishes, a frozen Qwen3.5-4B scores 0.637 balanced accuracy and blink-tiny scores 0.4393 ± 0.0342, with one ten-thousandth of the parameters. Blink does not compete on open-domain language, and External corpora says so with the controls next to it. On jevlike's Wikispeedia next-click task the two are level (0.306 against 0.313), and neither reads the article: the task reduces to matching titles.

Everything between the markers below is generated by scripts/report_results.py from results/eval-*.json, as are §1 and §2. It is generated because it was hand-copied for several revisions and went stale the moment the architecture changed — at one point quoting numbers from models that no longer loaded. Regenerate it with python scripts/report_results.py --write.

Every figure is mean ± standard deviation over three independent runs (see the note on determinism below: on MPS a seed does not pin a run). Reliability tables, risk–coverage curves and bootstrap intervals are in results/eval-*.json; row-level predictions are regenerated into results/predictions/ by the same script and are not committed.

3 runs, 4000 test rows over 2000 scenario groups whose entities appear in neither the training nor the validation split. Nothing clipped.

Per family, which is the part that means anything:

Temperature is fitted on validation, whose entity pool is disjoint from both training and test, and is then measured here.

Reliability, one run (bins holding at least 40 rows):

Risk–coverage, averaged over runs:

WANLI, trained on its own train split — a generalisation test, not a transfer test. Byte limits were taken from the corpus (--limits-from-data), so nothing is clipped.

The same 256 WANLI rows SemIf evaluates. Rebuilt from the row identifiers SemIf commits, in SemIf's display order, from the same pinned revision. No premise in the subset appears in Blink's training split.

Blink's controls on this subset: shuffled state 0.3659 ± 0.0266, shuffled question 0.3906 ± 0.0156. The margin over the controls is about eight points, not the eleven the headline suggests.

Transfer to the external fixtures. A model trained on the synthetic corpus, asked for something it has never seen.

blink-small on WANLI, same protocol, three runs: top-1 0.4736 ± 0.0023, below blink-tiny's 0.4913, and 0.4467 ± 0.0150 balanced on SemIf's 256 rows against tiny's 0.4393 — inside tiny's spread. It memorises: final training NLL 0.13 against validation 2.86. See §5.

Measured on the previous option head. Everything from here to §4 predates the cosine option head (container format 3). Each subsection compares arms trained under the same head, so the comparisons stand, but the absolute numbers are older than §3 above: blink-tiny was 0.6064 ± 0.0149 pooled then and is 0.6334 ± 0.0171 now, and judgment went from 0.9754 ± 0.0497 to 0.9991 ± 0.0015. The containers these rows came from are format 2 and no longer load; re-running the three comparisons on the current head is §6 item 2.

A note on what "run" means here. PyTorch on the MPS backend is not deterministic: the same seed, the same corpus and the same architecture diverge by the first epoch. Measured on a minimal case, two runs at seed 7 give 1.3074637349446614 twice on CPU and 1.307463773091634 against 1.307463755607605 on MPS. So the figures below are independent runs, not seeds, and every standard deviation in this document conflates the two sources of variation. See REPRODUCE.md.

Three arms, 60 epochs, identical otherwise:

• cross — the full model. Six runs.
• film — without the question-to-state cross layer. Three runs.
• nofilm — without the cross layer and without the query conditioning. Three runs.

The cross layer raises the mean by about ten points and cuts the spread by a factor of 3.7. That is a real improvement and it is not the stabilisation an earlier revision of this page claimed: it reported a factor of 120, from three runs that had all happened to succeed. Three further runs of the same configuration scored 0.875, 0.980 and 1.000. judgment is still occasionally learned only in part; it is no longer occasionally lost entirely.

From the three-run comparison, before the additional runs:

insufficient is solved by every run in every arm — the claim mentions something the state never touches, which is a lexical signal. The other two differ only in a verb, over the same state, so telling them apart requires comparing one word in the question against one word in the state. Without the cross layer a run can collapse the two classes entirely: nofilm run 2 scores supports 1.000 and contradicts 0.000. That total collapse is what has not recurred with the cross layer.

The effect is confined to judgment: selection and comparison are untouched, and routing is very slightly worse, which is the honest cost of adding capacity a family does not need.

jevlike is the one comparison that is fair without qualification: both models are small and both are trained from scratch on the task data. Its frozen-encoder results measure a pretrained encoder, which is a different experiment.

Same corpus, same 60 epochs, jevlike's own default learning rate, three runs each, and both sets of predictions scored by eval/evaluate.py so the arithmetic is identical. --context-tokens was set from the corpus so nothing jevlike reads is truncated — a comparison against a truncated model measures the truncation. Reproduce with eval/compare_external.py and scripts/experiments/queue_external.sh.

At matched capacity Blink is ahead by 15 points on routing and 23 on judgment, and the intervals do not overlap on judgment. The largest gap is calibration: 7× lower ECE. jevlike is confident when it is wrong, which for a model whose output is meant to drive an if statement is the difference between usable and not.

Two things this table says that are worth more than the win.

Capacity is not jevlike's bottleneck. Nine times the parameters left it slightly worse (0.5004 against 0.5116). It is the clearest evidence that Blink's margin comes from the stem, the pooling, the mixer and the question-to-state layer rather than from spending more weights on the same structure.

The two hard families are hard for both. comparison and selection sit at chance in all three systems and every run. Blink's advantage is real and it is confined entirely to the families this class of model can address.

What this does not establish. The corpus is Blink's own. It was built to separate capabilities rather than to flatter anything, but it is still home ground. The comparison in the other direction follows.

The comparison above runs on Blink's corpus. This one runs on Wikispeedia next-click, where jevlike publishes 26% with a frozen Qwen2.5-0.5B encoder and 29% from scratch. It is the direction that does not favour Blink.

eval/build_wikispeedia.py reimplements jevlike's selection exactly — same hash, same step, same menu sampling, same split by target article — and emits both formats from one selection. 41,291 training rows (jevlike reports "40,000 clicks"), 4,373 test rows over 314 target articles, up to 64 options and 43 on average. Both systems get 512 bytes of article body and nothing truncated; Blink puts the navigation goal in the question and the body in the state, jevlike gets the same bytes in its single context. Controls are applied to both in the same way (compare_external.py score-native), which jevlike's own shuffle_context does not do: it swaps titles and body together.

It is a tie. jevlike is slightly ahead, inside Blink's spread, with 21% more parameters (its position table grows with the 704-byte context) and far lower run-to-run variance. Calibration is close, unlike on the synthetic corpus where Blink's was seven times better.

Neither model reads the article.

Replacing the article body with another article's costs jevlike 0.9 points out of 31 and Blink 1.6. Both solve the task almost entirely by matching the target title in the question against the link titles. Blink extracts 1.7 times as much from the evidence and the intervals do not overlap, but on a scale of thirty points that difference is real and negligible at once.

The finding worth more than either number is about the benchmark. Wikispeedia next-click, built this way, is a title-matching task. That applies to jevlike's published 26–29% as well: with its default 192-byte context, jevlike saw the titles and almost none of the body. This replication of jevlike reaches 0.3127, slightly above the published 0.29, which is consistent with giving it 704 bytes instead of 192.

Across both corpora, then: Blink is ahead where the evidence matters and the two are level where the task reduces to titles.

The film and nofilm arms above differ only in the query conditioning, and their difference remains inside their own spread:

Undecided on every slice, and two earlier single-seed claims in FiLM's favour — that it rescued judgment, then that it rescued comparison — are retracted.

Note what this comparison is now missing. Both arms lack the cross layer, so both are bimodal on judgment, and that bimodality is most of their variance. The experiment that would settle FiLM is cross+FiLM against cross+noFiLM, now that the noise it has to beat is 0.0015 rather than 0.18. It has not been run; §6 lists it.

tests/python/test_parity.py, all three presets, on empty questions, empty states, all 256 byte values, invalid UTF-8 and inputs exactly at the limits:

The first two are fp32 accumulation against float64 accumulation and nothing else. The third is looser because PyTorch batches and pads, which changes the order of the additions; it is a check that the export is faithful, not a check of arithmetic.

Stated plainly, because a results page that only lists successes is not a results page.

• Blink does not read. This is the summary of every bullet below. It learns the form of a decision from its training data; it has no pretrained knowledge of language, and on tasks that need it — WANLI, SemIf's fixtures, selection — it is at or near chance. That is the price of 450 KB and 55 µs, and no amount of parameters trained from scratch on a few thousand rows has bought it back.
• selection is never learned, by any run, under either option head, in the mixed corpus or trained on nothing else for 100 epochs: 0.2317 ± 0.0211 against a uniform baseline of 0.240. Binding "which city does Omar live in" to the right sentence, when every candidate city also appears in the state, is beyond this architecture as it stands.
• comparison is learned once in three. Under the cosine head one run reached 0.396; the other two sat at chance, which is why its spread is 0.0798. It was at chance in every run under the previous head.
• judgment is solved on three runs, which is not the same as solved. 0.9991 ± 0.0015 with the cosine head, against 0.9754 ± 0.0497 before it. An earlier revision called judgment "stabilised" on three runs that all happened to succeed, and three further runs disproved it; the same caution applies here.
• Seeds do not pin a run on MPS. Every standard deviation in this document therefore mixes seed variation with backend non-determinism, and three runs is too few to separate them.
• routing costs a little to add capacity it does not need. 1.0000 ± 0.0000 without the cross layer, 0.9980 ± 0.0035 now — one row in 500 on average. Small, but it is a cost and not a rounding artefact.
• The FiLM ablation is undecided, and two earlier single-seed claims in its favour have been retracted. See above.
• Quantization-aware training can destroy a converged model. Switching it on at 70% of the schedule moved validation NLL from 0.87 to 1.51 in one run and from 1.01 to 1.32 in another. The cause in both was a multiplicative weight path being quantized; that path is now fp32, but the abrupt switch remains a sharp edge and the run logs should be read, not assumed.
• Padding the state with irrelevant text costs 10 points. The argmax flips on 27% of rows (0.6334 → 0.5347). The encoder's only long-range path is a masked mean, and a mean is what irrelevant text dilutes; anything that changes the sequence length also moves every pooled window boundary. Measure this on your own data before trusting the accuracy above.
• The model does not transfer. 0.375 and 0.386 on SemIf's two fixtures against a uniform 0.333, and two thirds of their rows are longer than the synthetic model's limits. A 400k-parameter byte model learns what it is trained on.
• Byte limits are a property of the trained container. A corpus with longer states needs a model trained for it, not a flag at inference time. --limits-from-data sizes them from the training corpus (WANLI: 0 rows clipped, from 100% with fixed limits).
• blink-small is experimental and is not shipped. Its containers are not in the repository (scripts/run_all.sh --small trains them). Two reasons. First, it is worse than blink-tiny on every corpus: 0.5956 ± 0.0306 synthetic and 0.4736 on WANLI, against 0.6334 and 0.4913. On the synthetic corpus tiny already saturates the families that are learnable, so capacity has nothing to buy; on WANLI small memorises (training NLL 0.13, validation 2.86). Second, it costs 4.3 ms to encode a 512-byte state against 0.4 ms. Under the previous head it also diverged in one run in three, with the fitted temperature pinned at its bound; the cosine head and 100 epochs removed that failure, and training now warns when the temperature fit hits a bound, but they did not make small better than tiny.
• Activations are fp32 by default. The W8A8 build (§2, The W8A8 backend) is about twice as fast with no measurable accuracy cost, but it is not the default: fp32 activations are what make the exact float64 parity check possible.
• One thread. Concurrency is one session per thread over a shared model. There is no intra-decision parallelism.
• The synthetic corpus is templated. Held-out entities show the mechanism generalises past memorised names. They do not show open-domain understanding.

In the order I would do them.

1. Settle FiLM against a quiet baseline. cross+FiLM against cross+noFiLM, on the current head. The existing ablation compared two arms that were both bimodal on judgment, so it had to beat a noise floor of 0.18; that floor is now 0.0015, and a real effect of a few points would be visible. Six runs, about two and a half hours.
2. Re-run the three older comparisons on the cosine head — the judgment ablation, jevlike on Blink's corpus and jevlike on Wikispeedia — so that every number on this page comes from containers that still load.
3. A benchmark that requires reading. Wikispeedia turned out to be title matching for both systems. The comparison with jevlike needs a task where the evidence carries the answer, from outside this repository, so neither side designed it.
4. Make selection learnable, or establish that it is not. Neither the cross layer nor the cosine head touched it, which is consistent with the diagnosis: selection needs binding between two positions inside the state, not between the state and the question. The next thing to try is relative position information in the mixer's attention, so that "Omar" and "Rennes" being adjacent is representable. If that fails, the honest outcome is a documented boundary of the architecture.
5. Pretraining, if Blink is to read. The WANLI gap to SemIf is not capacity (§5). A byte-level encoder pretrained on unlabelled text, then distilled into the tiny shape, is the only route this page's evidence points at. It is a different project in cost.
6. Soften the quantization-aware switch. Ramping the fake-quantization noise in over several epochs, rather than flipping it on at one, would have avoided both blow-ups seen above.
7. W8A8. Done as an optional build (§2, The W8A8 backend): 1.8× on blink-tiny and 3.0× on blink-small, accuracy unchanged. What is left is quantization-aware training for the activations, which could let it become the default.
8. An x86-64 SIMD path. Done (§2, x86-64): SSE2 always, AVX2 + FMA when the CPU has it, for both W8A32 and W8A8. AVX2 is 2.7× the scalar loop on a GitHub x86 runner. What is left is a benchmark on a dedicated x86 machine, and AVX-512 and VNNI, which are not implemented.
9. A Jev comparison, if TypeSafe publishes enough to make one honest. At present nothing here is measured against a Jev endpoint, and this page says so wherever the subject comes up.

Completed from earlier revisions of this list: the three-way disjoint entity split (closed the ECE gap: 0.131 → 0.026) and corpus-derived byte limits (--limits-from-data; WANLI went from 100% of rows clipped to 0%, with no change in accuracy — the limit was not the bottleneck).

Also completed: question-to-state cross attention, which removed the judgment bimodality that had been the dominant source of variance in every number on this page.

Also completed: every headline number over three runs; the cosine option head (container format 3), which bounds every logit by construction and ended the blink-small divergence; blink-small at 100 epochs; Wikispeedia against jevlike.