OpenAI says Control Room halts research model output within 35 seconds; scale, drills and audit not stated

One number, 35 seconds, and the clock it measures

OpenAI's post Control Room: A central system to track and stop model workloads across our research infrastructure is listed in OpenAI's news index under 9 November 2026; the page itself prints no date. Its text prints one measurement: a maximum of 35 seconds between Control Room receiving an instruction to stop a job and further progress becoming impossible. That figure appears three times in the saved text (derived count), and it is the only measurement in the body. The page prints no count of workloads, engines or clusters, no count of alert types, no error rate, no result from any stop drill, and no date for the end of its fail closed rollout beyond "the next few days". The interactive figure has 13 steps (derived by counting the step headings).

What this does not establish. The 35 seconds is a design ceiling as OpenAI states it. The post does not say any job has been stopped this way, measured how often the ceiling is reached, or timed a drill. The opening paragraph and the speed section also start the clock at different moments: a "decision to intervene" in one, the moment Control Room "receives an instruction" in the other. Nothing on the page bounds the time between those two.

What kind of post this is. It is an engineering write up of an internal control, with a hiring request at the end and OpenAI named as the author. It is not a framework disclosure and it prints no independent review. OpenAI sells AI products and writes the post about its own infrastructure; a safety post is also a statement about how it wants to be seen. The text was read from a copy of the page saved on the morning of 13 November 2026 (UTC). The copy carries no revision note, and the post says fail closed will reach the remaining research workloads "over the next few days", so parts of it may already be overtaken.

How Control Room works, in the post's own parts

Control Room, as OpenAI describes it, "connects every research inference workload", including agentic sampling for model training and evaluation, and data processing. It works together with OpenAI's misalignment monitoring systems. The design joins three parts: the workload, the inference engine and the Control Room service. A workload asks Control Room for a job_id when it starts, then attaches that job_id to every request for model output. The request goes straight from the workload to an engine and, in the post's words, "does not pass through Control Room". Before answering, the engine asks Control Room whether that job is still authorised. If a person or the monitoring system has marked the job as stopped, Control Room says no and the engine returns a refusal.

Zoom

One design choice carries the post's argument. Workload code "changes often" and is not an ideal place for safety protections, so OpenAI puts the check in the inference layer, where "a very small number" of code paths serve all of its research. The post adds a backstop: "continual agentic and programmatic sweeps" to find engines launched with Control Room unimplemented or disabled. A sweep is a detective control. It finds a rogue engine after it exists; it does not stop one from starting. The post prints no sweep frequency and no result.

The 35 seconds, read twice

The post gives the figure in two places and words it differently. The table lines them up.

OpenAI says the 35 second lag "comes from a caching layer for inference authorization, to support the required volume of traffic", and that it is working to drive the number "down to zero". So the lag is a deliberate trade against traffic volume, and the volume is not printed. A reader cannot tell whether 35 seconds is typical or a worst case reached once a month. The post also leaves out how that cache behaves when Control Room is down: it says all inference is denied until Control Room resumes, but a cache that holds an allow for up to 35 seconds could keep answering during that time. That interaction is this site's inference from the two statements, not something the post says.

What stops is also narrower than the title suggests. The post says the stopped job's "research process may remain alive" and that the workload code can still try to sample model output and is refused. The control acts on requests to the model. The page does not say what a stopped job can still do without new model output, such as run tools it already has, write files or use the network. It also says "stop or pause" once and never describes a pause, or how a stopped job is allowed to resume.

The worked example is a mechanism, not an incident

The section headed "Example: reacting to a monitoring alert" describes the route in general terms: the monitoring system detects a potential issue, may decide to stop the job, and sends Control Room a message "passing the job_id". Control Room records the job as terminated and denies the next inference request. It does not narrate a job that was stopped this way. The only real event it touches is one sentence saying a recent DNS related incident "was caught by a monitor". Caught is not stopped, and the post does not say Control Room acted on it.

The earlier briefings on this site matter here. The briefing on OpenAI's 29 October monitoring post recorded that, for internal Codex traffic, paging was disabled, and that the post printed no incident count or miss rate. Control Room's post inherits the same gap: it describes the stop path in detail and says nothing about how many times it has been used.

Labels that do the work of evidence

Five phrases carry weight in the post. Each is a claim, not a result.

Zoom

What the post states, and what it does not

The reach row is the one a non research reader should read twice. The post says Control Room is deployed "where the need is greatest", across research infrastructure, and that the external model serving stack already has a "well-developed operational capability" to take down deployments. It then says nothing about how fast that capability is. A reader who runs OpenAI models in a product has been given a latency figure for research jobs and none for the service they use.

What to do, in order

The post gives readers no checklist. These steps are this site's suggestions, drawn from the questions the post leaves open.

Technical details

The post prints no command, API call, request format, log line or configuration. What it prints is names, one field name and a sequence of steps. They are copied below exactly, because an operator comparing their own system needs the vocabulary the post uses.

The first block is the vocabulary: the one field name, the three components and the two requirement terms. An operator maps each to their own system: what issues the identifier, what checks it, and what holds the approval.

job_id
workload
inference engine
Control Room service
approved safety case
fails closed

The second block is the integration sequence, in the post's words. It is the whole mechanism. A defender uses it to ask, at each line, which system is trusted to do it and what happens when it does not.

When starting a new job, the workload code requests a new job_id from Control Room.
Whenever the workload needs to sample tokens from a model, it makes a request to an inference engine running that model, passing the job_id.
The engine requests permission from Control Room to fulfill that request, passing the job_id along to Control Room.
Control Room checks whether that job has been terminated, and if so, it denies the inference request.
The engine responds to the workload's inference request with a refusal, stopping further model output from being produced for that job.

The third block is the stop message path for an automated stop, and the interface labels from the post's figure, which show four example jobs in the active state. The post prints no message format; the figure labels are illustrative.

In this case, the monitoring system sends a message to Control Room to stop the job, passing the job_id.
job_039, active
job_040, active
job_041, active
job_042, active

Hunting and hardening, from the post's own terms: confirm that every model server you run asks a central service before answering; look for a server started without that check; and test what a request carrying no identifier, or an unknown one, receives. The post does not say what Control Room does in that case.

The question the post leaves open

If a stop order is given at the moment an alert fires, how many seconds pass until the last token that job can use has been produced, and has anyone at OpenAI timed that end to end with a real job and a real person giving the order?

Key facts