Should AI Really Slow Down?

By Blair Little

Tech Enthusiast | Innovator | Embracing the Digital Frontier for a Connected Future

More useful work from each watt and each model, with stronger evidence that people remain in control.

The AI race has rewarded speed. Train the next model, raise the benchmark and ship before a competitor does. But speed is a poor measure of progress if the systems being built become harder to understand and control.

On 18 August, OpenAI said it had temporarily slowed scaling, including a two-week pause in reinforcement learning training on its latest models intended for deployment. At the time of that announcement, its largest planned frontier reinforcement learning run remained on hold. The company linked the changes to security concerns and preliminary evidence that Astra might reach its Critical cybersecurity capability threshold. That is a dated account of the pause, not a claim that the same runs are still paused today. OpenAI's development update

There is a serious safety question here. There is also an engineering question: should we concentrate so heavily on making the next model more powerful when we could do much more with the intelligence already available?

A pause needs a purpose

A temporary pause can be sensible when a specific experiment or deployment exceeds the safeguards around it. It creates time to investigate failures, improve evaluations and restrict what a system can reach.

OpenAI's August account described work on monitoring, alignment and stronger isolation of research workloads. Those are concrete changes to the conditions under which development proceeds. OpenAI's safeguards

The useful question is what evidence would make restarting acceptable. A pause with clear tests and independent scrutiny can reduce risk. An indefinite call to slow everything, without a measurable objective, is much harder to assess.

Better hardware cannot answer that safety question on its own. A cheaper, faster system can still take an unauthorised action. Efficiency and control need to improve together.

What does Altman stand to gain?

It is reasonable to examine the incentives of Sam Altman and OpenAI. It is not reasonable to present a hidden motive as an established fact without evidence.

OpenAI has publicly set out a strategy connecting data centres, chips, models and products. In August, chief financial officer Sarah Friar described those investments as mutually reinforcing parts of the business. OpenAI's compute strategy

The scale of its infrastructure ambition is also public. The January 2025 Stargate announcement outlined an intention to invest $500 billion over four years in US AI infrastructure. That was a programme commitment, not proof that the money had already been spent or the capacity built. Stargate announcement

My concern is the competitive effect of how safety rules are designed. Expensive fixed requirements for auditing, reporting and evaluations could be easier for a large incumbent to absorb than a small laboratory. A slowdown could also give a well-funded company time to improve the infrastructure beneath its existing products.

Those are plausible benefits, not evidence that Altman's safety concerns are insincere. Clear rules could also constrain OpenAI, impose costs on it and protect smaller companies from pressure to take dangerous shortcuts.

The test should be practical: are requirements proportional to demonstrated risk? Can smaller researchers access evaluation facilities? Are findings independently checked? Would the same rules apply to the company proposing them?

Build better below the model

There is plenty of useful work that does not depend on pushing the next frontier capability threshold.

Improve memory use. Reduce unnecessary data movement. Make inference, the process of running a trained model, more efficient. Route simple jobs to smaller models. Improve cooling, scheduling and the reliability of the systems people already use.

OpenAI is pursuing some of this itself. Its August Jalapeño report described measured inference performance and efficiency results, while saying deployment within its infrastructure was planned to begin by the end of 2026. Those are company-reported benchmark results and a deployment plan, rather than proof of savings across every production workload. Jalapeño results

For a business, useful progress could mean the same task completed reliably with less electricity, less waiting and fewer failed attempts. The relevant measure is cost and energy per successful task at an acceptable quality level, not a token-speed headline in isolation.

Efficiency also has a catch: cheaper computing can encourage more use. Better performance per watt does not guarantee lower total electricity demand.

Could idle PCs contribute?

The idea has a credible scientific precedent. Folding@home lets people contribute computing resources to research, including work on cancer and other diseases. BOINC provides infrastructure for volunteer computing across varied, unreliable devices. Folding@home, BOINC research

An AI equivalent might run approved jobs on a participating computer while its owner is away. The owner would choose when it runs and set power, temperature, bandwidth and storage limits. This is a proposed design, not a product announcement.

But an idle GPU is not free computing. It still consumes electricity under load, produces heat and has limited memory. The network also needs scheduling, storage, verification and someone responsible for its operation.

The right starting point is a workload that can be split into useful, independently checkable pieces.

Training is the difficult case

Conventional large-model training depends on frequent communication between tightly connected accelerators. A collection of home computers connected through the public internet has very different latency, bandwidth and availability constraints. DiLoCo research

That does not make distributed training impossible. DiLoCo investigates training across groups of devices with much less communication. Its research results support exploring alternative architectures; they do not establish that a worldwide network of untrusted gaming PCs can replace a frontier training cluster.

More promising early candidates include public-data processing, independent simulations, batch inference with openly distributable models and some evaluation jobs. Each candidate still needs checks for memory requirements, licensing, confidentiality and whether validating the answer costs less than doing the job centrally.

Interactive services are harder when users expect a fast response and volunteer machines can disappear. Safety testing of highly capable proprietary models is also a poor default for a public network: distributing the model may expose precisely the capabilities and assets that need protection.

Security runs in both directions

A volunteer network has to protect the computer owner from the job and protect the project from the computer owner.

On the participant side, a defensible pilot would use signed software and updates, minimal permissions, isolated execution and explicit resource controls. Jobs should have no routine access to personal files, credentials or the local network. There must be an immediate stop control.

On the project side, assume that a host can inspect what it receives and return a fabricated result. Start with public data and models licensed for redistribution. Use reference tasks, sampled recomputation and redundant checks where those checks are meaningful.

These are design recommendations, not a claim that one security mechanism makes the network trustworthy. A signature can authenticate a job without proving it is harmless. A container can restrict a job without hiding model weights from the machine's administrator. Encryption in transit does not conceal information while that host is processing it.

Reputation can help scheduling, but participants can create multiple identities or cooperate to fool a validator. Trusted hardware may help particular workloads; its protections and deployment constraints must be tested. Neither fragmentation nor a good reputation should be treated as a confidentiality guarantee.

Prove the economics before scaling

A useful pilot would compare a volunteer network with a central service on the same public workload and quality target. Measure completed, verified tasks; total electricity; network traffic; failure rates; turnaround time; and operator effort.

Include the cost of duplicated work, retries and coordination. Count participants' energy use rather than making it disappear from the accounting because someone else pays the bill.

Reusing existing equipment could reduce the need for some new hardware. Whether it lowers emissions or total cost depends on utilisation, hardware efficiency, local electricity and the workload. The result could be positive, but it needs measurement.

So should AI slow down?

Yes, when the next step exceeds the evidence that it can be carried out safely. The pause should target the risky activity and have clear conditions for review.

Meanwhile, keep improving evaluations, security, chips, memory systems and data centre efficiency. Test distributed computing where the work and trust requirements fit. Make existing AI more reliable and useful.

OpenAI's infrastructure ambitions deserve scrutiny alongside its safety arguments. Neither commercial incentives nor genuine technical concerns should be waved away.

The better ambition is simple: more useful work from each watt and each model, with stronger evidence that people remain in control.

References

OpenAI: Pacing model development
OpenAI: The full stack behind abundant intelligence
OpenAI and SoftBank: Stargate
OpenAI: Jalapeño first results
Folding@home: Diseases we study
David P. Anderson: BOINC
Douillard et al.: DiLoCo