A lab publishes the capability it gave up to keep reasoning readable

Where things stand (as of 14 Oct 2026)

Nothing qualifying has been published since the question opened on 16 Sep 2026. The debate is very heated, though. OpenAI released GPT-6 Astra on 3 Sep. The Information reported that it uses "recurrent depth", meaning looped transformer layers. The Astra system card (deploymentsafety.openai.com/gpt-6-astra/monitorability, updated 9, 22 and 29 Sep) says three things that matter here:

• chain-of-thought monitorability fell "substantially";
• OpenAI is "quite confident" that the change in how well the model controls its reasoning is not due to architecture;
• OpenAI "will not accept further degradation of monitoring beyond a limit… We plan to share more about our approach in the coming months."

According to Fortune (3 Sep), OpenAI researchers said they limited the looping "so that the model's reasoning remains legible". Jakub Pachocki said on X that depth is "within a factor of two of GPT-4" and promised architecture details later. That is exactly the kind of sacrifice this question asks about. But it has only been said informally, on X and to reporters, and with no numbers, so it does not count.

Pachocki's essay An Alien Mind (6 Sep) and OpenAI's 9 Oct statement both endorse industry-wide monitorability commitments. The Information (14 Oct) reports that OpenAI is "grappling with fallout from use of loop transformers" as it prepares its next flagship model.

I checked the main in-window documents and none contains a measured capability loss tied to keeping reasoning readable:

• Claude Opus 5.5 system card (22 Sep), Sonnet 5.5 (28 Sep) and Haiku 5.5: they track how legible the reasoning is, but report no trade-off.
• GPT-6 Sol/Luna appendix and GPT-6.1 Sol addendum (29 Sep).
• Gemini 4 Argon Safety & Security Report (Oct 2026): a long chain-of-thought transparency section and a rule against penalizing the chain of thought, but no capability given up.

Reference class

The "monitorability tax" idea goes back to OpenAI's March 2025 paper. Over about two years of reasoning models, no lab has cleanly published a measured capability loss accepted to keep reasoning readable.

• OpenAI's December 2025 "monitorability tax" is measured in compute, which this question excludes.
• The closest precedent is DeepSeek-R1, arXiv v2 (Jan 2026), appendix B.6. It ablated the language-consistency reward ("for readability") and showed a slight drop in coding scores. But it was run on a 7B distilled model and shown only as curves, so it would probably fail this question's frontier-model and measured-amount tests. DeepSeek's V4 report repeats nothing like it.
• Labs do sometimes publish costs of safety measures they adopt (for example, Anthropic's figures for over-refusal and compute overhead of its constitutional classifiers), but rarely as capability they gave up.

Paths to YES and NO

YES paths:

• OpenAI's promised write-up on its approach or architecture quantifies the capped looping against a deeper variant it tested.
• A future system card (from OpenAI, Anthropic or Google DeepMind) reports a checkpoint or configuration kept for legibility or monitorability, with numbers.
• A Chinese lab publishes a readability-reward ablation on its flagship model.
• Industry commitments or regulation push labs to disclose a measured tax.

NO paths:

• Labs avoid revealing architecture or admitting lost capability.
• OpenAI blames general capability gains rather than architecture for the monitorability decline.
• The field shifts toward reading internal activations instead of the written reasoning, or toward latent reasoning.
• Publications state commitments but give no measured, attributed loss.

I estimated rough five-year odds for each path (OpenAI architecture write-up about 8%, any lab's checkpoint or configuration decision with numbers 12–17%, Chinese labs about 4%, research on a deployed training technique about 5%, policy-driven disclosure about 3%). Combined, they give about 30%.

Hazard model

Quarterly hazards are about 3–3.7% for Q4 2026 and Q1 2027. That is the peak of public attention, OpenAI's promised write-up is due, and new flagship model releases are coming. The hazard then declines to about 2% per quarter in 2028 and about 1% by 2031. The result is about 14% cumulative by the end of 2027 and about 32% by the end of 2031.

Strongest case against this estimate: in the first month after the question opened, at peak salience, five or six frontier safety documents included nothing qualifying. That suggests the chance per document is low, and the true figure could be closer to 15%. On the other side, ten developers, five years and intense pressure could push it to 40% or more. I kept a middle estimate.

Question. By the last day of each quarter, has a covered developer stated that it gave up a measured amount of capability to keep a frontier model's reasoning in readable text, and published the amount?

Definitions.

• Frontier model: a model the developer identifies as frontier or as one of its most capable general-purpose or reasoning models at the time of the decision. Released models and internal models count; small-scale research demonstrators alone do not.
• Reasoning in readable text: intermediate reasoning generated and used by the model before its answers or actions, expressed in human-understandable language, potentially including ordinary mathematical notation or code. It need only be available to the developer or its evaluators, not to end users. Post-hoc explanations, summaries of hidden reasoning, and opaque latent vectors or encoded token sequences do not qualify. The developer need not claim that the text captures every internal computation or guarantees alignment.
• Gave up capability: the developer actually adopted or retained a model, checkpoint, architecture, training constraint, or inference configuration and explicitly states that preserving readable reasoning was a reason for accepting lower measured task performance than an identified alternative. The alternative may be an experimental variant or checkpoint, but must have been evaluated, not merely projected.
• Measured amount: a positive numerical performance loss, expressed as a difference, percentage, ratio, or numerical range, or as two published values from which the loss can be calculated. The publication must identify the capability metric, the adopted option and comparator, and the evaluation conditions. Benchmark accuracy, task success, and demonstrated task or research throughput count. Extra token use, latency, monetary cost, or compute consumption alone do not count unless translated into measured task performance or task throughput under a stated common resource budget. There is no minimum size of loss and no requirement for a statistically significant difference.

Resolves YES if a qualifying developer publication satisfies all definitions and expressly connects the published loss to an implemented choice to preserve readable reasoning. A comparison need not hold every other model characteristic constant, but the developer must attribute the reported sacrifice to that choice rather than leaving readers to infer the connection. Evidence may be spread across explicitly linked developer publications; the qualifying date is when all requirements are first publicly documented.

Exclusions (resolve NO).

• General commitments to readable reasoning, warnings that transparency may cost capability, forecasts of a future sacrifice, or quantified hypothetical trade-offs without an implemented choice.
• Experiments that measure a readability–performance trade-off but do not report adopting or retaining the readability-preserving option for a frontier model.
• Lower scores attributed only to refusal training, content restrictions, unrelated safety measures, or broader interpretability work without preserving readable intermediate reasoning.
• A numerical improvement in monitorability without a published numerical capability sacrifice; or a decline in one model's score with no developer statement that it accepted that decline for readable reasoning.
• Publications outside the Resolution window. For published performance statistics, the Observation period convention applies; repeating or revising only pre-opening measurements does not qualify.

Resolving source. Developer-authored system cards, technical reports, risk reports, research papers issued on behalf of the developer, or official posts on the covered developer's own domain, under Public confirmation (A2). The source must state the developer's actual decision; third-party reports and papers expressing only affiliated authors' personal views cannot substitute for that statement. Apply Resolution date (A3) and the Resolution window.