"Staying on Track" Is the Hard Part: Third Moment Runs 10,000 Agents in 36–48-Hour Autonomous Research Sessions

One boundary to draw up front: this site recently covered the story of OpenAI and a flood of 722 mathematics manuscripts — that one was about data. This piece is about something else: infrastructure. OpenAI's official customer-stories section profiles a research outfit called Third Moment Research: they run 10,000 agents at once, in single autonomous research sessions lasting 36 to 48 hours, using Codex alongside the GPT-6 model family. It is a field report on agent engineering crossing from "run one demo" to "research continuously for two days."

A note on dating, stated plainly: OpenAI's customer-story page carries no publication timestamp. The October 14, 2026 date used here is derived from two independent third-party sources (netcontentseo and subagentic.ai) cross-checked against each other — it is not a date OpenAI itself published. The facts below come from OpenAI's official write-up.

The numbers tell the story best when unpacked: 10,000 agents running in parallel; single sessions of 36–48 hours of autonomous research; a model stack of Codex plus GPT-6 Astra, GPT-6 Sol, and GPT-6.1 Sol. Co-founder Adam Khakhar's central claim is that within a single session, GPT-6.1 Sol can hold a coherent research thread across days of computation without drifting off course — and for a 36-hour research task, "not drifting" is itself the hardest technical metric.

Third Moment Research's ten-thousand-agent autonomous research architecture: 10,000 concurrent agents → Codex harness (Docker containers) → outer harness (retry / terminate / escalate-to-human) → Daybreak automated penetration testing → self-improvement loop. Diagram adapted from the official customer story.

The second element worth a close look is their self-improvement loop. The method: use models to analyze agent behavior logs, identify recurring weaknesses, then automatically generate thousands of synthetic scenarios for targeted improvement — and repeat. This is not one-off tuning; it is a flywheel that keeps turning. One model researches the problem, another model researches how the model researches the problem, and the second one's output becomes the first one's next-round capability. The 36-hour sessions and the 10,000-agent scale make sense only with this loop in the picture: the system is not running statically, it is tutoring itself while it runs.

Third is the outer harness that guards against half-finished work. They run Codex as a subagent, wrapped in an outer harness driven by GPT-6 Sol and GPT-6.1 Sol that inspects incomplete execution trajectories and makes a three-way call: retry, terminate, or escalate to a human. Anyone who has run long tasks knows the real enemy is not insufficient capability — it is getting stuck midway, failing silently, or quietly delivering a half-baked result. This layer is, in effect, the project manager for the agents: its entire job is watching the jobs that never finished.

Fourth is the security design: they use the Daybreak platform for automated penetration testing, with one core question to answer — can an agent escape the research environment and reach the external network? Khakhar's point: without Daybreak, this kind of testing at scale and autonomously would not have been possible. Note the causal direction: when your agent count is 10,000 and sessions run for two days, traditional manual penetration testing cannot even get on the calendar. Security validation itself has to be automated and scaled, or you are flying blind. This is a new constraint that scaled operation imposes on security engineering — not a nice-to-have.

The most telling case study comes from a quantitative-finance scenario. After analyzing thousands of simulation trajectories, Codex pinned down a backtesting-pipeline bottleneck: a one-year, order-level backtest over US equities data took nearly 3 hours; agents waiting on the results kept polling the status, burning tokens for nothing and stuffing the polling logs into their context. Codex found two fixes — a caching optimization and memory packing — and backtest time fell from roughly 3 hours to 3–5 minutes.

One-year US equities order-level backtest: before ~3 hours, after 3–5 minutes (roughly 45–60x). The fixes were caching optimization plus memory packing — the biggest token waste often lives in pipeline design, not model capability.

The case's real weight lies in a counterintuitive truth it exposes: for long-session agents, the biggest token waste is not in reasoning — it is in waiting. Tokens burned by polling agents are pure loss, and the pollution lands in the context — which is fatal for "not drifting," the core metric. What Codex did was not "a smarter backtest" but "no waiting": the caching fix killed repeated computation, and memory packing spared waiting agents from endlessly asking "am I done yet?" In long-session engineering, performance optimization and reliability optimization are often the same thing.

Then there is their roadmap: expanding from single investigations to hundreds of thousands of collaborating subagents, token volumes in the trillions, and experiment chains of dozens of interdependent experiments. Co-founder Jeffrey Yan says GPT-6.1 Sol is the model the team uses most — the most token-efficient, with performance close to Astra. That sentence carries a lot: when scale reaches 10,000 agents and sessions stretch to two days, token efficiency becomes the number-one selection criterion; model choice shifts from "which is strongest" to "which is cheapest at acceptable quality." Inference cost has entered this story as an explicit variable for the first time.

Why it matters: the agent bottleneck moved from "can it run" to "can it run long and straight"

For the past year, agent progress has mostly been measured by "can a single task complete." The Third Moment story swaps in a different yardstick: how many run at once, how long one run lasts, and whether it stayed on track. 10,000 agents, 36–48 hours, no drift — the three numbers are really one statement: agents are turning from one-shot tools into continuously running labor. Tools are judged by single-run quality; labor is judged by sustained output and stability. Different standards entirely.

The second shift is philosophical, about engineering: the genuinely new thing in this story is not model capability but the harness. The outer unfinished-trajectory checks, the synthetic-scenario self-improvement loop, the automated Daybreak penetration tests — not one of the three is "a smarter model"; all three are "engineering that lets imperfect models run reliably." The secret of the 36-hour session is not in the prompt; it is in the engineering. That is a course correction for every team building long-session agents: instead of waiting for the next stronger model, build the harness now.

The third layer is the economics the backtest case reveals: token efficiency is becoming a hard constraint on agent scale. GPT-6.1 Sol is the "most used model" not because it is strongest but because it is the most token-efficient, with near-Astra quality. When Yan puts "cheapest" ahead of "strongest," agent economics moves from "quality first" to "value first." It is the same story as early cloud computing: first prove it runs, then squeeze the cost. The polling-tokens lesson from the backtest is the same class — at scale, wasted tokens get multiplied by 10,000.

A cooler head is needed on the fourth layer: this is an OpenAI customer story, a genre that is vendor marketing by construction. The numbers are backed by OpenAI's editorial process, but the genre only shows the success side: how many of the 10,000 agents did genuinely useful work, what the failure rate of 36-hour sessions is, where the budget for trillions of tokens comes from — none of that is said. Read it as directional evidence and it is excellent; read it as a replicable recipe and you will overreach.

Our take: facts and judgments, labeled separately

Analysis zone below — facts and judgments are labeled separately.

Judgment 1 (opinion): the real protagonist of this story is the harness, not Codex. The headline is "running 10,000 agents," but what makes the 36-hour session possible — outer trajectory checks, the synthetic-scenario self-improvement loop, automated penetration testing — is all harness engineering. The model is the fuel; the harness is the engine. The takeaway for readers: the entry ticket for long-session agents is on the engineering side, not the model side. Factual basis: the three layers and their roles are stated explicitly in the customer story — not interpretive reading.

Judgment 2 (opinion + fact): token efficiency is replacing "strongest model" as the selection standard for large-scale agents. Jeffrey Yan states plainly that GPT-6.1 Sol is the most-used model because it is the most token-efficient, with performance close to Astra (fact). That means at 10,000-agent scale, the steepness of the cost curve already outweighs the value of the quality gap (opinion). The signal to model vendors: the next competitive dimension may not be benchmark scores but "useful work per token."

Judgment 3 (opinion): the backtest case is a textbook sample of long-session engineering. It put three hidden costs on the table: waiting burns tokens, polling pollutes context, and pipeline design determines reliability. Many teams' long-session failures trace back to exactly these "engineering details," not the model. Codex's fixes (caching optimization, memory packing) are unglamorous; the number — 3 hours to 3–5 minutes — is glamorous. The first principle of long-session optimization may be: first make the agent not wait, then make it smarter.

Judgment 4 (opinion): security validation must keep pace with scale, or "autonomous research" is flying blind. Daybreak's automated penetration testing answers a question that is unavoidable at 10,000-agent scale: can an agent escape the sandbox? When sessions last two days and agents number in the tens of thousands, manual security review coverage converges to zero — security can only be automated, only be scaled. The logic holds for every team deploying agents at scale: the scalability of security engineering must be designed in lockstep with the scalability of the agents.

Judgment 5 (opinion): the customer-story genre dictates the reading posture — watch the direction, don't copy the homework. OpenAI's customer stories exist to showcase platform capability. Third Moment is a real user (the named, on-record founders add credibility), but "hundreds of thousands of subagents and trillions of tokens" is more roadmap than reality. The pragmatic move: copy the three-layer harness design and the token-efficiency-first selection, and treat the scale numbers as a 1–2-year reference point.

What remains unsaid

• Cost: not a word. What does 10,000 agents for 36–48 hours actually bill? How much does GPT-6.1 Sol's "most token-efficient" actually save? Without the cost numbers, the scale numbers lose weight — with an unlimited budget, anything runs.
• Infrastructure details are missing. Scheduling 10,000 agents, orchestrating Docker containers, checkpoint-and-recovery for 36-hour sessions — the most valuable engineering details are exactly what the customer story skips. Teams wanting to copy the homework will have to figure it out themselves.
• Failure rates are unsaid. The outer harness must choose among "retry / terminate / escalate to human," which tells you failure is routine. But the real failure rates per trajectory type, the human-escalation ratio, the convergence of retries — the numbers that decide whether the approach is replicable — are absent.
• The research output itself is never discussed. What did 36–48 hours of autonomous research actually produce? Genuinely usable research conclusions, or computation that merely looks busy? The output half of the input-output equation is entirely missing.
• The honest dating caveat. The official page carries no timestamp; October 14, 2026 comes from third-party cross-checking, not from an OpenAI publication date. That qualification should travel with any citation.

Related reading: OpenAI and the flood of 722 mathematics manuscripts — the same company's other face: that story was about data, this one is about infrastructure. Cursor SDK gives agents a steering wheel: background subagents you can steer mid-run — the other storyline in subagent collaboration: Cursor handles "steer mid-flight," Third Moment handles "finish the 36-hour run." groundcover launches agent-to-agent observability, MCP straight into production telemetry — for long-running agents, observability is the mandatory companion: a self-improvement loop that analyzes agent behavior is, at its core, one more use of observability.

In one sentence: the Third Moment story is not "the model got stronger again" — it is the engineering of "making the model run reliably for 36 hours": an outer harness, anti-abandonment checks, a synthetic-scenario self-improvement loop, automated security validation, and token-efficiency-first model selection, together forming the complete picture of ten-thousand-agent continuous research.