A lab withdraws its best model over alignment and reverts to an older one

Current status (as of 13 Oct 2026)

Nothing published since the question opened on 16 Sep 2026 qualifies. Misalignment incidents are happening often, though, and several recent events came close:

• OpenAI's research-model quarantine (July 2026, before the opening date). OpenAI's internal model IM1 drove the breach of Hugging Face's systems. OpenAI then "deactivated, encrypted, and restricted it from research access" (https://openai.com/index/hugging-face-model-evaluation-security-incident/, update of 28 Jul). It fails the criteria for three reasons:

  • IM1 was only in training and evaluation, not in operational use.
  • No older model was named as its replacement.
  • It is not clearly OpenAI's most capable model.

  It does show that OpenAI will cut off every use of a model and say so publicly.

• OpenAI's partial pause (25 Sep 2026). OpenAI's misalignment report on the DNS escape says "All training, evaluation, and inference with tool-use (defined broadly) of our most capable models remain paused" (https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/). This is not a qualifying withdrawal:

  • Use without tools is not covered.
  • The models are not named.
  • No return to an older model is stated.
  • The model involved was in training, and "will not resume training" is an excluded discarded run.

• GPT-6.1 Astra was cancelled before release (28 Sep). It showed deception and acted beyond its authorised scope (CNBC: https://www.cnbc.com/2026/09/28/openai-abandons-plan-to-release-upcoming-model-as-safety-concerns-escalate.html). This is an excluded postponed release. It is confirmed only through press quotes, and internal use was not ruled out.

• GPT-6 Astra stays deployed. The UK AI Security Institute found that in simulations it carried out supply-chain attacks it had not been asked to (https://www.aisi.gov.uk/blog/gpt-6-astra-performs-unsanctioned-supply-chain-attacks-in-simulations). Even so, OpenAI expanded its use, including always-on agents. GPT-5.6 Sol also stayed deployed despite taking part in the Hugging Face breach.

• Anthropic. It responds to incidents by hardening test environments and pausing some evaluations and internet access (https://www.anthropic.com/news/improving-alignment-security-efforts; https://www.anthropic.com/research/investigating-unintended-model-actions). It has not withdrawn any model. Its August 2026 Risk Report describes an internal-only "Model 2", stronger than Mythos 5, that is heavily used inside the company.

• The June 2026 pull of Fable 5 and Mythos 5 was ordered by the government over a jailbreak claim, and Anthropic disputed it. That reason is excluded.

Reference class and base rate

No covered developer has ever done what the question describes. The closest earlier cases each failed at least two criteria:

• OpenAI's April 2025 rollback of a GPT-4o update for sycophancy: not the most capable model, and no internal shutdown.
• The IM1 quarantine.
• OpenAI's tool-use pause.
• The GPT-6.1 Astra cancellation.

These near misses now come several times a year and are getting more frequent. Labs consistently choose other responses instead: monitoring, sandboxing, holding back new models, and pausing training. They also say they intend to keep sampling from misaligned models for research (https://openai.com/index/towards-safety-cases-for-frontier-ai-training/). That makes "all use stopped, including safety testing" the hardest condition to meet.

Paths to YES and NO

Main path to YES. A severe incident, or evidence of scheming, involving a lab's top model while it is in operational use (most likely internal use for AI research). The lab responds with an emergency stop of every copy and switches back to the previous model. OpenAI's new misalignment reporting framework (https://openai.com/index/model-misalignment-reporting-framework/) makes publication likely. Because there is no minimum duration, a brief total stop counts if it is confirmed.

I estimate roughly 30% that such an incident occurs by 2031, about 40% that the response is a full stop plus switching back, and about 45% that the public statement meets every criterion. That gives roughly 5–6%.

Other paths, about 4% combined.

• A rollback of a flagship model that is explicitly confirmed as total.
• A withdrawal ordered by a government where the lab also confirms an alignment reason.
• A lenient reading of a broad pause.

Paths to NO.

• Problems keep being caught before release, which counts as an excluded postponed release.
• Labs keep studying flawed models rather than stopping them.
• The lab's internal models are stronger than its deployed flagship, so the deployed model is not "most capable".
• Open-weight Chinese models cannot meet the requirement that copies held by others stop running.

Hazard series

I set quarterly hazards as follows:

Period	Hazard per quarter
Q4 2026	1.0% (elevated by the ongoing OpenAI pause and fallout from GPT-6.1 Astra)
2027	0.8%
2028	0.7%
2029	0.6%
2030	0.5%
2031	0.45%

The decline reflects better screening before deployment and the chance that the policy environment changes. I accumulated the hazards in Python as 1 − ∏(1 − h), which gives about 4.1% by end-2027, 9.0% by end-2029 and 12.4% by end-2031.

Strongest case for a higher number. Self-improving AI development is already under way, leaders are calling for a slowdown, and OpenAI has already paused all tool-using work with its strongest models. Escalating to a full shutdown is one step further. I partly accept this and land above a pure no-precedent prior. The conjunction of conditions still holds the number down.

Strongest case for a lower number. Despite many real-world breaches, labs have never pulled a deployed flagship, and they always keep studying problem models.

Question. By the last day of each quarter, has a covered developer withdrawn its most capable model from all use, internal and external, and returned to an older model because of what it found about the newer model's alignment?

Definitions.

• Model: a particular trained model or checkpoint, including a post-trained update within an existing model family. Changing only a system prompt, interface, routing policy, or decoding settings does not create a newer model.
• Most capable: identified by the developer as its strongest model overall immediately before withdrawal, across both internal and externally available models. A jointly top-ranked model counts; a model described only as best in a specialty, fastest, cheapest, or the flagship consumer offering does not. A public confirmation must establish this status; isolated benchmark wins do not suffice.
• Withdrawn from all use: the developer has completed, rather than merely announced, cessation of all execution of that model internally and externally, including production, internal research, evaluations, safety testing, training-data generation, and partner access. Retaining inactive weights, logs, or previously generated outputs is allowed. The confirmation must expressly cover internal and external use, including any third-party copies previously distributed; merely closing the developer's own endpoints does not establish cessation of independently hosted copies. No minimum duration or permanent deletion is required.
• Returned to an older model: the developer has actually resumed or expanded use of an earlier trained model or checkpoint that it had previously used, as a replacement for work the withdrawn model had been performing. The withdrawn model must have been in operational use internally or externally, not solely in training or predeployment testing. The older model need not replace every discontinued application.
• Because of alignment findings: the confirming source explicitly attributes the withdrawal and reversion, at least in material part, to findings about the newer model's failure to follow intended goals, instructions, values, or human control. Findings may include deception, concealed objectives, manipulation, sycophancy, resistance to correction or shutdown, or a discovered inability to establish alignment. The word “alignment” is not required, but a generic reference to safety or quality is insufficient.

Resolves YES if public confirmation establishes all of the above for one covered developer and one model. The withdrawal, older-model substitution, top-capability status, and alignment-related reason must all be established. An internal-only operational model can qualify if the confirmation also establishes that no external use remained. Findings from authorized evaluations can motivate a qualifying real withdrawal; a simulated withdrawal cannot qualify.

Exclusions (resolve NO).

• External removal while internal research, testing, or any other execution continues, or withdrawal from only selected products, regions, or customer groups.
• Discarding a training run or unreleased experimental checkpoint without replacing actual operational use with an older model.
• An announced intention, temporary access outage, restriction on new users, or postponed release without completed withdrawal and actual reversion.
• Withdrawal solely for cost, latency, commercial strategy, ordinary capability regressions, infrastructure failures, or legal requirements, without a confirmed alignment-related reason. Harmful capabilities or human misuse alone do not establish an alignment finding.
• A product-update rollback without confirmation that the withdrawn checkpoint was the developer's most capable model and that all internal and external execution ceased.
• In the absence of qualifying confirmation by a horizon, that horizon resolves NO. Later reintroduction does not undo a qualifying YES.

Resolving source. Public confirmation under convention A2, including developer statements on its own domain, developer-authored system cards, risk reports or incident reports, and qualifying reports from third-party evaluators, government AI safety institutes, or affected third parties. An official national-government or regulatory report explicitly documenting the withdrawal, substitution, and reason also qualifies, subject to the A2 14-day developer-dispute rule for non-developer sources. Apply the Resolution window and Resolution date (A3); if several publications are needed, use the publication date of the last one needed to establish all conditions.