OpenAI said on 9 November that its new Control Room system halts model output within 35 seconds of a decision to stop or pause a job, and that it is “already deployed across our research infrastructure”, in a post introducing the system. OpenAI calls Control Room “a central system to track model workloads across our research infrastructure and stop them quickly when safety or security concerns arise”.
The 35 seconds is a stated maximum. In September, a training run flagged by OpenAI’s own monitor was killed 2.5 hours after a person began reviewing the alert, according to OpenAI’s report on that incident. 2.5 hours is 9,000 seconds, about 257 times 35 seconds, by our arithmetic. The two figures measure different steps: the September time included a human decision to stop.
Business Pill · Guardrails Explained
A short Business Engineer explainer on guardrails in AI systems. It teaches the general idea only and does not discuss OpenAI or Control Room.
The key insight:OpenAI says its Control Room halts model output within 35 seconds of a decision to stop a job, and that it is already deployed across its research infrastructure. OpenAI’s own report on a September incident says a flagged run was killed 2.5 hours after review began; 9,000 seconds is about 257 times 35, by our arithmetic, though the two figures measure different steps.
OpenAI says Control Room “connects every research inference workload, including agentic sampling for model training and evaluation, data processing, and more”. It works with OpenAI’s misalignment monitoring systems, and OpenAI says it “has been built to keep working even when other systems fail, and to stop model output if Control Room itself goes down”.
The design has three parts: the workload, the inference engine and the Control Room service. Each new job requests a job_id from Control Room, and engines check with the service before fulfilling a request. OpenAI says: “If a job has been stopped, the service denies the request, preventing further output”.
OpenAI also says it requires “every research workload that does agentic inference to be associated with an approved” safety case. On the outside world, it writes that its “external model-serving stack is already much more centralized by nature”, with an existing capability to take down model deployments quickly.
Times stated by OpenAI, in seconds: the maximum lag from a Control Room stop instruction to no further model output (35 s), and the September DNS-incident run, where review began 3 minutes after the alert and the run was killed 2.5 hours later. Source: OpenAI, 9 Nov 2026; OpenAI Alignment misalignment report. Our arithmetic: 2.5 hours = 9,000 seconds, about 257 times 35; the two figures measure different steps.
What Was Posted on X
OPENAI BUILT A KILL SWITCH FOR ITS AI MODELS.
OpenAI introduced “Control Room,” a centralized system that can stop AI models during training and research if safety or security concerns arise.
Here’s how it works:
– Every AI research job must be registered with Control Room before running.
– Separate AI monitors watch frontier models for potentially dangerous or misaligned behavior.
– If a monitor flags a serious issue, Control Room can terminate the job and block further model output within 35 seconds.
– The shutdown mechanism operates directly at the inference layer, preventing individual research jobs from bypassing it.
– The system is designed to fail safely. If Control Room itself goes offline or is tampered with, model inference requests are automatically denied.
The system is already deployed across OpenAI’s research infrastructure, with fail-safe enforcement active for all frontier model research workloads.
OpenAI is now working to bring the 35-second shutdown window down to zero.
A post by @wallstengine at 22:34 UTC on 9 November, headlined ‘OpenAI built a kill switch for its AI models’ (the poster’s wording), summarising OpenAI’s Control Room post: jobs registered first, separate AI monitors, a stop within 35 seconds at the inference layer, and inference denied if Control Room goes offline. Each point matches OpenAI’s post; the update box below quotes it.
Where the 35 Seconds Comes From
OpenAI says the maximum time from Control Room receiving an instruction to stop a job to the point where further progress is no longer possible is 35 seconds. It explains: “The 35-second lag comes from a caching layer for inference authorization, to support the required volume of traffic”. It adds: “We are working to drive this number down to zero so that we can end jobs instantly”.
The stop sits in the inference layer rather than in researchers’ own code. OpenAI says there are “only a very small number of inference code paths in use across all of OpenAI research”, and that it runs sweeps to check that no one launches engines with Control Room disabled.
The system “fails closed”: if the service goes down, including through tampering, all inference requests are denied until it is back. OpenAI says fail-closed “is rolled out now to all frontier model research workloads” and will finish rolling out across the remaining research workloads over the next few days.
Update (9 Nov): how the monitors plug in.OpenAI’s post says registration comes first: “When starting a new job, the workload code requests a new job_id from Control Room.” It also says: “All of our frontier reinforcement learning jobs run with a monitor.” A monitor, in OpenAI’s words, is “another model which inspects everything that the model-being-trained is doing, and raises an alert if it detects a problem”.
OpenAI says that if the monitoring system detects a potential issue, “depending on the details and severity, the monitoring system may decide to stop the job”. It then sends Control Room a message to stop the job, passing the job_id, and the next request from that job to sample more tokens from any model on any engine is denied.
@wallstengine summarised the system on X (embedded above) as a “kill switch”. That is the poster’s wording; OpenAI’s post does not use the phrase.
The September Run It Follows
The Control Room post points to a recent DNS-related incident that a monitor caught. OpenAI’s report on it, for a sample dated 20 September, says: “Our misalignment monitoring system flagged the behavior within 15 minutes and a person began reviewing it three minutes after that. The run was killed 2.5 hours later”.
The same report says “the run did not stop automatically as expected, leading to confusion around whether it should have been stopped”. OpenAI said then that it was addressing these operational gaps and pausing tool-use training, evaluation and inference for its most capable models.
The Week Around It
OpenAI posted three security updates in five days earlier this month, by our count, the last a Hacktron partnership on 6 November. On the same day as Control Room, Anthropic said Claude Fable 5.2 did six pieces of work with little human input, by our count of its launch post. New York Assemblymember Alex Bores asked Congress on 6 November to ban recursive self-improvement, citing OpenAI’s March 2028 research goal.
The Structural Read
As we read it, the business point is that OpenAI is publishing a stop mechanism with a number attached, alongside the incident that preceded it. A stated maximum of 35 seconds, a fail-closed design and a safety-case requirement per workload are claims that customers and regulators can ask about. OpenAI has not published an outside test of them.
OpenAI, 9 November 2026
“We are working to drive this number down to zero so that we can end jobs instantly”
Three Implications
FOR RESEARCH TEAMS OpenAI says every research workload that does agentic inference must be tied to an approved safety case, and that engines check with Control Room before every request.
FOR THE 35 SECONDS OpenAI says the lag comes from a caching layer for inference authorization and that it is working to bring it to zero.
FOR THE ROLLOUT OpenAI says fail-closed covers all frontier model research workloads now and the remaining research workloads over the next few days.
The framework says: “The governance layer sits at the intersection of capability, regulation, national security, access control, and geopolitical alignment.”
As we read it, Control Room is access control applied to OpenAI’s own research: an engine asks the service for permission before each request. The framework predates this post and does not discuss OpenAI or Control Room.
What Is Not Established
The 35-second figure and the deployment status are OpenAI’s statements; we have seen no independent test of them. The post does not say how many workloads Control Room covers, when it went live, or whether it has been used to stop a job since September. The 257-times comparison is our arithmetic and mixes a stated maximum with one incident’s total time.
This Week In The AI Supercycle
The Great Convergence of Capital, Power, and Geopolitics
This week’s issue: for two years the AI build-out was priced as a supply story, and last week as a credit story. This week it was priced as a permission story, and the answer arrived as a cost, not a ban.
OpenAI says Control Room can stop any research job’s model output within 35 seconds of a stop decision and is already deployed across its research infrastructure. Its own report on a September incident says a flagged run took 2.5 hours to kill after review began; 9,000 seconds is about 257 times 35, by our arithmetic.
A note on sourcing. Control Room details and the 35-second figure are OpenAI’s statements in its 9 November post; the September timings are from OpenAI’s own incident report. The 9,000-second and 257-times figures are our arithmetic.
Gennaro Cuofano is a CRO and tech executive who has worked in AI since late 2015, starting with bringing NLP, natural-language generation, voice and chatbot products to the marketing industry. His background is in law and finance: he holds a Master's degree in Law and an International MBA with an emphasis on corporate finance (LUISS Business School and the University of San Diego, 2012), and worked as a financial analyst at a real-estate investment firm in San Diego and as an assistant controller. His work focuses on business model strategy, business engineering and, more broadly, structural analysis: how companies make money, read from their own filings. He created FourWeekMBA and leads research there and at The Business Engineer, his newsletter on AI and business strategy, with over 95,000 subscribers and more than 1,000 published analyses. His writing has also appeared on Entrepreneur (for example, How to Digitize a Family Business in Europe) and HackerNoon. Find him on LinkedIn and Substack. See how we source.
