OpenAI Ultrafast in Codex: Cutting Incident Investigation From Hours to Minutes
OpenAI published an internal case study on October 26, 2026, describing how its own engineers use Ultrafast, a high-speed mode in Codex, as their default tool for incident response. The headline claim is operational rather than benchmark-based: security investigations that once took one to two hours of pulling together structured and unstructured data now finish in 10 to 15 minutes, and individual answers frequently arrive fast enough (under roughly 30 seconds) that engineers stop context-switching while Codex works.
TL;DR
Ultrafast is a high-speed mode in Codex, and OpenAI reports that its technical staff have made it the default for incident response, security investigations, refactoring, and daily planning. The primary quantified outcome in the post is that security investigations that used to take an hour or two now take 10 to 15 minutes, sometimes near real time. The post is part of an OpenAI series sharing internal examples of how the company uses its own technology and APIs, and it presents these as illustrative examples rather than as published benchmark results.
What Ultrafast is, according to the source
Ultrafast is a high-speed mode inside Codex, OpenAI's coding agent. The post frames the feature around latency tolerance: when production breaks, engineers cannot wait minutes for an answer while the incident compounds, so a faster mode lets them investigate multiple potential causes at once.
The source does not publish an engineering specification for Ultrafast. It states no token throughput figures, no model version identifiers, no hardware details, and no latency percentile measurements. Everything quantitative in the post comes from named OpenAI staff describing their own workflows.
Incident response: searching many "haystacks" at once
OpenAI's incident workflow centers on a Slack channel and a Codex thread pointed at the problem. Aaron Friel, a Member of the Technical Staff at OpenAI, typically runs point on incidents: he spins up an incident-response Slack channel and then directs Codex to monitor, investigate, and answer questions as they arrive.
"In any incident, there are usually many hops along the way of what could have gone wrong, and finding the right needle in the right haystack is really the chief job of the people on that channel. Using Ultrafast, I'm able to essentially search all of those haystacks at the same time, and respond to incidents much faster."
That parallel-investigation pattern is the core structural claim of the post: rather than serializing hypotheses, engineers let Codex pursue several candidate causes simultaneously and report back while the incident is still live.
Security investigations: from one to two hours down to 10 to 15 minutes
The most concrete number in the post comes from AJ Trbojevic, a Member of the Technical Staff and Datacenter Security Architect at OpenAI. He describes the prior process for security investigations as taking an hour or two to gather structured and unstructured data, normalize it, and assemble enough context to make a decision.
"Now that happens in 10 to 15 minutes. And at times it's near real time."
This is the figure behind the post's "hours to minutes" framing. It is a self-reported workflow comparison by a practitioner, not a controlled benchmark, and the source does not specify the sample size, the incident types involved, or how the measurement was taken.
The 30-second threshold
Ultrafast's practical value in the post is defined by a human attention limit rather than a machine metric. Jeff Niu, another Member of the Technical Staff, states his own rule: if it takes more than 30 seconds to find an answer with AI, he will switch to Slack or ask a coworker instead.
With Ultrafast, Niu reports that most of his work now falls under that threshold. He describes the previous pattern of asking Codex a question, switching to something else while it thought, and returning having lost his train of thought. The change he highlights is conversational continuity: the exchange now happens in real time, which keeps him focused on the task at hand.
The 30-second figure is Niu's personal switching threshold, not a documented performance guarantee for Ultrafast.
Refactoring and technical debt
Faster responses change what work engineers are willing to start. Niu says Ultrafast makes him more willing to take on large refactors because reworking existing code takes less time.
"Technical debt is much easier to pay down now than it ever was before. Code is cheap, and now it's very quick to produce. A refactor that used to cost a lot happens almost instantly."
The claim here is behavioral rather than financial: lower interaction latency lowers the perceived cost of starting a big change, so deferred cleanup work gets done.
Codex as a persistent daily copilot
Adam Perry and Sayan Sisodiya, both on the core agent team that builds the code letting Codex take actions, run commands, and use tools, describe two day-to-day patterns.
Perry keeps a standing Codex thread he calls his chief of staff. Every morning it reports his meetings and flags messages he may have forgotten to reply to.
"It's already looked at all the data to write that summary, so when I ask a followup, it's not waiting to go fetch more. I can just keep asking questions in the same conversation just like an actual chief of staff."
Sisodiya uses Codex for browser-based manual work such as filling out forms, a task he previously avoided because it was too slow.
"It would open a browser, sit there thinking for five seconds, click something, sit there again."
He attributes his changed willingness to delegate that work to improvements in computer use in the latest models, combined with Ultrafast's speed.
"Now I'm totally fine letting it click through the browser and it's fast enough that I'm not losing time by not doing it myself."
Why engineers stopped running Codex in parallel with themselves
Before Ultrafast, engineers treated Codex as a background task that could not be trusted to return in time. Perry describes the old behavior directly:
"Before, I'd ask Codex to look into something, and then go look into it myself at the same time, because I knew it wouldn't be fast enough to just wait on. Now with Ultrafast, Codex is fast enough that I can just stay focused instead of splitting my attention."
Sisodiya describes using Codex beyond log analysis during incidents, searching Slack for references to suspect changes or for other people reporting similar symptoms elsewhere in the workspace.
"Beyond just digging through logs in an incident, I use Codex to dig through Slack to see if there are references to changes that might be suspect or people talking about similar symptoms elsewhere in Slack."
The recurring theme across all five engineers is that latency, not capability, determined whether they delegated work at all. The post's own conclusion is that Ultrafast "lets OpenAI's Technical Staff work with Codex at the pace of their questions," letting them follow up on an answer or try another approach without losing their train of thought, and changing what work they are willing to take on.
What the post does and does not claim
Stated in the source:
- Ultrafast is a high-speed mode in Codex.
- OpenAI engineers use it as the default for incident response.
- Security investigations went from "an hour or two" to "10 to 15 minutes," sometimes near real time, per AJ Trbojevic.
- A 30-second answer threshold governs whether Jeff Niu keeps using AI or switches to Slack or a colleague.
- Faster responses increase willingness to take on large refactors, per Jeff Niu.
- Codex is used for daily planning summaries and browser-based form filling, with computer-use improvements in the latest models cited as part of that shift.
Not stated in the source:
- No benchmark scores, latency percentiles, throughput numbers, or model version identifiers.
- No description of how Ultrafast is implemented technically.
- No measurement methodology for the hour-to-minutes comparison.
- No pricing, availability, or rollout information for Ultrafast.
The post is explicitly framed as part of an OpenAI series sharing internal examples of how OpenAI uses its own technology and APIs, presented as illustrative examples of frontier AI supporting use cases across its teams rather than as a product announcement or evaluation.