Editorial cover showing a grokking regime map beside attention diagnostic curves
Cover: the idea of the post. The measured phase diagram below is the released paper figure.

Abstract

This solo-author preprint studies cheap online diagnostics for grokking phase regimes in transformers. The public artifact includes a Python package, aggregate JSONs, provenance manifests, figure artifacts, Lean 4 checks, and a Hugging Face dataset.

TL;DR: Two cheap statistics computed directly from attention weights track when and whether a transformer "groks" a task, at about 3% extra compute cost. Across 1,120 runs we map a phase diagram over weight decay and model size, and show the critical weight-decay threshold is architecture-specific, not a universal constant.

If you're skimming

  • Question: can we see grokking phase behavior without expensive second-order diagnostics?
  • Diagnostics: attention-head cosine similarity and entropy spread across heads.
  • Scale: 1,120 transformer runs for the main regime map, plus 350 cross-architecture probes.
  • Limit: the critical weight-decay threshold is architecture-specific, so the number should not be copied blindly.

What "grokking" means here

Train a small transformer on a synthetic task like modular addition and something strange happens: the model first memorizes the training examples, the training loss drops to near zero, and test accuracy stays low, sometimes for thousands of steps. Then, seemingly out of nowhere, test accuracy jumps and the model generalizes. That delayed jump is called grokking.

Knowing whether and when a run will grok matters if you're studying generalization, but the standard ways to detect the underlying phase transition (Hessian-based diagnostics) are expensive to compute during training.

The two cheap diagnostics

We compute two numbers directly from the model's attention activations during training:

Both track the grokking phase regime from attention activations alone, at roughly 3% wall-clock overhead in the reported setting, complementing the more expensive Hessian-based diagnostics at much lower compute cost.

Phase diagram of weight decay versus model size showing memorization, developmental, and collapse regimes across 1,120 modular-arithmetic transformer runs
The mapped regime diagram: weight decay on one axis, model size on the other, with distinct memorization / developmental / collapse regions across 1,120 modular-arithmetic transformer runs (0.82M–85M parameters).

How to read the figure

The x-axis is weight decay and the y-axis is model scale. The point of the figure is not that one region is "good" and the others are "bad." It is a map of training behavior: too little regularization leaves you in memorization, an intermediate region supports delayed generalization, and too much regularization can push the run into collapse.

The useful part is operational. If you are launching a sweep, the figure tells you that weight decay is not a single knob with a universal setting. The same value can mean different things after model scale changes.

The regime map

Across the 1,120 runs, we map a 2-axis regime diagram (weight decay × model size). The critical weight decay for the canonical 4-layer, 8-head, 128-dimension transformer on modular addition lands at λc ≈ 0.0158, with a power-law exponent ν ≈ 0.757 describing how the transition sharpens with scale.

What I would use this for

I would use these diagnostics as cheap sweep instrumentation, not as a final theorem about grokking. They are useful when you need to decide whether to extend a run, kill a run, or sample more densely near a suspected transition. Because they come from attention activations, they can run during training without the cost of a full Hessian-style probe.

The strongest use case is early triage: if a sweep is expensive, I want a low-overhead signal that tells me which runs are worth watching longer. The diagnostic does not replace final test accuracy. It gives a reason to spend the next compute dollar on one part of the grid instead of another.

The architecture-specificity result

We then ran the same diagnostics on three other architectures at matched horizons: a 4-layer MLP, a 4-layer LSTM, and a 4-layer Mamba (selective state-space) model, 350 additional runs. Each showed a different critical weight-decay value: about 0.0511 for the MLP, 0.0365 for the LSTM, and 0.0144 for Mamba. The Mamba value overlaps the transformer's canonical range, but we don't claim that overlap reflects a shared underlying transition mechanism. The practical takeaway is that a critical weight-decay number measured on one architecture should be recalibrated, not assumed to transfer, when you move to a different architecture.

What is public

Frequently asked questions

What is "grokking" in transformers?

A network first memorizes training data, then, much later, suddenly generalizes to the test set - often long after the training loss looks flat.

What are the two new diagnostics?

Mean pairwise attention-head cosine similarity and entropy standard deviation across heads, both computed straight from attention activations at roughly 3% overhead.

Is the critical weight-decay value the same across architectures?

No. MLP, LSTM, and Mamba each showed a different critical value in our cross-architecture probes. Recalibrate per architecture rather than transferring the transformer number.

Is any of this formally verified?

The diagnostic identities are checked with Lean 4 proofs against mathlib. The empirical claims are separately traced through aggregate JSON provenance, not formally proven.

Links

BibTeX

@article{verma2026grokkingdiagnostics,
  title={Weight Decay Regimes in Grokking Transformers: Cheap Online Diagnostics},
  author={Verma, Lucky},
  journal={arXiv preprint arXiv:2605.20441},
  year={2026}
}