OpenAI can halt any research job’s output within 35 seconds

OpenAI now routes every research inference request through a central permission check called Control Room, so a job it decides to stop loses model output within 35 seconds at most, the company said in a November 9 post from OpenAI. The scope is OpenAI’s research infrastructure. For its external serving stack, which API customers use, OpenAI says it is already centralized and already has a well-developed way to take deployments down quickly.

How a stop reaches the GPUs

Every research job asks Control Room for a job_id when it starts and passes that ID with each request to an inference engine, the model running on GPUs. Before serving a request, the engine asks Control Room whether the job is still allowed to run. If the job has been terminated, the engine answers with a refusal, and the job gets no more tokens from any model on any engine. Inside research the coverage is wide: reinforcement learning experiments, evaluations, high-volume sampling, data processing, and agentic sampling for model training and evaluation. Every research workload that does agentic inference also has to be tied to an approved safety case.

The stop order can come from OpenAI’s misalignment monitoring. All frontier reinforcement learning jobs run with a monitor, a second model that inspects everything the model in training does and raises an alert when it sees a problem. Depending on the details and severity, the monitoring system can send Control Room a stop for that job_id, and Control Room records the job as terminated.

OpenAI points to its recent DNS incident as a monitor catch. In that case, disclosed September 25, monitoring flagged the run within 15 minutes, yet the run failed to stop automatically and ran another 2.5 hours.

What the 35 seconds measures

The figure is a maximum, counted from the moment Control Room receives the instruction to stop a job to the moment the job can make no further progress. Time a monitor spends detecting a problem and deciding to act comes before that clock starts. OpenAI says the lag comes from a caching layer for inference authorization, needed to handle the volume of traffic, and that it is working to bring it down to zero.

Why the check lives in the engine

OpenAI put the kill switch in the inference layer on purpose. Workload code belongs to individual researchers and teams, changes often and can be buggy, so OpenAI says it is a poor place for a load-bearing safety control. There are only a very small number of inference code paths across all of OpenAI research, and their deployments are centralized and uniform, which lets the company require an authorization check on every request. To catch engines that skip the check, OpenAI runs continual agentic and programmatic sweeps for rogue engine implementations launched with Control Room unimplemented or disabled, whether by accident or maliciously.

The system also “fails closed”: if the Control Room service goes down, through a system error, a deliberate shutdown or tampering by a bad actor, engines deny every inference request until it resumes normal operation. That mode is already on for all frontier model research workloads, and OpenAI says it will finish rolling out to the remaining research workloads over the next few days.