GPT-6 Astra's looped transformers double effective depth and complicate reasoning audits

According to a post by Cole Halton on dev.to, GPT-6 Astra ships with looped transformers as its headline architectural change: instead of adding layers, the model's transformer blocks execute roughly 44 passes over the same weights. The reported result is that effective depth roughly doubles while the parameter count stays flat.

How the looping works

In Halton's description, identical blocks run repeatedly and reuse their weights each time. What changes between passes is state, not parameters: the key-value cache and the intermediate activations differ from iteration to iteration, so each pass refines a computation rather than adding fresh capacity. The tokens a user sees are, in his framing, only the visible surface of that process — one slice of a recurrent computation that is otherwise hidden.

What this does to the reasoning trace

The post's central argument is about interpretability. When reasoning happens inside those loops, the chain of thought a model writes out is composed after the computation has finished. It is real text, but it is narration: the model describing, after the fact, a route from input to output that sounds right, not a log of the passes that actually ran.

Halton does not claim the model is dishonest — narration and computation probably agree most of the time. The problem, he writes, is that you cannot tell when they diverge, and divergence is exactly where a bad review or a subtle bug would hide. Much of today's agent evaluation and code review practice leans on chain-of-thought output as evidence — whether edge cases were considered, whether repo conventions were respected before code was changed. If the explanation is written separately from the compute, then judging the explanation means judging the model's account of its thinking rather than the thinking itself.

The practical response for evaluators

For anyone benchmarking agents or reviewing AI-generated code, Halton's advice is to stop treating visible reasoning as ground truth and to instrument what can actually be checked: which tools the agent called, which files it touched, the diff it produced, and how it observably behaved. A written chain of thought from a looped model should be read as an after-the-fact report, not a recording.

He also flags a subtler measurement trap. Some evaluation setups force models to externalise their reasoning as a transparency measure, but doing so intervenes in how the model allocates its passes. A forced-transparent variant and the shipping default are therefore not the same system, so a number measured on one does not cleanly transfer to the other — a harness difference that exists before reasoning quality even enters the picture. His recommendation is to state explicitly which configuration a benchmark was run against.

Why it matters

Looped transformers are usually framed as an efficiency story: more effective depth without more parameters, which matters for both training and serving costs. This post argues the change also has an accountability dimension. Evaluation methods that lean on chain-of-thought output — agent benchmarks, review workflows, safety audits — were built around models whose visible trace reflects their computation. If a flagship release really does move the compute into recurrent passes, those methods need to shift toward behavioural and artifact-based checks, and the field needs to be explicit that a written explanation from such a model is an account rather than an instrument.

The account comes from a single dev.to post rather than documentation from the model's developer, so specific figures such as the pass count should be read as one author's description of the release.