What OpenAI published

On 2026-10-26 OpenAI published an internal case study titled How Ultrafast cut incident investigation from hours to minutes at OpenAI. It is part of a series where the company documents how its own teams use its products - explicitly framed as illustrative examples rather than customer benchmarks.

The claim is concrete: Ultrafast is a high-speed mode in Codex, and for OpenAI engineers it has become the default for incident response. When something breaks, they investigate several possible causes at once and get answers in under 30 seconds.

The numbers, and who is saying them

The post leans on named engineers rather than aggregate statistics, which makes it easier to judge:

  • AJ Trbojevic, Member of Technical Staff and Datacenter Security Architect: security investigations used to take “an hour or two” to pull structured and unstructured data together, normalise it, and give enough context to decide. “Now that happens in 10 to 15 minutes,” he says, “and at times it’s near real time.”
  • Aaron Friel, Member of Technical Staff, runs point on incidents. He opens a Slack channel, then points Codex at the problem and asks it to monitor, investigate, and answer questions as they arrive. His framing: every incident has many hops of “what could have gone wrong”, and finding the right needle in the right haystack is the main job of the people in that channel. With Ultrafast he can “search all of those haystacks at the same time.”
  • Adam Perry, core agent team, describes the behavioural change: “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.”

That last quote is the most useful sentence in the piece, and it is not really about speed.

Why latency, not capability, is the lever

Perry’s metaphor is blunt: of two equally smart people, the one who answers in a minute beats the one who answers in an hour. That is a statement about throughput, and it explains why a “fast mode” changes a workflow that a smarter-but-slower model does not.

When an answer takes ten minutes, the rational move is to hedge - start your own investigation in parallel, because you cannot afford to idle. That hedging doubles the work and halves the benefit of having an agent at all. When the answer takes under 30 seconds, waiting becomes the cheaper option, so the human stops duplicating and starts directing.

Capability improvements usually do not change that calculus. Latency does, because the decision it changes is “should I do this myself while it runs”.

The pattern worth copying on a Windows desktop

You do not need Codex or OpenAI’s infrastructure to apply the structure. An incident-response agent on a Windows machine needs four things:

  1. A single channel per incident. One place where questions are asked and answers land, so the agent’s context and the humans’ context are the same. In OpenAI’s case that is a Slack channel; locally it can be a single notes file or terminal session.
  2. Read-first tooling. Logs, event viewer output, tickets, config files - the agent should be able to query all of it without the power to change any of it. Investigation and remediation are separate permissions.
  3. A latency budget you actually meet. If your agent takes minutes per step, no one will wait, and you are back to duplicate work. Measure the round trip, not the model’s benchmark score.
  4. Parallel hypotheses, serial conclusions. Searching three causes at once is cheap; acting on three fixes at once is not. Keep the fan-out on the reading side.

And the constraint that no case study removes: remediation still needs a human. The reported wins are all about finding - which service, which deploy, which permission change. That is exactly the part where a wrong answer costs attention rather than uptime.

If your incidents currently start with fifteen minutes of clicking through the same five tools, that is the loop to hand over first. MOOGH runs on Windows and drives the applications you already use, which is what those first fifteen minutes usually consist of.

FAQ

Does this mean incidents can be handled without engineers?

No. OpenAI’s examples are engineers using a faster tool inside their existing process, with humans making the decisions. The reported gains come from search and synthesis, not autonomous remediation.

What is the smallest useful version of this?

Give one agent read access to your logs and one channel to report into, and require it to answer with citations to the lines it read. That alone removes most of the manual gathering step.