Third Moment Research reported one trillion OpenAI tokens consumed in a single day. That figure gives some indication of the computational scale involved in operating thousands of research agents, but it says relatively little about the efficiency of the work being performed.
A more revealing detail appears elsewhere in OpenAI's case study.
Third Moment was running trading simulations against a year of order-level US equity data. Each backtest took approximately three hours. While the simulations were executing, agents repeatedly checked whether the results were available, consuming tokens and adding status messages to their context.
Codex examined thousands of recorded trajectories, timestamps, and the underlying codebase. It identified caching and memory-packing optimizations and deployed a change that reduced the backtest runtime to approximately three to five minutes.
The resulting improvement was not a new reasoning technique. It was an optimization of the software that the reasoning system depended on.
Why tool latency affects agent economics
An autonomous agent typically alternates between model inference and tool execution.
The model interprets the current state, decides what to do, invokes a tool, receives the result, and then determines the next action.
This arrangement works well when tool operations finish quickly. It becomes less efficient when a tool launches a job that requires several minutes or hours.
If the agent remains inside a loop repeatedly checking whether the job has completed, the reasoning system is effectively being used as a polling mechanism.
Traditional applications generally delegate this responsibility to a scheduler, event loop, or background worker. There is rarely a need to invoke a language model to interpret the message that a job is still running.
Yet agent implementations can accidentally make routine orchestration part of the model's reasoning loop.
The cost extends beyond the tokens used in individual checks. Repeated tool responses may also enter the context of subsequent model requests, increasing the amount of information the model must process.
This is the context pollution described in Third Moment's case study.
What did the backtest optimization achieve?
The reported reduction from 180 minutes to three to five minutes corresponds to approximately 36–60 times faster execution.
The comparison below uses the bounds reported by Third Moment.
Figure 4: Backtest runtime before and after optimization
xychart-beta
title "Backtest runtime (minutes)"
x-axis ["Before", "After: 5 min", "After: 3 min"]
y-axis "Runtime in minutes" 0 --> 180
bar [180, 5, 3]
Source: OpenAI's October 14, 2026 case study. The after-values represent the reported runtime range, not two separate benchmark runs.
The immediate benefit is fewer minutes spent executing each backtest. However, the more important improvement for an autonomous research system is increased experimental throughput.
Suppose a research investigation has a fixed 24-hour compute window and runs simulations sequentially. A three-hour backtest permits, at most, eight such runs during that period, ignoring other work. A five-minute backtest permits up to 288 runs under the same simplified assumptions.
That is not a prediction of Third Moment's actual experimental throughput. Agents also spend time generating code, evaluating results, training models, and waiting for other resources. But it illustrates why optimizing a common computational bottleneck can have effects far beyond one tool invocation.
How expensive can polling become?
Consider a hypothetical deployment of 10,000 agents, each waiting for an external operation and checking its status every 30 seconds.
The fleet would generate:
| Measurement | Illustrative value |
|---|---|
| Concurrent waiting agents | 10,000 |
| Polling interval | 30 seconds |
| Status checks per minute | 20,000 |
| Status checks per hour | 1,200,000 |
| Status checks over 24 hours | 28,800,000 |
This is a hypothetical workload, not a measurement of Third Moment's system.
If each polling interaction generated additional model usage, the resulting overhead could become substantial. The exact token cost would depend on the implementation, how context is managed, whether model inference occurs for every check, and how tool results are represented.
A particularly inefficient implementation might ask the model to interpret each status response. A better implementation would let software handle the waiting.
Replacing model-driven polling with event-driven execution
For long-running tool operations, the orchestration system can submit a job and suspend the agent's execution branch until the job produces a terminal event.
The agent receives a durable job identifier. The execution service monitors progress and stores the result when the operation completes. The agent is resumed with a reference to the completed artifact.
Figure 5: Polling versus event-driven execution
flowchart TB
subgraph POLLING["Model-Driven Polling"]
A["Agent"] --> B["Check Job Status"]
B --> C{"Complete?"}
C -->|"No"| A
C -->|"Yes"| D["Process Result"]
end
subgraph EVENT["Event-Driven Execution"]
E["Agent Submits Job"] --> F["Execution Service"]
F --> G["Agent Suspended"]
F --> H["Job Completes"]
H --> I["Completion Event"]
I --> J["Resume Agent"]
end
This approach is not free of reliability concerns. Completion events may be delayed, duplicated, or lost. The system must maintain durable job status, detect stalled operations, and support reconciliation after failures.
Nevertheless, these problems can be handled through conventional execution infrastructure rather than repeated language-model inference.
The difference between token efficiency and research efficiency
Third Moment uses multiple models for different workloads. Co-founder Jeffrey Yan reports that GPT-6.1 Sol has become the company's most frequently used model because it delivers similar performance to GPT-6 Astra on their workloads while consuming fewer tokens.
That distinction matters because model selection should be evaluated against the entire workflow, not only the cost of individual tokens.
A smaller model might require fewer tokens per decision but make more mistakes, generate unnecessary experiments, or require additional validation. Conversely, a more expensive model might produce a correct result with fewer tool calls and less wasted computation.
For autonomous research, a useful efficiency measure would incorporate all costs associated with producing a validated result:
Cost per validated result = (inference + compute + tool + recovery costs) ÷ number of independently validated results.
The denominator matters. A system producing twice as many experiments but no additional valid findings has improved throughput without improving research productivity.
The same distinction applies to latency. A model that reaches an answer quickly may still produce a poor result if its output fails subsequent evaluation.
What engineering teams should monitor
Instead of monitoring only total token expenditure, an agent platform should be able to associate consumption with individual investigations and their outcomes.
Several measurements are particularly useful:
- Tokens per accepted result: How much inference was required to produce a validated outcome?
- Tool wait time: What proportion of an investigation was spent waiting for external computation?
- Retry amplification: How much additional work was caused by failed operations?
- Experiment throughput: How many meaningful experiments completed within a fixed research window?
- Context overhead: How much model input consisted of administrative messages rather than research-relevant information?
Together, these measures help distinguish genuine research activity from expensive execution overhead.
Third Moment's backtesting optimization demonstrates why these distinctions matter. The company achieved a substantial improvement by investigating the computational environment rather than changing the fundamental objective of the agents.
As autonomous workloads grow, some of the most valuable performance improvements may come from conventional software engineering: faster algorithms, better caching, asynchronous execution, durable job management, and eliminating unnecessary work.
Sources: OpenAI — Third Moment Research · Temporal — Tasks
Related: Inside Third Moment's Architecture | How Agents Maintain State for 48 Hours