Nvidia Moves Down the Stack to Power OpenAI's Next AI Factory

Power Behind the AI Factory

Nvidia isn't merely supplying chips for OpenAI's next AI factory. It's helping secure the land, electricity and finance needed to make the facility possible.

Stay with this one, because the scale explains why the AI contest increasingly resembles an infrastructure contest. Nvidia has partnered with SB Energy at the PORTS-Pike campus in Ohio, where OpenAI is expected to operate an Nvidia-based AI factory. Nvidia says the initial deployment is planned to provide 4.25 gigawatts of capacity. Another 3.75 gigawatts is possible, although that second portion isn't committed.

Four-point-two-five gigawatts is an extraordinary amount of planned capacity for a single AI development. And it won't arrive quickly. Nvidia says the project will enter service in phases from 2028 through 2030, which leaves years of construction, financing and energy-market risk before the full initial deployment is operating.

The commercial commitments are as striking as the power figures. TechCrunch reports that Nvidia is investing $1.5 billion in SB Energy and will be the sole supplier of compute infrastructure for the project. It may also provide as much as $105 billion in credit. Nvidia describes its roughly 20-year support as covering defined portions of lease and power payments, along with a residual-value commitment. That doesn't mean Nvidia is simply writing one enormous cheque, but it does mean the company is putting its balance sheet behind selected long-term obligations.

Then there's the energy source. TechCrunch reports that SB Energy plans a 9.2-gigawatt natural-gas power plant at the site. That puts the physical cost of the AI build-out in plain view. These systems need chips, but they also need generation, transmission, cooling, buildings and reliable access to land. Securing those inputs years in advance is becoming part of the competitive strategy.

For OpenAI, the arrangement offers a path towards very large capacity while tying that capacity closely to Nvidia. The dependence now reaches beyond accelerators into the financing and physical infrastructure that will host them. For Nvidia, the upside is deeper control of demand across the whole stack. The risk is deeper exposure too: construction delays, changing energy prices and a huge concentration of commitments around one major customer and its partners.

My read is that Nvidia is turning scarcity itself into a moat. If electricity, suitable sites and long-term finance are the constraints, helping customers secure all three makes its chips harder to displace. But none of the announced numbers should be treated as operating capacity yet. The optional expansion may never happen, costs can move, and the earliest phases are still two years away.

Groq Joins the Nvidia Cloud

That factory deal shows Nvidia reaching well beyond the chip tray. Groq's latest pivot makes the same point from the other direction.

Groq announced a $350 million funding round at a $3.5 billion valuation to expand its AI inference cloud. The round was led by Disruptive, with Nvidia expected to participate, and remains subject to customary closing conditions. Groq says it now operates 13 data centres, serves more than six million developers and plans to lift capacity from 54 megawatts to more than 200 megawatts during 2027.

Those are company-reported figures, and Groq hasn't demonstrated that the expanded cloud can be profitable over the long term. Still, the strategic change is notable. Groq originally built its profile around its proprietary Language Processing Unit, or LPU, as an alternative to Nvidia hardware for running trained AI models. TechCrunch reports that Groq now operates Nvidia systems after Nvidia licensed Groq's technology and hired founder Jonathan Ross and other senior personnel.

So one of the better-known challengers to Nvidia's inference silicon is becoming an Nvidia-powered neocloud: a specialised cloud operator focused on supplying AI compute. Customers may benefit if the funding translates into more available capacity and broader deployment. But the market loses some of the competitive pressure that came from Groq trying to establish an independent chip platform.

The useful lesson for infrastructure companies is that differentiated silicon isn't enough by itself. A chip needs capital, data-centre space, software support, customers and enough deployed capacity to serve them reliably. Groq's decision suggests those surrounding advantages can outweigh ownership of the processor design.

My assessment is that this strengthens Nvidia in two ways. It brings another cloud supplier into Nvidia's hardware ecosystem, and it shows prospective challengers how hard it is to finance a genuinely independent alternative. Groq may grow faster as a service business, but its expansion now reinforces the platform it once set out to challenge.

Stripe and the Model Gateway

Control over AI infrastructure can also sit in software, especially at the point where developers choose and pay for models.

TechCrunch, citing Bloomberg, reports that Stripe has finalised an agreement to acquire OpenRouter for more than $7 billion. Neither Stripe nor OpenRouter has confirmed the transaction. A Stripe spokesperson said the company doesn't comment on rumours or speculation, so this remains a reported deal rather than an announced change in ownership.

OpenRouter provides one interface through which developers can access models from many different suppliers. The company says it serves eight million users and offers a single access point to more than 400 models. That makes it useful for teams that want to compare providers, switch models or route different tasks without building a separate commercial and technical integration for each one.

The reported price is more than five times OpenRouter's reported $1.3 billion valuation from a funding round in May. That premium makes more sense if the asset isn't viewed merely as an API wrapper. A gateway can see which models customers select, how demand moves between providers and where spending accumulates. Pair that routing position with Stripe's expertise in metering and payments, and there is a plausible path towards simpler billing for AI applications.

There is no product, pricing or contract change to act on yet. Even so, organisations using OpenRouter as a model-neutral layer should pay attention to the incentives that could follow a sale. A gateway owned by a major payments company might make usage charging easier, while also concentrating routing, billing and valuable demand data under one commercial owner.

For developers, my practical judgement is to preserve the ability to move. That doesn't mean abandoning OpenRouter on an unconfirmed report. It means keeping model identifiers, routing logic and billing assumptions sufficiently visible that a future ownership or policy change doesn't become an emergency rewrite. The attraction of a neutral gateway is optionality; customers should check that their own architecture still protects it.

Rare Books Become Training Supply

The hunt for training material is reaching far beyond the public web, and some of the source material isn't surviving the trip.

An investigation reported by TechCrunch tracked a rare book to Amazon's VGT3 facility in Las Vegas. A tracking device had been placed inside the book, allowing its journey to be followed. At the facility, Amazon was reportedly buying rare texts, removing their spines and scanning the pages for AI training.

Amazon said it purchases books through commercial channels to improve products and services for customers. It didn't provide a comprehensive list of the titles acquired, identify the particular models trained on the scans or disclose the full size of the programme. Those missing details make it difficult to judge how systematic the operation is.

The attraction of these books is understandable from a model developer's perspective. Out-of-print and less commonly digitised works can contain text that isn't already circulating through familiar online datasets. That may make the material valuable as developers search for sources that haven't been repeatedly copied, summarised or contaminated by machine-generated text.

But destructive scanning imposes a preservation cost. Removing a spine can turn a scarce physical book into raw input for a dataset while eliminating the original object. A digital scan may preserve the words, but it doesn't necessarily preserve bindings, annotations, paper, printing characteristics or the documented ownership history that researchers can value.

This creates a new provenance problem for libraries, booksellers and AI companies. Records need to show what was acquired, whether another copy exists, how the scan was produced, what rights attach to it and whether the physical source survived. Without that trail, valuable historical material can disappear into a training pipeline with little public visibility.

My view is that rare texts are becoming supply-chain assets for AI, and organisations holding them should price preservation into any deal. Digitisation can broaden access, but a model-training programme shouldn't quietly treat an irreplaceable object as disposable feedstock. The unresolved issue here isn't whether Amazon scanned one tracked book; it's how many other works went through the same process and where their text ultimately ended up.

Evidence Under Scrutiny

A different kind of provenance problem has surfaced in Australia, this time inside evidence used to support public policy.

A Senate inquiry heard concerns about apparent fabricated or incorrect references in an age-assurance report that helped support Australia's ban on social-media access for children under 16. Guardian Australia identified six problematic references in one section, including Digital Object Identifiers that appeared not to exist, incorrect identifiers and papers that didn't support the claims attributed to them.

The report emerged from a $3.48 million trial, and the communications minister had cited it as evidence that effective age-checking options existed. That gives the citation failures more weight than an ordinary editing mistake. The work helped inform a consequential policy debate involving children, privacy, technology platforms and age-verification systems.

The report's authors acknowledged using ChatGPT to edit text, but denied that AI generated the citations. The department is examining the concerns and said it hadn't independently verified the contractor's explanation that some links subsequently broke. A broken link also wouldn't, by itself, explain a nonexistent DOI or a real paper being used to support a claim it doesn't make.

It's important not to jump past the evidence. The causal role of ChatGPT hasn't been established. Bad references existed before generative AI, and human researchers can miscite sources without a model's involvement. The confirmed problem is the failure of the evidence-assurance process, regardless of which tool introduced the errors.

For government departments, the consequence is straightforward: human sign-off isn't a sufficient control when a report can influence legislation or regulation. Contracts for AI-assisted research need explicit citation verification, retained source records and a reproducible trail from each material claim to the evidence supporting it. Spot checks should resolve identifiers and confirm that a paper actually says what the report claims.

My assessment is that agencies should treat reference integrity as a testable deliverable, not a formatting detail. AI tools can make drafting faster, but they also make polished, confident prose cheaper to produce. That raises the value of verification. When evidence enters the policy process, a citation needs to function as proof, not decoration.

Imagen Endpoint Deadline

Sometimes the risk is less dramatic than a disputed policy report: an unchanged application simply reaches the end of a provider's calendar.

Google's published Gemini API lifecycle schedule set August 17 as the shutdown date for three Imagen 4 image-generation endpoints. The affected model IDs are imagen-4.0-generate-001, imagen-4.0-ultra-generate-001 and imagen-4.0-fast-generate-001. Google announced the retirement on June 15 and directs developers towards newer stable or preview endpoints.

The lifecycle notice establishes the support deadline. It doesn't independently confirm whether every retired endpoint stopped responding at the same moment after that date, so the safe conclusion is that integrations still using those IDs are now beyond Google's stated support window. They may fail, behave inconsistently or remain temporarily reachable without any support guarantee.

Migration isn't necessarily a one-line substitution. Google's changelog doesn't promise identical behaviour, pricing or stability across every replacement. Teams may need to compare output quality, latency, safety settings, regional availability and cost before promoting a new endpoint into production. Preview models also carry a different stability expectation from stable ones.

This is easy to dismiss as routine API maintenance, but model endpoints are becoming operational dependencies in design tools, publishing systems and customer-facing products. A provider can retire the model while the surrounding application code remains untouched. Without a current inventory, the first lifecycle alert may arrive as a failed job reported by a user.

For developers, the worthwhile practice is to track model IDs as managed dependencies, alongside libraries and external services. Record which product calls each endpoint, assign an owner and test the replacement before the deadline. My read is that lifecycle management is now part of basic AI reliability. The model choice may feel experimental during development, but once it sits in a production workflow, its retirement date belongs in the operating calendar.

Hardware Wallet Data Exposure

Keeping crypto keys offline solves one security problem. It doesn't stop a shipping database from identifying who may own valuable assets.

Trezor and SafePal have separately disclosed incidents exposing customer contact, address and order information. Both companies say wallet credentials and devices were not compromised, and neither incident exposed seed phrases or private keys.

Trezor says a breach at shipping provider ShipMonk fully exposed information belonging to 11,742 customers and partially exposed records for another 1,947. Its investigation into some older partial records remains open. SafePal says an authorisation flaw in an order-tracking system exposed information associated with approximately 39,798 customers.

The immediate danger is targeted social engineering. An attacker who knows a person's name, address and hardware-wallet purchase can make an email, phone call, letter or delivery appear unusually convincing. They can impersonate the manufacturer, refer to a real order and manufacture urgency around a supposed security problem. The aim will often be to obtain a seed phrase, persuade the owner to install malicious software or direct them to a fraudulent support site.

Affected customers don't need to move funds solely because order information was exposed. Moving assets in a panic can create fresh risk, especially if the instruction came from someone exploiting the breach. The useful response is to distrust unsolicited contact that refers to the purchase and verify any notice through the vendor's independently reached official channels.

For wallet companies, my takeaway is that security claims have to cover the retail supply chain as well as the device. Strong key isolation remains valuable, but fulfilment data can identify people worth targeting and may reveal where a device was delivered. Minimising retained order data, constraining third-party access and testing authorisation boundaries are part of protecting customers.

Both investigations, or their external reviews, remain in progress, so the disclosed scope could change. What is already clear is that offline custody doesn't equal anonymity. The cryptography can hold while the surrounding customer record becomes the attacker's map.

What Changes for You

One deadline deserves immediate attention if Relay sits anywhere in your working automation stack.

Relay's free service closed on August 15, and the company said data associated with free accounts would be permanently deleted after that date. Paying customers retain access until September 14. After that cutoff, their accounts and any data they haven't exported are also scheduled for deletion.

Relay is an AI automation service used to assemble workflows across models, applications and business processes. TechCrunch reports that founder Jacob Bank and other Relay staff are joining Google's Chrome team. Neither company has explained how those hires may shape Chrome's AI roadmap, so there's no basis for assuming Relay workflows will reappear inside a Google product.

Paying users can export workflows, sequences and MCP servers as JSON and prompts. Relay also provides exports for run histories and tables. The practical change is that customers have a shrinking window to preserve both the automation logic and the operating records around it. An export is only the first step: integrations, credentials, triggers and provider-specific behaviour may still need to be recreated elsewhere.

If a Relay process is business-critical, export it now, document what starts it and test a replacement before September 14. The relevant limitation is portability. JSON and prompt files preserve useful structure, but they don't guarantee that another automation service will execute the workflow identically or support every connector.

My judgement is that the shutdown exposes a design risk common to agentic tools. A clever workflow can become operational infrastructure long before anyone creates a recovery plan. Builders should keep portable copies of prompts and workflow definitions, but also record external dependencies and expected outputs. When the service disappears, the hard part isn't remembering what the agent said; it's reconstructing everything that allowed it to act.