The most interesting detail about OpenAI’s new Control Room is not the 35-second stop time. It’s that the system is built to assume the researchers’ own code will break. That’s a sensible design choice, and one few labs have described this plainly.
OpenAI announced Control Room as a central system that tracks model workloads across its research infrastructure and stops them when safety or security concerns come up. It covers every research inference workload, including agentic sampling for training and evaluation, and data processing. It’s already deployed.
How the kill switch works
Three pieces are involved: the workload (an RL experiment or an eval), the inference engine running the model on GPUs, and the Control Room service. A job requests a job_id at the start. Each time it samples tokens, the engine asks Control Room for permission, passing that ID. If the job has been terminated, the request is denied and output stops.
The trigger can be a monitoring model. OpenAI says all frontier reinforcement learning jobs run with a monitor, another model that watches what the model in training is doing. If it flags a problem, it tells Control Room to kill the job. OpenAI says its recent DNS-related incident was caught this way.
Why it sits in the inference layer
Research workload code changes constantly and is owned by many different teams. That’s a poor place for safety controls. Inference code paths are few and uniform, so OpenAI put the check there. It also runs agentic and programmatic sweeps to catch anyone launching rogue engines without the check.
The system also fails closed. If Control Room goes down, whether from an outage or tampering, all inference requests are denied until it returns. That’s already live for frontier workloads, with the rest due within days.
The limits
The 35-second delay comes from a caching layer for authorization, needed to handle traffic volume. For a fast-acting agent, 35 seconds is a long time. OpenAI says it’s working to get this to zero, but today it’s a real gap. Also, this covers research infrastructure only. Production serving is more centralized and already has takedown tooling.
Does it matter?
For most developers, no direct impact. You can’t use it. But it matters as a signal. Anthropic, Google DeepMind and others publish safety frameworks, yet few describe operational controls at this level. A kill switch that fails closed is a concrete, checkable claim, which is more useful than a policy document.
The caveat is that it’s self-reported, and a stop mechanism only works if monitors catch the problem first. Still, as models get more agentic, this kind of plumbing will become standard, and labs that can’t show it will face harder questions.
