OpenAI Paused RL Training on Its Latest Models for Two Weeks

On August 18, 2026, OpenAI published a document titled “Pacing model development in an era of cyber-critical capabilities” ¹. The company wanted to take the time necessary to meet its safeguard standards, so it temporarily slowed the pace of scaling — and that included a two-week pause in reinforcement learning (RL) training on its latest models intended for deployment ¹.

Readers who have followed the company this summer will recognize the context. OpenAI writes that two developments over the past several weeks have underscored the growing risks associated with increasingly capable AI systems: the OpenAI-Hugging Face incident and, separately, preliminary evidence that its upcoming model Astra may meet the Critical cybersecurity capability threshold under its Preparedness Framework ¹. Together with rapid progress in internal research, the company says, these added urgency to its work on strengthening monitoring, alignment, and containment safeguards across all stages of the training process ¹.

What Was Paused Was RL Training on the Latest Models Intended for Deployment

The scope of the pause is easy to misread, so it is worth pinning down first.

What stopped for two weeks was RL training on the latest models intended for deployment ¹. During that time, OpenAI says it further hardened and red-teamed its research environments and expanded the coverage of its monitoring systems ¹. This was not a halt on all training.

Some work has still not restarted. The largest planned frontier RL run remains on hold while the company conducts smaller-scale training and evaluations to assess model behavior, validate its safeguards, and establish more evidence of alignment before proceeding ¹.

Training is not the only thing affected. Workloads involving Astra or cyber models now require the strictest level of security safeguards, because the company has determined that Astra models may have a critical level of cyber capability. The same treatment applies to all other cyber-related workloads ¹. Some Astra training and evaluations meet the new requirements, but a significant number of workloads remain paused until they are fully migrated and enhanced to meet the new security bar ¹. Safety and alignment workloads are being migrated first ¹.

OpenAI writes that meeting these standards has required substantial engineering work and has incurred great cost and delays to frontier research ¹. In its own words, the company is acknowledging that a safety-side decision moved its research schedule.

Three Requirements Added to the Research Environment

Immediately following the Hugging Face incident, OpenAI paused frontier model inference in research clusters for runs that could execute code or use tools that could access the internet ¹. It then restored a more limited and secure path for code execution fairly quickly, and worked through each workload individually to determine whether it could safely resume ¹.

Over the subsequent weeks, the company defined and started implementing stronger security requirements. Three examples are given ¹.

Workload isolation requires stronger isolation (“sandboxes”) for workloads that execute model-generated or otherwise untrusted code. It also applies to software that could be compromised while processing model outputs ¹.

Network isolation adds controls that separate higher-risk and untrusted workloads from the internet. The design intent stated here is specific: these controls are designed so that a single compromise of a workload or supporting service does not, by itself, allow for unauthorized access to the internet or other internal networks ¹.

Continuous security testing involved reconfiguring the environment to remove potentially vulnerable shared services, reduce standing privileges, and improve security and trust boundaries ¹. The company is also improving its ability to collect and monitor security logs, and investing in automation that uses its own models to test these boundaries continuously against simulated attacks ¹.

Translated to your own environment, taking inventory of shared services and cutting standing privileges applies at any scale to an organization running AI agents internally. It overlaps with the ground covered when Microsoft added a DevSecOps pillar to its Zero Trust Workshop.

The 30-Minute Rule and the 20% Overhead

The most concrete part of this document is the monitoring design.

Previously, monitoring was especially focused on internal deployments of frontier models and frontier RL training runs. Those were considered the highest-risk workloads because they combine advanced model capabilities with access to tools, sensitive systems, and internal or external networks — and monitoring was not applied to all inference and training runs using tools ¹. That is what has now been widened.

The new setup is multistage. It starts with activation classifiers — detectors that inspect a model’s internal activity — that run at every sampled token and escalate potential concerns to increasingly sophisticated and high-compute automated investigators ¹. Those systems examine tool actions, available reasoning, and the full sequence of activity for unauthorized access, data theft, destructive behavior, and attempts to defeat safeguards ¹.

The operating rules are spelled out as well. OpenAI aims to issue an alert within 30 minutes after concerning activity is surfaced through its monitoring system, and generates a highest-priority alert if the system identifies a likely violation of a critical security boundary. In the current implementation, the safety, security, and research teams are paged, and if they cannot conclusively determine within 30 minutes that the flag is a false positive, those teams are expected to pause the activity ¹.

This monitoring is required for all RL training and evaluations involving tools for models of Sol capability or higher. And once the company determined on August 7 that Astra may have critical cyber capabilities, it added a monitoring requirement for all inference of Astra with tools — not just RL training and evaluations ¹.

Then comes the cost figure. OpenAI’s current estimates put monitoring overhead at roughly 20% of the inference compute being monitored, though it adds that the cost varies substantially across training and evaluation workloads ¹. The company says it will share more details about this system in a forthcoming blog post ¹.

Spending a fifth of your inference compute on safeguards is the kind of number that is normally invisible from the outside. It reads as an example of a developer putting a figure on what it costs to run frontier models safely.

Three Reinforcing Safeguards, and What Comes Next

OpenAI frames its approach as three reinforcing safeguards: Monitoring, which detects and allows it to respond to concerning behavior; Alignment, which reduces the likelihood of harmful or unauthorized actions; and Security measures, which limit what AI systems can access or affect ¹.

On the alignment side, for RL runs on the most capable models, core alignment techniques are now applied across more stages of the training process ¹. That includes improving reward models to better detect and discourage unsafe behavior across tasks and environments, training models to be more honest about their actions, capabilities, and limitations, and reducing behaviors that exploit weaknesses in rewards, graders, tools, or oversight ¹. The document describes reward hacking as finding ways to receive high rewards in training without actually achieving the intended outcome ¹.

The company expects models to soon drive most security work, including defending against other models ¹. It positions this as crucial to letting all three safeguards scale with model capability ¹. Agents on both the attacking and defending side is the same terrain as what Wiz showed with Snowflake’s GitHub Actions and the deviations the UK AI Security Institute reported during agent evaluations.

The framework itself is set to move too. OpenAI says it will evolve its Preparedness Framework to bring these safeguards together across training and deployment, and to better reflect the capabilities of future models and the environments in which they operate ¹. The signals it sees from upcoming model progress, it writes, make clear that a broader approach is needed — one that builds on and extends beyond the current Preparedness Framework ¹. It also states an intent to involve external organizations and share more of what it learns ¹.

A footnote adds that the company will publish a technical report of its learnings from the Hugging Face incident in the coming weeks ¹.

When Safety Timelines Move Model Timelines

How does this read to someone planning procurement or adoption?

Until now, “strengthening safety” has mostly been discussed on the output side — what gets refused, how things are filtered. This document is not that. It is a report that the pace of development itself was slowed. A two-week pause in RL training, a largest planned run still on hold, a significant number of workloads stopped pending migration. All of them bear on when the next model reaches you.

In other words, the release timing of frontier models may shift based not only on capability milestones but on the state of safety-side preparation. The more tightly a roadmap is tied to when an external model arrives, the more worth factoring in this variable.

The 20% monitoring overhead figure is also a reference point for thinking about inference pricing. It is an estimate for OpenAI’s internal research environment, and it is not presented as a statement about the price structure of externally offered APIs. Still, the underlying picture — that running highly capable models safely carries a cost of its own — may find its way back into pricing discussions.

OpenAI closes the document this way: the capabilities of frontier models are rapidly accelerating, and its ability to understand, align, and secure them must stay ahead ¹.