On August 18, OpenAI said it had temporarily slowed scaling after the OpenAI-Hugging Face incident and preliminary evidence that its upcoming Astra model might meet its Critical cybersecurity capability threshold. It paused reinforcement-learning training on its latest deployment-bound models for two weeks, while the largest planned frontier RL run remained on hold as smaller-scale work and evaluations continued.
A few weeks later, Dario Amodei used the same word, pacing, for something much broader: an architecture built around embedded external evaluation and coordination. Demis Hassabis had already proposed a frontier-AI standards body and assessment regime. Jakub Pachocki then argued that voluntary slowdowns should become common until shared safety bars exist.
All four point toward restraint.
They do not put the brake in the same place.
That is the distinction I find useful, because "should frontier AI move more slowly?" compresses several operational questions into one moral-sounding speed preference. The more inspectable version is:
- What is actually constrained?
- What evidence activates the constraint?
- Who evaluates or verifies that condition?
- What evidence is enough to continue?
Once those are separated, the current convergence looks less like one shared slowdown policy and more like several decision rules aimed at the same broad problem:
Capability can move faster than the work needed to understand, monitor, secure, and govern it.
The word arrived after the mechanisms
September 2026 is a visible convergence point for the language. It is not where pacing began.
The public Pacing the Frontier statement was circulating in July. Its request was not a universal freeze. It asked the U.S. government to support an international effort to build the technical and governance tools needed to deliberately pace frontier-wide progress, and it treated competitive pressure as a reason individual companies may be unwilling to slow unilaterally.
Hassabis's standards-body proposal also predates the September cluster. OpenAI's operational slowdown arrived in August.
By September, the important change was that several different mechanisms were being discussed through a common frame. That makes the word more useful politically and rhetorically, but less useful analytically unless the mechanism underneath it stays visible.
I wrote about a related evidence-calibration problem in The Warning Is Real. The Countdown Is Not Established.. That piece asks what recent frontier-AI incidents establish about risk and timing. This is a different question: once someone says "pace the frontier," what control are they actually proposing?
Four things currently being called pacing
OpenAI: hold a particular workload
OpenAI gives the clearest implementation evidence in this source set.
Its August account describes a bounded operational hold: pause specific reinforcement-learning work, continue smaller-scale training and evaluation, harden research environments, expand monitoring, and proceed selectively as safeguards and evidence improve. Its Frontier Governance Framework places those decisions inside a broader risk-assessment process that can draw on internal research, model evaluations, outside experts, government input, and third-party evaluation where appropriate.
The important part is the release condition. OpenAI did not publish one fixed numerical "restart threshold." Its public account is evidence-based and risk-based: proceed when the relevant safeguards are sufficient and the residual risk judgment is acceptable, with safety margins applied.
Its September policy statement makes the same posture more explicit. OpenAI says confidence in safety should increasingly set the pace of progress and that development or deployment should slow or stop when a system cannot be sufficiently safeguarded.
So the controlled object can be quite specific: a training run, workload, model-development path, or deployment decision.
That is a real brake, but not a universal one.
Amodei: condition capability progression
Amodei's proposal moves the control surface outward.
He explicitly says pacing does not mean halting training or technical progress. The central problem, as he frames it, is that risk-prevention work needs time to keep up with capability gains.
His first step is embedded third-party evaluation. Frontier companies would give external evaluators ongoing, employee-like access so they can inspect not only finished models but training pipelines and processes, verify safety commitments, and report incidents. Anthropic commits to that step in the essay.
The next steps are coordination among frontier companies in democratic countries around shared safety standards and limits on unchecked progress, followed by international coordination where verification becomes even harder.
That is broader than OpenAI's August hold. The object being constrained is not simply one workload. It is frontier capability progression when safety, alignment, interpretability, security, and operational rigor are falling behind.
The qualification matters. Amodei proposes and commits to an embedded-evaluator architecture, but the source does not establish that Anthropic already has a fully independent regulator-like team inside the company with final stop-or-continue authority.
METR's May Frontier Risk Report shows why access and authority should stay separate. Its pilot with Anthropic, Google, Meta, and OpenAI involved unusually direct access to capable internal models and non-public information, with more editorial independence than many prior external-evaluation arrangements. That is meaningful. It still does not turn an evaluator into the final decision-maker for a lab.
Hassabis: gate deployment
Hassabis puts the strongest lever somewhere else again.
His proposal centers on a standards body that would define what counts as a frontier-class model using dynamic benchmarks, develop assessment protocols, and coordinate technical testing. Frontier labs would initially provide models for voluntary review before release. If the process proved robust, he proposes formalizing it so frontier models would have to pass the assessment to be deployed in the U.S. market.
The same framework leaves room for stronger escalation, including a coordinated slowdown among frontier labs if conditions warrant it.
Here, the primary control surface is release and market access. A model crosses a frontier classification, enters an assessment regime, and can be withheld from deployment if it does not pass.
That is operationally distinct from pausing a training workload or conditioning capability progression on a broader safety architecture.
It is also a proposal. I would not read it as adopted Google DeepMind policy or an operating U.S. regulatory regime.
Pachocki: restraint without the same machinery
Pachocki's September essay is useful for a different reason.
He argues that no lab has solved alignment and monitoring well enough to continue responsibly scaling at maximum speed for much longer, and says he expects and hopes voluntary slowdowns will become common until shared safety bars are established. He also calls international coordination a priority.
That is strong evidence of convergence around restraint.
It is not an equally specified fourth control system.
The object is broad: continued maximum-speed scaling. The trigger is also broad: alignment and monitoring are not yet sufficient. The release principle is visible in the idea of shared safety bars. But the essay does not attach the same kind of verifier architecture, institutional mechanism, or detailed restart process to that principle.
Adding precision that the source does not contain would make the comparison cleaner and less true.
Where the brake is connected
The approaches overlap on the broad problem. They differ on the control surface and on how much of the mechanism is actually specified.
| Approach | Main controlled object | What activates restraint | Who evaluates or verifies | What permits continuation | Current status in this source set |
|---|---|---|---|---|---|
| OpenAI | Particular training, research, inference, or deployment activity | Incident, capability, safeguard, and residual-risk evidence | Primarily internal governance informed by evaluations and external input | Stronger evidence that safeguards and residual risk are acceptable | Implemented targeted holds plus an internal governance framework |
| Amodei / Anthropic | Rate of frontier capability progression | Capability growth outpacing safety and risk-reduction work | Proposed embedded external evaluators plus company/government/international coordination | Evidence that safety work has caught up enough under the relevant commitments and checks | Proposal plus an Anthropic commitment to the embedded-evaluator step |
| Hassabis | Frontier-model release and market access, with broader slowdown as escalation | Frontier classification plus assessment concerns or failure | Proposed standards body, technical experts, and third-party auditors | Passing the adaptive assessment regime once formalized | Authored institutional proposal |
| Pachocki | Continued maximum-speed scaling | Alignment and monitoring remain insufficient | Not specified at the same level | Shared safety bars exist | Restraint principle, not a comparably complete control architecture |
The table is deliberately uneven. The sources are uneven.
Calling all of this "slow down AI" hides the differences. Calling them four incompatible philosophies overstates them.
The useful question is more mechanical: where is the brake connected?
Triggers are easier to name than restart rules
Across these sources, the reasons to apply restraint are easier to name than the conditions for lifting it.
A capability threshold is crossed. An incident exposes a weakness. A model shows behavior that current monitoring cannot adequately cover. A benchmark places a system in a frontier class. Evidence suggests safety work is falling behind capability growth.
Continuation exists too, but it is less standardized.
OpenAI's account ties progress to better evidence about model behavior, safeguards, alignment, and residual risk. Amodei's proposal makes pacing useful only if the gained time improves the work around alignment, interpretability, security, safeguards, and verification. Hassabis would make deployment conditional on passing an evolving assessment regime once formalized. Pachocki points to shared safety bars without specifying the same verifier or institutional owner.
What I cannot find in this source set is one common cross-lab rule of the form: when metric X reaches value Y, everyone restarts.
That does not mean there is no release logic. It means the release logic is different, differently specified, and still full of judgment.
This matters because a pause without a continuation rule can drift into symbolism, while a continuation rule that is too easy to satisfy can make the pause cosmetic.
The hard part is deciding what evidence earns the right to take a foot off the brake.
A coherent rule can still be difficult to run
Defining the control is only half the problem.
Amodei's coordination step acknowledges that some forms of inter-company pacing may need government support. On September 15, Reuters reported that FTC chair Andrew Ferguson was skeptical of requests for antitrust exemptions tied to AI-company coordination, while other participants argued that existing law may already permit some safety information-sharing.
That does not settle whether coordination is desirable or legally workable. It shows that a technically coherent pacing rule can still collide with competition law, incentives, verification, and trust.
The same problem appears at every layer. Evaluators can have access without final authority. Standards can lag the capabilities they are supposed to classify. Companies can agree on a rule and disagree on the evidence. Countries can agree on the risk and distrust each other's verification. A targeted hold can also redirect researchers, compute, or experimentation into work that remains unconstrained rather than reducing total frontier progress one-for-one.
The last point is especially easy to overstate. OpenAI has described substitution and reallocation effects around its own pacing decision. That is not evidence that the same effect, at the same scale, exists across labs.
"Pacing" tells us that restraint exists somewhere in the design, but it does not tell us what the design can survive.
What I'd hope to see in the next pacing proposal
A proposal does not need one universal formula to be legible. But if I'm trying to understand what it would actually do, there are six questions I'd hope to be able to answer:
- Object: What can actually be stopped, delayed, withheld, or conditioned?
- Trigger: What observed capability, incident, evaluation result, or risk judgment activates restraint?
- Verifier: Who receives the evidence, who can challenge it, and what independence or access do they actually have?
- Continuation: What new evidence is sufficient to proceed, and who decides that it is sufficient?
- Scope: Does the rule apply to one workload, one lab, frontier-class models, an industry, or multiple countries?
- Status: Is this an implemented control, an internal framework, a public proposal, or a restraint principle?
Those questions will not resolve the substantive disagreements. They do something more basic: they stop one word from pretending the disagreements are already resolved.
The frontier does not have one speed setting.
Before arguing about whether to turn it down, I think we should know what is actually wired to the control.
// End of transmission. Ask where the brake is — ZYANE