"Ten thousand agents working simultaneously" is easy to make a news headline, but what truly drives down costs might be the reduction of a backtest from about three hours to just three to five minutes. The Third Moment Research case released on October 14th by OpenAI demonstrates how this startup uses models to run research tasks that last 36 to 48 hours with Codex. The article reveals the scale of the project, a specific performance optimization, and future expansion plans; however, this does not mean that independent external audits have proven that all its agents can independently produce reliable research conclusions. Viewing it as an engineering case presented jointly by the vendor and the client allows us to see new progress while also maintaining necessary skepticism.

The goal of Third Moment is to create a system that learns from work trajectories: it records the actions taken by agents and the weaknesses they encounter, then automatically constructs a large number of synthetic scenarios for retesting and improvement. OpenAI states that GPT-6, Astra, GPT-6, Sol, GPT-6.1, Sol, and Codex are involved in supporting this research and computation; the company can run ten thousand agents concurrently during an investigation that lasts 36 to 48 hours. This number indicates the scale of the experiment, but it does not alone answer questions about the success rate, the amount of manual review, or the total cost per run. Replacing project evaluation indicators with "tens of thousands of agents" actually obscures the most valuable details.

The bottleneck in the project is not that the model can't think, but that the system is always waiting.

The most specific parts of the case come from quantitative research backtesting. One application of Third Moment uses order-level data for US stocks; originally, backtesting a strategy for one year would take several hours. During the waiting period, the agent continuously checked whether the task was completed, repeatedly consuming tokens and filling the work context with status information that had no analytical value. Codex is said to have examined a large number of simulated trajectories, timestamps, and code libraries to identify opportunities for caching and memory optimization. After implementing these optimizations, the time required for a single backtest was reduced from about three hours to around three to five minutes. The report summarizes this as a 97% reduction in backtesting time, but readers should remember that these numbers are specific to this particular workload and do not represent an average improvement that can be achieved by all quantitative systems or all companies.

Why would such savings affect agent systems? In traditional software, slow queries cause users to wait; however, in long-running agents, slow queries may lead to continuous tool calls during the waiting period, resulting in repeated readings of the same state and even the accumulation of incorrect inferences within the context. The faster the backtesting, the more hypotheses can be tested within the same budget, and the less likely the research process will be interrupted by unnecessary waits. The key technical aspect here is not to have language models "intuitively" replace backtesting, but to use them to understand the experimental process, and then to improve the verifiable steps through conventional engineering optimizations.

Of course, caching can also introduce new risks. If historical data is updated, model parameters are changed, or the backtesting logic is revised without being properly invalidated, the increased speed may come with outdated results. There are no publicly available complete benchmark tests, caching invalidation rules, or independent replication experiments for this case. Therefore, the most cautious statement would be: OpenAI reveals that Third Moment achieved significant speed improvements in an internal scenario; if institutions copy this approach, they should first fix the data version, verify the results, and establish rollback conditions. While the speed figures are impressive, whether the strategy is truly robust still needs to be proven separately.

The more agents there are, the less the audit responsibility can be diluted.

OpenAI also mentioned that these intelligent entities will operate continuously for dozens of hours and use Daybreak to test the security of the running environment. Systems that run for a long time not only face model errors but also encounter issues such as tool permissions, data leaks, mutual interference, and drift in task objectives. When the scale increases from ten to ten thousand entities, the small probability of a single entity making an error can turn into frequent operational and maintenance incidents. To evaluate such systems, it is necessary to clearly understand what each type of entity can access, whether they can submit code or financial instructions, who approves irreversible actions, and how failures can be traced back to specific trajectories.

The case mentions a consumption of one trillion OpenAI tokens per day. This amount is disclosed in that particular customer case and should not be interpreted as the norm in the industry, nor can it be directly converted into profitability. Tokens are merely an investment; what is truly worth calculating is how much cost was incurred for each research conclusion that required manual review, how much time of professional personnel was saved, and what losses were caused by incorrect results. Some tasks are suitable for highly parallel searches and experiments, while others are limited by data quality, regulations, or human judgment, and will not be automatically completed just because of increased concurrency.

Third Moment plans to grow to hundreds of thousands of collaborative sub-agents in the future, capable of handling longer chains of dependent experiments. This is a roadmap, not the production scale that has already been implemented with this release. Instead of guessing the next round of numbers, it's better to focus on three verifiable indicators: whether the success rate of the same task improves under the old and new processes, whether engineering accelerations can be reproduced across different datasets, and whether manual reviews can keep up with the output speed. Without these benchmarks, "self-improvement" may easily become just the system scoring itself.

For business readers, this case provides a practical lesson: before deploying agents, identify the most costly aspects of the workflow, such as waiting times, repetitive readings, and data transfer. Only after addressing these issues can more resources be allocated to valuable decision-making processes. What OpenAI presents is the observable practices and statements of one client; it is not yet an acceptance report for a general solution. Whether ten thousand agents can truly improve research quality depends not on the number of concurrent tasks, but rather on reproducible results, clear accountability chains, and effective exit mechanisms.

There is another boundary that is easily overlooked: faster backtesting in quantitative research does not equate to improved returns on investment strategies. Faster experimentation may even lead teams to repeat tests until results that seem excellent but are actually overfitting are obtained. If this process is to be applied to real funds, out-of-sample validation, transaction costs, market shocks, and risk limits should still be included in the assessment, and it must be clear when a human decision is needed to stop the experiment. Engineering efficiency can increase the throughput of research, but it cannot take on the responsibility of judgment for researchers.