AI labs discuss slowing down while releasing new models
Anthropic called for ways to pace frontier AI and OpenAI backed external evaluation. Days later, both companies announced new models. Here is what happened and what remains unresolved.
September 22, 2026 left an awkward picture for the AI industry. Anthropic introduced Claude Opus 5.5 and OpenAI announced GPT-6 Sol and GPT-6 Luna. Both releases came just days after industry leaders had publicly discussed a difficult question: how can frontier AI development slow down when everyone has incentives to keep moving?
It is tempting to reduce the sequence to a contradiction: companies call for brakes while keeping their feet on the accelerator. Their publications tell a more precise story. Nobody announced a general pause in releases. The discussion is about building evaluations and shared rules that would make it possible to buy time if a system outruns the ability to understand or control it.
A statement signed by people, not companies
The discussion was already under way in July. The Pacing the Frontier statement has 1,386 signatories from frontier AI companies, including people associated with OpenAI, Anthropic, Google DeepMind and other organizations. They ask the US government to support an international effort to develop the technical and governance tools needed to deliberately pace automated AI development.
The statement identifies a coordination problem. If one company needs more time to assess a model, it may fear that another will use the delay to release first. Countries face a similar pressure. The signatories are asking for the option to buy time, backed by tools that would make such a decision workable across the frontier.
The distinction matters: these are individual signatures. The initiative says personal comments do not necessarily represent a company’s views. It is neither a binding agreement between OpenAI and Anthropic nor a legal commitment to stop training. Reporting it as an industry-wide deal to slow down would overstate what happened.
Dario Amodei’s proposal
In September, Anthropic’s CEO developed the argument in We Must Pace the Frontier. Dario Amodei argued that capability gains need to leave enough time to investigate risks and put safeguards in place. He explicitly wrote that pacing does not mean halting model training or technical progress.
His plan has three layers. The first gives external evaluators ongoing access inside each lab, allowing them to check safety practices, report incidents and assess the development process as well as finished models. Anthropic says it is committing to this step on its own. The second layer requires coordination among companies. The third calls for international cooperation, because rules shared by only a few labs would have limited reach.
Those layers are different kinds of commitments. A company can open its own processes to outside evaluators. It cannot, on its own, make its competitors follow the same criteria for delaying a release. The first step can be checked lab by lab; the others still require agreements that have not yet been built.
OpenAI CEO Sam Altman publicly said he agreed with pacing the frontier and allowing outside evaluators access. Coming from a direct competitor, that support was notable. It was not, however, a pact to suspend releases. Agreeing on a direction and establishing enforceable conditions for action are different steps.
The September 22 releases
The immediate test of that distinction arrived on September 22. Anthropic released Claude Opus 5.5 as the first model in its Claude 5.5 family. According to its announcement, it performs at the level of Claude Fable 5.1 on most work and costs 40% less to run than Opus 5. Those are Anthropic’s comparisons, not independent measurements by BLOKIS.
Anthropic also said that external organizations, including Frontier Design and METR, evaluated Opus 5.5 before release, and that it carries safeguards for its most capable models. The company describes it as its first major release since calling for pacing the frontier. In its account, additional evaluation and a new release are meant to coexist.
On the same day, OpenAI expanded the GPT-6 family with Sol and Luna. Its announcement presents them as models bringing some of Astra’s advances to different balances of speed and cost. The API changelog confirms the September 22 date and the identifiers gpt-6-sol and gpt-6-luna. OpenAI also updated its GPT-6 Astra announcement to mention the expanded family.
The sequence establishes two facts at once: labs are talking about outside evaluation and they are still competing through new models. A release alone does not show that a pause commitment was broken, because no such commitment was announced. It does not prove that the proposed safeguards are sufficient either.
Where the real tension lies
The hard case comes when an evaluation recommends more than an improved safeguard and instead calls for a delay. What finding would trigger that decision? Who would be able to review the evidence? Would an incident be disclosed outside the lab? What happens if another competitor decides a similar system is ready to ship?
Suppose a lab finds behavior during testing that it cannot explain well and decides to spend several more weeks investigating it. That time may allow a fix, but it may also mean losing customers, researchers or a technical lead to a competitor that releases first. The choice would look different if other developers had accepted comparable criteria for responding to the same finding. This is the cost of acting alone that the July statement puts at the center of the debate.
Good intentions from executives do not resolve the problem. Someone must decide what information is shared, with whom, when and under what safeguards. A company might treat the details of an incident as confidential for security or competitive reasons. An evaluator needs enough access to determine whether a promised measure was followed. The public has a legitimate interest in learning when a system was delayed over a serious risk. These needs can conflict even if everyone agrees that safety matters.
External evaluators address part of the problem by letting more people examine a company’s safety claims. Coordination between labs addresses another part by lowering the cost of being the only one to wait. International cooperation tries to extend that possibility beyond a small group of companies. None of these measures can replace the others.
Evaluation should also be distinguished from a guarantee. Independent testing before release is relevant information. It does not mean a model is safe in every setting, with every permission or over a long sequence of actions. Tests have a scope, conditions and limits; readers need to know them to judge what the results mean.
That is why the phrase “evaluated by third parties” raises more useful questions than it settles. What could the evaluators observe? Did they have access during training or only to the finished model? Could they report an incident without seeking the lab’s permission? Were tests repeated after changes to the model? Anthropic names outside evaluators for Opus 5.5, but the larger debate is about making this kind of access sustained and verifiable, rather than treating it as a label attached to a launch.
Timing matters too. If assessment starts only when a product is ready to ship, delaying it may be difficult and costly. Monitoring during development could uncover some problems earlier and leave more room to fix them. That is one reason Amodei proposes evaluators with ongoing access. The quality of oversight depends on when and how much an evaluator can see, as well as on the evaluator’s reputation.
Why this matters outside the labs
This question reaches teams building AI into products. An assistant that summarizes documents has a different reach from an agent with access to a repository, a browser, a database or company email. As capabilities and permissions grow, a mistake can become an executed action rather than an incorrect answer.
That is why evaluation cannot be reduced to a benchmark score. Teams also need to test what a system does with real permissions, how it records its steps, when it asks for approval, how access can be revoked and what happens when it meets an unexpected task. Those questions connect the frontier debate to everyday engineering decisions.
An organization can turn that into specific choices: separate tasks that only read information from those that change data, give each agent only the access it needs and require human review before actions that are hard to reverse. It then has to test whether those boundaries still work when a model makes a mistake, misreads an instruction or carries out a long chain of steps. A team does not have to train a frontier model to face this problem; using one in a real workflow is enough.
The public discussion also needs to separate announcing a measure from showing that it works. A press release can describe a new evaluation process. Its effect will show in the access evaluators receive, the incidents they detect and the decisions their findings change. If no test ever affects the schedule or scope of a deployment, it will be difficult to tell how much authority that process really has.
The news, then, is not that the race has stopped. September’s releases show it has not. What has changed is that people inside the labs, and at least two of their leaders, are discussing how to build a real capacity to slow down when an evaluation demands it. The shared criteria, independent access and verifiable commitments that could make this possible remain to be seen.