OpenAI Control Room puts the kill switch where researchers can't break it
35 seconds. That is how long OpenAI says it now takes to stop a research model from producing any more output once someone decides to pull the plug. The system is called Control Room, announced Monday, and it is already deployed across OpenAI's research infrastructure.
The design is the interesting part. Every research job gets a job_id from Control Room when it starts. Every time the job wants tokens, the inference engine asks Control Room whether that job_id is still allowed. If a monitor flags a problem, say an RL run doing something like the DNS incident OpenAI disclosed earlier, the monitoring system tells Control Room to stop the job, and the next request from that job to any model on any engine gets refused. The 35 seconds is the lag from an authorization cache needed to handle the traffic, and OpenAI says it is working to bring that to zero. Every research workload that does agentic inference must also be tied to an approved safety case.
Why put it in the inference layer? OpenAI's answer is blunt: researcher code changes all the time and is "not an ideal place to implement critical load-bearing safety protections". There are only a handful of inference code paths across all of research, so that is the choke point. It also fails closed. If Control Room goes down, gets disabled, or gets tampered with, all research inference is denied until it comes back. Fail-closed is live on frontier research workloads now and finishes rolling out to the rest "over the next few days". OpenAI also runs agentic sweeps looking for rogue engines with the check switched off.
This is the controls-outside-the-model idea, built by a lab for its own training runs. A monitor that can only write an alert is a smoke detector. A monitor wired to a fail-closed gate is a sprinkler. The caveat is that all of this is OpenAI describing its own system: nobody outside has checked the 35 seconds or the coverage claim, and external model serving is not part of Control Room (OpenAI says that stack is already centralized with its own takedown process).
Source: https://openai.com/index/introducing-control-room/
← Back to all articles
The design is the interesting part. Every research job gets a job_id from Control Room when it starts. Every time the job wants tokens, the inference engine asks Control Room whether that job_id is still allowed. If a monitor flags a problem, say an RL run doing something like the DNS incident OpenAI disclosed earlier, the monitoring system tells Control Room to stop the job, and the next request from that job to any model on any engine gets refused. The 35 seconds is the lag from an authorization cache needed to handle the traffic, and OpenAI says it is working to bring that to zero. Every research workload that does agentic inference must also be tied to an approved safety case.
Why put it in the inference layer? OpenAI's answer is blunt: researcher code changes all the time and is "not an ideal place to implement critical load-bearing safety protections". There are only a handful of inference code paths across all of research, so that is the choke point. It also fails closed. If Control Room goes down, gets disabled, or gets tampered with, all research inference is denied until it comes back. Fail-closed is live on frontier research workloads now and finishes rolling out to the rest "over the next few days". OpenAI also runs agentic sweeps looking for rogue engines with the check switched off.
This is the controls-outside-the-model idea, built by a lab for its own training runs. A monitor that can only write an alert is a smoke detector. A monitor wired to a fail-closed gate is a sprinkler. The caveat is that all of this is OpenAI describing its own system: nobody outside has checked the 35 seconds or the coverage claim, and external model serving is not part of Control Room (OpenAI says that stack is already centralized with its own takedown process).
Source: https://openai.com/index/introducing-control-room/
Comments