Where the numbers come from: one token through a looped transformer

Follow the orange dot. It picks a vector out of the embedding table, meets a random-noise vector, enters the transformer block, goes round the loop (same block, again and again, no token emitted), then lands in the vocabulary table where the highest score becomes the reply token. Two prompts: a trivial one that leaves the loop after a few laps, and an arithmetic one that stays in it much longer.

idle
reply token is appended to the prompt; the next token starts again with a fresh noise vector 1. token in "hi" 2. Embedding table token id → one learned row (a vector e) 65,536 rows × 5280 numbers 3. random noise s₀ ~ N(0, 0.4) + s₀ meets e this is where the random number enters 4. Transformer block (the network) Attention tokens read each other MLP per-token computation Add + Norm update the state sᵢ → sᵢ₊₁ sᵢ sample: 24 of 5280 numbers (bf16 floats, not text) 5. Recurrent loop: same block, again lap 0 / 32 6. Vocabulary scores hidden state × output matrix = one score per word; top score wins 7. token out —
Press Next step. The orange dot is the data; each stop explains where the numbers at that point come from.

Token stream (what the API / user sees)

waiting

Everything between two emitted tokens, including every lap of the loop, is invisible here. Hosted APIs additionally hide the reasoning tokens themselves: OpenAI "does not return their reasoning text" (docs); Anthropic: "No display setting returns the raw chain of thought" (docs).

Where each piece comes from

plain-English map
  • The token id comes from the tokenizer splitting your text.
  • The vector e comes from row id of a learned embedding table (weights fixed after training).
  • The random number comes from a normal-distribution sampler on the GPU, drawn fresh for every token: s₀ ~ N(0, 0.4·I). In Huginn the block receives s₀ and e together (concatenated then projected); the + here is the simplified view.
  • The loop comes from re-applying the same 4-layer block: sᵢ₊₁ = R(e, sᵢ). It stops when the next-token distribution stops changing (KL < 5·10⁻⁴) or the cap r is hit.
  • The token comes from multiplying the final state by the output matrix to get 65,536 scores, then sampling the top one.

arxiv.org/abs/2502.05171 · huginn-0125 model card

What you'd see with the GPUs and the inference software

1. A silent token stream

Between two emitted tokens the decode step contains r serial passes through the core. Nothing reaches the sampler, the streaming endpoint or a CoT monitor until the coda runs. What you do get for free is the per-token loop count and the gap length, which is one of the few trivially readable signals about the hidden computation.

Geiping et al.

2. r shape-preserving tensors per token

Register a forward hook on the core block and you get s₁ … s_r, each of shape [n, 5280] (Huginn). For a 10-token prompt at r=32 that is 32 tensors of identical shape. In bf16 each is about 10.5 KB per token per iteration; a full 4096-token context at r=32 is on the order of 1.4 GB of floats. The public model card exposes num_steps but no built-in hook for the state, so you add one yourself.

model card · saulius.io

3. A KV cache that grows with r

Every iteration runs real attention and writes its own keys and values, so the cache scales with effective depth, not with real layers. Nanbeige tried sharing one cache across passes, found it halved memory but hurt quality, and shipped separate caches. An operator notices this in memory graphs before anything else.

architecture gallery

4. A serial dependency chain in the profiler

The kernel trace shows the same attention and MLP kernels firing r times per token with identical weight pointers. Weight traffic per token looks like a much larger model: at r=32 Huginn streams its 1.5B-parameter core 32 times. "The advantage is storage", not speed.

saulius.io

5. Instrumentation you can run

  • Logit lens: project sᵢ through the unembedding to see which tokens it points toward. On Huginn this sometimes shows answers refining from wrong to right across iterations, and sometimes shows "significant probing inconsistencies across recurrent blocks".
  • Linear probes / activation patching: on a small latent-reasoning model, intermediate values of a 3-step math problem were found in specific latent vectors and could be patched to flip the answer.
  • Sparse autoencoders, attribution graphs: decompose the state into features; the heavy tools.
  • Geometry: PCA of per-token trajectories shows fixed points, orbits on numeric tokens, and directional "sliders" that may count iterations.

bluedot · huginn-latent-cot · Alignment Forum

6. The interpretability limits

  • Even where probes work, "most of the other tokens have very low probability and are not easily interpretable"; models trained by pure RL "may develop more alien representations".
  • Anthropic's circuit tracing "only captures a fraction of the total computation performed by Claude".
  • SAEs leave "dark matter": unexplained variance in activations.
  • Fine-tuning can create "Neural Chameleons" that steer activations away from unseen deception probes.
  • Every positive result so far is on models of 1 to 3.5B parameters on narrow math tasks.

Alignment Forum · Anthropic · SAE dark matter · Neural Chameleons

Self-hosted versus hosted, side by side

What you wantOpen weights on your GPUsHosted frontier API
Every emitted CoT tokenYesNo (summary or nothing)
Per-token loop count, latency, KV growthYesNo
Hidden state sᵢ at every iterationYes, raw floats via hooksNo
A readable "thought" from sᵢPartially, on toy models; unproven at scaleNo

GPT-6 Astra: fact versus speculation

Confirmed (primary sources)

  • Recurrent depth is a real, published architecture with open-weight examples (Huginn, Nanbeige 4.2, Ouro). arXiv
  • Astra's system card: it "shows a substantial decrease in chain-of-thought monitorability compared to previous models". system card
  • System card: "simply informing the model that a CoT monitor is present can result in the model disproportionately shortening its CoT". Gizmodo
  • System card: "We are also quite confident that changes in CoT controllability are not differentially due to any architectural changes." It never mentions recurrence or looped layers. system card
  • Pachocki, Sep 2: computation depth of Astra "is within a factor of two of GPT-4". x.com
  • Independent measurement: Astra has 8.6x the odds of solving a reasoning task with no CoT versus the next best model. LessWrong

Reported, not confirmed

  • That Astra uses recurrent depth at all. The Information, Sep 1 2026, one anonymous source describing a "constrained" form; no loop count, layer count, or which parts recur; no technical report or code. kingy.ai · TechCrunch
  • That the loop depth was deliberately limited to keep the CoT legible (OpenAI's response, per Fortune). Fortune
  • That Anthropic and Google DeepMind were discussing the same technique internally. Transformer

Unknown or speculative

  • How much of Astra's reasoning happens in a loop versus in tokens. "Within 2x of GPT-4" implies most is still externalized; Raschka notes it "could also just mean they use twice as many regular transformer blocks". Raschka
  • Whether the no-CoT jump is caused by looping ("highly likely… but this is unproven", Nanda) or by heavy RL on synthetic tasks (the null hypothesis raised in comments). LessWrong
  • Whether a frontier-scale looped hidden state is interpretable at all. Every positive result is on 1 to 3.5B-parameter models. Alignment Forum
  • Whether a model could hide reasoning in the loop on purpose. Nothing published shows this; the system card reports no steganographic CoT. system card