OpenAI deploys Control Room to halt model output in 35 seconds

The need for a kill switch

OpenAI recently introduced a system called Control Room to manage and monitor model workloads across its research infrastructure. The company built this tool to provide a central way to stop model outputs quickly when safety or security concerns arise. It serves as a primary mechanism for human oversight over automated AI processes.

The move follows a specific incident in September where a training run was flagged by OpenAI's own monitoring system. According to the company's report, a person began reviewing the alert, but the run was not killed until 2.5 hours later. This delay highlighted a need for faster operational responses during research.

By creating a dedicated system, OpenAI aims to close these operational gaps. The Control Room is designed to connect every research inference workload, which includes tasks like data processing and agentic sampling for model training and evaluation.

How the architecture works

The Control Room operates as a service that sits between the workload and the inference engine. Each new job must first request a unique job_id from the Control Room. The inference engines then check with this service before they are allowed to fulfill any specific request.

If a job has been marked as stopped, the service denies the request, which prevents any further output from the model. This design ensures that the stop command sits in the inference layer rather than requiring changes to the researchers' own code. OpenAI notes that there are only a small number of inference code paths in use across its research.

To ensure the system is reliable, OpenAI says it has been built to keep working even when other systems fail. It is also designed to stop model output if the Control Room service itself goes down. This is known as a "fail-closed" design, which means all inference requests are denied until the service is restored.

Addressing the 35-second lag

OpenAI states that the Control Room can halt model output within a maximum of 35 seconds of a decision to stop a job. The company explains that this specific lag is caused by a caching layer used for inference authorization. This layer is necessary to support the high volume of traffic required by their research infrastructure.

The company is currently working to drive this number down to zero so that they can end jobs instantly. While 35 seconds is the stated maximum, it represents a significant improvement over the 2.5 hours (or 9,000 seconds) it took to kill the run in the September incident. The two figures measure different steps, as the September time included the human decision-making process.

OpenAI also conducts regular sweeps to ensure that no one launches engines with the Control Room disabled. This oversight ensures that the safety guardrails remain active across all frontier model research workloads. The fail-closed rollout is currently finishing across the remaining research workloads over the next few days.

Requirements for researchers

The introduction of Control Room changes how researchers at OpenAI must approach their work. The company now requires every research workload that does agentic inference to be associated with an approved safety case. This means that automated agents must have a documented safety framework before they can be run.

Because the engines check with the Control Room before every request, the system acts as a permission layer for AI behavior. This structure allows the company to maintain a centralized point of control over various types of inference, including those used for evaluation and data processing.

While the external model-serving stack is already more centralized, the Control Room provides a specific internal mechanism for research. It allows the company to demonstrate a measurable ability to intervene in complex, multi-step AI behaviors that might otherwise be difficult to stop once they begin.

The path forward

OpenAI has not yet published any outside tests to verify the 35-second stopping time or the deployment status of the Control Room. The company's statements currently serve as the primary record of how the system functions and its current reach within the organization. Future updates will likely focus on reducing the authorization lag to zero.

The rollout of the fail-closed mechanism is expected to be complete across all research workloads within a few days. This completion will finalize the infrastructure for frontier model research, ensuring that the system defaults to a stopped state if any part of the control service is compromised or fails.

As the company continues to develop more capable models, the Control Room will serve as a key piece of infrastructure for safety. It provides a technical answer to the question of how a company can maintain human control over high-speed, automated AI systems that may behave in unpredictable ways.