OpenAI's Control Room Can Halt Any Model Workload in 35 Seconds

OpenAI has built a central kill switch for its own research infrastructure, a system called Control Room that can halt model output across all internal workloads within 35 seconds of a decision to intervene. The company disclosed the system in an engineering post titled "Control Room: A central system to track and stop model workloads across our research infrastructure," and says it is already deployed across its research infrastructure, where the company judges the need to be greatest.

The system exists because of a scaling problem in AI safety. As OpenAI's models grow more capable, the company states, the safety and security risks grow alongside them, and the ability to detect potential issues and quickly stop models becomes critical. Control Room is the operational answer: a centralized service that tracks every research inference workload — including agentic sampling for model training and evaluation, and data processing jobs — and can stop them when safety or security concerns arise.

The system works in concert with OpenAI's misalignment monitoring systems, and the company reports a hard upper bound on response latency: no more than 35 seconds passes between Control Room receiving a stop instruction and further model progress becoming impossible. The lag comes from a caching layer for inference authorization, which exists to support the required traffic volume. OpenAI says it is working to drive that number to zero, which would allow jobs to end instantly.

Why does the 35-second figure matter?

Frontier AI labs increasingly frame rapid shutdown capability as a precondition for safe training. A reinforcement learning experiment running high-volume agentic sampling can generate large amounts of model output between checks; the interval between an intervention decision and a guaranteed halt defines how much of that output can escape containment. OpenAI has committed to a bounded interval, and to a fail-closed design that keeps working even when other systems fail.

Fail-closed means the engine-side integration is configured so that if the Control Room service itself goes down — whether from a system error, disablement for any other reason, or tampering by a bad actor — all inference requests are denied until the service resumes normal operation. In other words, if the kill switch breaks, the models stop. OpenAI states that fail-closed behavior is rolled out now to all frontier model research workloads and will finish rolling out across all remaining research workloads over the next few days.

The company's external model-serving stack, which handles deployed products, was already much more centralized by nature, according to the post, with a well-developed operational capability to take down model deployments quickly. Control Room extends comparable guarantees to research infrastructure, which is more fragmented.

How does Control Room actually stop a job?

The architecture integrates three systems: the workload, the inference engine, and the centralized Control Room service.

• The workload is the job being run — a reinforcement learning experiment, an evaluation, a high-volume sampling job, or a data processing job. OpenAI requires every research workload that performs agentic inference to be associated with an approved safety case, a documented argument that the activity is safe to run.
• The inference engine, or engine, is the model itself. OpenAI describes the engine as "the brain of the model," running directly on GPUs. One workload may use multiple models across multiple engines, and one engine may serve multiple workloads.
• The Control Room service tracks jobs and controls whether they are allowed to keep generating output. Engines check with the service before fulfilling any request; if a job has been stopped, the service denies the request.

The request flow follows a strict sequence. When a new job starts, the workload code requests a new job_id from Control Room. Whenever the workload needs to sample tokens from a model, it sends a request to an engine, passing the job_id. The engine then requests permission from Control Room, forwarding the job_id. Control Room checks whether that job has been terminated; if it has, the engine's request is denied, and the workload receives a refusal — stopping further model output for that job, on any engine, for any model.

Where does the enforcement bottleneck sit?

The design choice with the largest engineering consequence is where enforcement lives. Workloads — experiments, evaluation jobs and the rest — are normally owned and operated by researchers or teams of researchers. Workload code changes often, OpenAI notes, and is therefore not an ideal place to implement critical load-bearing safety protections. The implementation is instead designed to be resilient to buggy or broken workload code.

OpenAI achieves this by implementing the termination mechanism in the inference layer. Workload code is highly varied and decentralized, but only a very small number of inference code paths are in use across all of OpenAI research, and their deployments are much more centralized and uniform. That makes the inference layer a bottleneck, giving the company strong guarantees that all model inference in research is subject to Control Room authorization checks on every single inference request.

The bottleneck still requires policing. OpenAI additionally runs continual agentic and programmatic sweeps to check that users are not accidentally or maliciously launching rogue engine implementations with Control Room unimplemented or disabled — an admission that the centralized choke point only holds as long as no one routes around it.

How do monitors trigger a shutdown?

All of OpenAI's frontier reinforcement learning jobs run with a monitor, which the company defines as another model that inspects everything the model-being-trained is doing and raises an alert if it detects a problem. OpenAI cites a concrete precedent: its recent DNS-related incident was caught by a monitor. The integration path is direct. If the monitoring system detects a potential issue, it may — depending on details and severity — decide to stop the job. It sends a message to Control Room with the job_id, and Control Room records the job as terminated. The next inference request from that job, to any model on any engine, is denied.

What comes next?

OpenAI frames Control Room as one part of a holistic approach to safe frontier model training and deployment. The company says it will continue to strengthen and expand the system over the coming months, alongside continued investment in monitoring for misaligned behavior and security breaches, and it is hiring engineers to build systems for what it calls the safe and secure development and deployment of AGI.

The near-term milestone to watch is the zero-latency target: OpenAI wants to eliminate the 35-second caching delay and end jobs instantly. Completing the fail-closed rollout across all remaining research workloads in the coming days would close the gap between the system's stated guarantees and its actual coverage.