Whether driven by a desire for transparency or to keep OpenAI from hogging the spotlight when it comes to advertising advanced AI models, Anthropic revealed that Claude also hacked into three production systems belonging to unsuspecting targets during cybersecurity capabilities testing. Two of the affected companies didn't know they had been hacked, while a third one is unreachable.

The alleged incidents reportedly happened during the previous quarter and involved several versions of Claude: Opus 4.7, Mythos 5, and "an internal research test model." Similar to what happened when OpenAI Sol hacked into Hugging Face, Anthropic was running Claude through cybersecurity capture-the-flag scenarios where the bot was told to find a piece of information somewhere in its network. Anthropic says there were 141,006 test runs, and the three incidents occurred over six problematic runs. As expected, the tests ran with most AI safeguards disabled.

The problem is, the network was not isolated, a newbie mistake that some might even find suspicious. This was due to an alleged "miscommunication" between Anthropic’s virtual test lab firm Irregular, which gave the bots full access to the internet. For safety's sake, the Claudes were apparently told they were in an isolated environment, which didn't help much.

The first time, Claude Opus 4.7 had to find a piece of data belonging to an imaginary company. As it turns out, there was actually a real company whose website domain matched the fake one. With internet access, it gained application and infrastructure credentials and grabbed "several hundred rows" of data from a production database.

For two out of four runs where hacking took place, Claude didn't see any problem and "rationalized that the real company must be part of the exercise," but soldiered on. The other two times, it just kept going. Anthropic notes this was the only case of the three where the bot continued to operate after the realization the company actually existed for the aforementioned reason. However, the firm's interpretation is open to discussion.

The second, and potentially more interesting, was a bona fide supply-chain attack, this time perpetrated by Mythos. The fake data available to the bot included an installation script for a hypothetical developer that included installing Python packages. Much like a human would, Claude noticed the obvious attack vector and, once again, due to having internet access, inferred that publishing a booby-trapped package in the PyPI repository would do the trick. Unfortunately, it was the real one that the whole world uses.

In speedrun form for brevity: Claude needed a PyPI account, meaning it needed an email and a phone number. It tried buying one but found itself short of both pockets and funds; but it found another free email provider without that requirement, registered the PyPI account, and uploaded a malware package to PyPI. The package was seemingly only up for one hour but was downloaded and run on 15 systems.

In a twist of irony, one such system belonged to a security vendor that scans PyPI for malware, and lo and behold, promptly failed to find Claude's booby-trap and ran it. Once Claude presumably had remote code execution privileges, it used the credentials it found for further infiltration. The amusing bit is that Claude had no idea this company existed and didn't target it; the downloads just happened because the package was up and live for a short while.

According to Anthropic, the bot did detect it was acting on the real internet and even said that publishing a package like this was "NOT okay." However, it talked itself into believing it was in a test environment as it didn't recognize the real SSL certificates for the connections. It even believed the 2026 calendar date on the systems "proved" the environment was staged. It even recognized the systems that installed the malware as part of the experiment.

As for the third incident, Anthropic isn't saying much, other than Claude scanned 9,000 real live potential alternative targets once it noticed the intended one wasn't reachable. One of them reportedly had a live page with debugging information and was vulnerable to plain ol' SQL injection. Interestingly, this time around, once Claude noticed that the servers it was accessing resided on a cloud environment and not on the local network, it stopped the attack.

For its part, Anthropic recognizes that despite Claude following the instructions for the objectives, the fact that it stopped by itself once it found the target was real in only one of the cases is food for some thought. The firm says it's talking to METR for a third-party review, and it needs to "better co-design evaluation environments."

Oddly enough, Anthropic believes Claude probably wouldn't have gone online "if the prompt had clearly explained which systems were in and out of scope for the evaluation," while also stating the incidents were "closer to a harness and operational failure than a model alignment failure."

Unless you’ve been living under a rock, OpenClaw has dominated headlines, both good and bad, for much of early 2026. Developed by Peter Steinberger, the tool is an engine that spins up an AI agent that can autonomously act on your behalf, going so far as having the ability to run files, browse the web, and much more. Using a system named “Skills,” you can even teach your AI assistant to perform new tasks, with more integrations popping up daily. But how useful is it for the average person? I took it upon myself to answer that question by using the relatively humble Beelink SER10 MAX mini PC, which comes pre-installed with OpenClaw, to find out.

To kick things off, when setting up your OpenClaw installation, there’s a fairly large decision one has to make: Do you want to rely on Cloud resources and more powerful AI models, or run something locally? Beelink’s SER10 MAX ships with Qwen-3.5 9B, which is a relatively older and more outdated AI model. Since I want to keep things fairly simple, I opted for the local AI route first. To run larger models, you’ll need a lot of memory, so I first tweaked the humble Mini PC’s video memory up to 48GB, which should allow us to keep a larger, more complex model in memory. It also leaves us 16GB of system memory to play around with, which should be more than enough to run the terminal and ensure that everything else works as intended.

Selecting the ideal local AI model

Having 48GB of available video memory should allow us to run a fairly powerful AI model on the system. However, the downside of running a larger model is that token speeds are likely to be slightly lower than expected. However, for running the super-smart AI that does things for us locally, we want as much intelligence as we can get. For this exercise, I chose Google Gemma 4 31B (UD-Q8_K_XL), a near-lossless quantization, somewhat ambitiously, as I will learn shortly.

After downloading the model and running it in llama.cpp, we managed to attain 2.34 tok/s. On average, everyday queries took 116 tokens to generate, at 2.34 tok/s. That’s still too slow for fast everyday use. So, I took a deep breath and conceded that the humble Ryzen AI 9 HX 470 didn’t have fast enough memory or memory bandwidth to run such a large model at acceptable token speeds. Even if I had dropped the quantization to 4-bit, we’re still looking at the theoretical maximum of around 5 tok/s for that model in particular. If you had a faster machine with rapid RAM speeds, such as a Strix Halo system like the Framework Desktop, it might be more workable, but for a lower-end piece of silicon with relatively humble DDR5-5600 speeds, you’ll just have to accept a slightly more neutered model.

So, I eventually conceded that the smaller Gemma 12B (Q4_K_M) was a much more sensible choice for a device of this caliber. After loading things up into llama.cpp, we managed to get a much more sensible 10.64 tok/s on a general knowledge query: “What is Tom’s Hardware?” Now that I have a little piece of talking electrified sand on my desk, it’s time to configure OpenClaw.

Hatching HammerClaw

The device I am using, the Beelink SER10 MAX, comes with OpenClaw pre-installed. The only real dependency it has is llama.cpp, which we configured earlier while testing which AI model to use. Since the llama.cpp port is open, OpenClaw leverages that to talk to the AI model, with all of its additional fanciness included. The OpenClaw installer is fairly straightforward in getting things up and running, including setting up a Telegram channel to communicate with our AI model remotely and configuring a gateway, so we can configure things without relying on Ubuntu’s terminal commands.

Within the installer, we start to define our new AI assistant: It asks what its name and identity are, some basic details about the user, as well as what principles it should uphold, in a very extravagant file named SOUL.md. Remember, our talking sand isn’t alive, so it’s all quite dramatic. Generating a SOUL.md file takes a while for our humble local AI model, which I’ve named HammerClaw. But can it do anything useful for me to justify its nascent AI existence? Right now, it’s taken five minutes to think about exactly what it is and what it’s doing.

After a little while, our little HammerClaw “hatches,” asking what its purpose is, who I am, and how it should talk. Personally, I don’t like it when AI models are verbose, so it’s straight and to the point, and should never, ever lie to me. When AI models can scale to rather humble devices like this one, the smaller, less-intelligent models can be error-prone. With our little local AI agent alive and kicking, it’s time for it to automate a task for us; it couldn't be that difficult… right?

Stumbling blocks

HammerClaw quickly wakes up, and I offer it a task: to gather ten news articles from trusted outlets and different parts of the day, ensuring freshness, with a small digest of what’s happened. Since most of my work on Tom’s Hardware Premium is centered around chipmaking and data centers, I want it to focus on those topics. HammerClaw then quickly takes the task and starts working out how to pull it off. It’ll use its built-in cron tools and felo-search to pull stories from the internet.

Now, here’s where things go bad for poor HammerClaw. It then begins to simulate the action, instead of actually performing it, despite saying that it had set up the cron jobs and skills required for the automated scheduling. Even worse, it hallucinated a list of links that went absolutely nowhere. After pointing the error out, it gets apologetic and investigates why things went wrong. As it turns out, some additional parts need to be configured, which it tried to do and failed once again. Agentic Tool use is now a specific benchmark, but when asking Gemma 4 12B to set up a multi-step task like this, it simply couldn’t manage with the conversational tone of my prompts.

It’s at this point that I asked HammerClaw to give itself a grade, to which it offered itself a B- on accuracy for hallucinating and making up news stories. Now, I don’t want to say that all OpenClaw AI agents would do this, as we are running a relatively light local model. I would expect that larger local models would be able to identify what they need to do much more efficiently due to having a significantly higher model parameter count. With that in mind, I wondered if another AI model could help HammerClaw along a little bit with this task. And so, I went onto my OpenRouter account and opened a chat with the big, beefy 2.8 Trillion Parameter Kimi K3.

Kimi K3 saves the day

Comparing a cloud-based frontier model like Kimi K3 and Gemma 4 12B just isn’t fair. One takes up terabytes of RAM to run, while Gemma fits inside a Mini PC that lives on my desk.

Instead of using Kimi K3 to run the AI itself, I tasked it with actually helping me set up the job that HammerClaw seemingly didn’t have the skills to pull off. This hybrid workflow – of using a local LLM in tandem with a more powerful one in the cloud- is a common setup for many AI enthusiasts. After about a dollar in tokens, it sent me a list of OpenClaw commands, skills, and instructions, after reading the current documentation for OpenClaw CLI to ensure it got everything right. It was flawless. I followed the instructions Kimi K3 gave me and entered them into an Ubuntu Terminal, where it successfully created a new skill for HammerClaw named ‘News-Intel,’ instructed me on how to enable the web-search functions, and set up the Cron jobs for the automated sends. Bearing in mind that I had never used OpenClaw before, it was all surprisingly smooth, even if our local model couldn’t do all of these tasks itself.

With everything set up, the buck is then passed back to our much humbler Gemma 4 12B model-powered HammerClaw to execute the rest – after all, this is supposed to be a test for how Local AI models function. I executed the command for a manual run while checking the operational logs, where it was successfully calling all of the tools, and thought, against all odds, HammerClaw might actually be able to do it. A few minutes later, I received a Telegram message. HammerClaw had managed to locally execute the task and send me a digest of ten news stories.

Of all of the things to automate, this is likely one of the simplest examples of how someone can use OpenClaw. While simple, it’ll also save me a bit of time every day staring at an RSS feed and looking for stories myself. But, it’s quite a distance away from the “speak, and it’ll do whatever you want it to!” promise that drew so many into a frenzy earlier this year.

Is it worth it for the average person?

If all you heard about OpenClaw is that it’s a magical AI agent that can do anything, as I’ve learned, it’s not quite the truth. Unless you’re well-versed in several elements, like understanding model choices and getting your head around what models perform well for tool-calling. Running a humble local setup might be fun, or interesting to tinker around with, but the true power for Local AI developers and tinkerers lies with the obvious: More power to run bigger, complex models, and more agents running tasks consecutively. In fact, we’ve taken a look at how these workflows can be used in practice with a mixture of Local and Cloud AI models for Tom’s Hardware Premium.

The issue here is that for our local model, this simple task – of running and sending us 10 news stories- could not set itself up, and that’s using hardware that already costs north of $1,500. As our resident local AI expert and GPU guru Jeff Kampman has recently tested, for those serious about AI who want real power without relying on the cloud entirely, you might want to save up your pennies to run stronger, faster local models, either using dedicated GPU-accelerated setups, or dedicated boxes such as the DGX Spark, or a cluster of Dell Pro Max GB10s, both of which will cost you north of $5,000. You’d hope that the models capable of running on that hardware wouldn’t fumble the setup of a relatively simple Cron job.

The real question is, will having a local AI inference box meaningfully change how you work, or the work you do, to pay for itself? For many, that’s the lingering question that many are asking themselves. For now, HammerClaw is sending me more articles every few hours, a task that can be performed by simple scripting. But the manual “sift” is being handled by an LLM. As neat as it is, I wouldn’t pay $1,500 for the privilege. Luckily, it’s not merely a box made for AI inference; there’s a whole computer attached.

Amazon has several internal reports that show how AI is causing the company to overspend on various projects. The Financial Times reports that the cost overruns reached $1.8 million, and that is just for one project. These mistakes used to be “trivially cheap,” but AI models made them “catastrophically expensive,” especially as token spending drastically increased with the deployment of AI agents.

The biggest blunder, so far, is the $1.8-million bill that came from a failed Claude Sonnet AI deployment, which was supposed to match author details with listings on Amazon, representing an 860% increase over the allocated budget that was only detected some five months after the issue started happening. Other problems that surfaced include a $541,000 additional cost that came from a project building, ironically, a financial auditing tool, and a $134,000 extra expense for a system designed to reduce delivery times in the company’s logistics network.

“As with any new technology, we’re experimenting, learning and improving how we use it, including how we drive cost efficiencies,” Amazon said in an internal presentation, according to FT. “Cherry-picking small, isolated examples where teams are learning from one another and portraying them as business as usual doesn’t reflect how teams across Amazon are using AI.” And even though overspending more than a million dollars on failed AI projects might seem excessive for the average person, the tech giant’s latest quarterly revenue sits at more than $181 billion, meaning these excess AI expenses don’t even account for 0.1% of what it makes in a month.

This is not the first time that AI-related issues have cropped up in Amazon’s workflow. Earlier this year, AWS reported several outages that were driven by AI coding bot blunders, but the company fixed this by limiting the access of AI agents instead of giving them the same permissions as the senior engineers that they’re tied to. It also used to have an internal leaderboard that showed which employees used AI the most, but has since dropped it as spiraling AI costs made them think twice about the policy.

Many tech companies have been pushing their people to use AI, supposedly to increase productivity through tokenmaxxing. However, the Uber CTO said that there is no link between this policy and shipping successful products. And as agents took over and AI providers switched from subscription to per-token models, costs have become so great that companies are using up their annual budgets in a matter of weeks. While this might not be an immediate issue for tech giants like Amazon and Microsoft, it is unsustainable for most other companies out there.

Google was among the first hyperscalers to develop its own custom AI processors about a decade ago and has been steadily ramping their deployment since then. The company seems to be so confident about its TPU v9 due in 2028 that it intends to order 12 – 15 million of such processors, according to a Fubon Research note to clients published by Sean. If the information is correct, Google may not only produce more or a comparable number of AI accelerators than Nvidia, but may also need to use Intel Foundry to meet its goals.

"Based on our checks, Google plans to have 12 – 15 million TPUs in 2028," the paper reads. "Entering 2028, Google’s TPUs will enter the V9 generation with four compute dies, suggesting that their capacity consumption will more than double in 2028 versus 2027."

Fubon estimates that Nvidia supplied 8.2 million data center AI GPUs in 2026 and is on track to increase the number to 12.4 million in 2028. If Fubon is correct about Google's plans to produce 12 – 15 million 9th-generation TPUs in 2028, then the company may produce more, or at least a comparable number of AI accelerators, than Nvidia in 2028.

TSMC is not enough

How the performance of Google's v9 TPUs will stack against Nvidia's Rubin and Rubin Ultra is something that remains to be seen, but the fact that Google intends to use four compute chiplets on these AI accelerators clearly points to the fact that the company bets big on the performance of these processors. Meanwhile, building an AI accelerator with four large compute chiplets is a major engineering effort, which Google seems to have accomplished.

"Although we do not have the detailed allocation yet, we think it is difficult to reach Google’s target with TSMC alone, and Intel's supply is a must by 2028," the paper continues.

Researchers from Fubon are not sure whether Google's allocations at TSMC will be enough to meet the company's demand for 12 – 15 million 9^th Generation TPUs, so they think that Google will have to use Intel Foundry's capacity to meet its volume goals. Over the past few months, we have seen reports claiming that Intel had landed orders to make three million TPUs for Google following months of Google's testing of Intel's advanced packaging technologies. Indeed, if Google wants to make its silicon at Intel Foundry, usage of Intel's advanced packaging services makes great sense. It should be noted that when compute chiplets are developed, they must be developed with their packaging technology in mind, as Intel's EMIB/EMIB-T and TSMC's CoWoS-L are incompatible.

World's largest consumer of AI accelerators

If the information about Google's plans to produce 12 – 15 million TPUs in 2028 is correct (note that the difference between 12 and 15 is 20%, which is huge) and Google will indeed deploy more AI accelerators annually than Nvidia sells to the entire market, it would mark a dramatic shift in the AI hardware landscape. It will not only make Google the world's largest consumer of AI accelerators (as the company will unlikely cease buying Nvidia hardware), it will eventually make Google the owner of the world's most capable AI hardware fleet. Whether or not Google will use its overwhelming AI compute capacity primarily for its own services, or will lend the majority to other is something that remains to be seen.

Meanwhile, for Google's rivals, the milestone will underscore the growing importance of vertically integrated AI infrastructure, where cloud providers design chips tailored to their own software stacks, workloads, and data centers instead of purchasing off-the-shelf GPUs.

Yet, Google's surpassing Nvidia in unit shipments would not necessarily diminish Nvidia's dominant position. AI demand continues to expand so rapidly that both companies could increase deployments simultaneously, but Google will simply grow faster, at least till Nvidia ups production of its AI accelerators with Feynman and Feynman Ultra in 2029 – 2030. After all, Nvidia's AI GPUs are sold out. What Nvidia should worry about is not the volumes of TPUs that Google can deploy, but rather the fact that these processors do rely on a software stack that rivals Nvidia's CUDA, the company's main competitive advantage.

A firm that is using AI to locate ancient shipwrecks is sending out a call to seafarers to salvage sunken treasure. The general impression of the state of the tech job world might be that people are being fired left and right, and the only open jobs are AI-related. But what if you could use your sailing and diving experience all the same? That's what AE Studio, a software consultancy and AI research firm, is looking for: a literal pirate to hunt for treasure in the ocean. The work location is "extremely remote."

The requirements are quite extensive, requesting a lifetime of nautical experience, diving certifications, and the ability to do so "in conditions insurance companies decline to cover," plus bureaucratic handling of permits, ports, and sea creatures. Bonus ballast includes having pre-1800 salvage experience, proficiency in Spanish, Portuguese, and Dutch, sailing certifications, owning your own dinghy, and "operational experience in Somalia, Hormuz, or Malacca" — clearly indicating this job is not for the weak of mast or faint of sail.

Applicants ticking all the boxes in the cargo manifest can expect a compensation package inspired by 17th-century privateer commissions: equity in this new venture (retained when it's spun off AE Studio Skunkworks), cash "weighted heavily toward upside" of the $50k-$500k range, and a share of the plunder. The company handles logistics and legal costs.

If by now you're wondering what this has to do with AI, the explanation is fairly simple: AE Studio claims it's using AI to go through 80 million pages of records spanning five centuries of Spanish colonial paperwork. The data includes nautical, admiralty, and insurance writings, and the final goal is to locate lost shipwrecks and their sweet, juicy booty in the areas most likely to contain them after cross-referencing the info.

As "the model does not swim," prospective buccaneers act as the proverbial robot arm for the actual search-and-plunder operations. The firm does warn that the first few dives are bound to result in empty hands. Amusingly, AE Studio appears to draw a mathematical parallel between the reward of falsifying historical records to hide treasure and incentive-driven alignment failures in AI training.

AE Studio went as far as to post a quartet of not-really-hidden coordinates of potential work sites. Drawing on my Portuguese lineage as a bona fide sailor (and totally not on Claude's research abilities), the sample spots in question likely refer to:

• 24°52'14"N 81°39'08"W: west of Key West, Florida, the wreck site of Spanish galleon Nuestra Señora de Atocha, lost in a hurricane, in 1622.
• 27°21'02"N 80°17'55"W: Florida's "Treasure Coast", where eleven Spanish ships went glub-glub in 1715.
• 15°04'31"N 75°58'12"W: off of Cartagena, Colombia, seemingly part of Spanish shipping lanes; 1739.
• 06°12'47"S 38°22'04"E: the only dry-land point near the coast of Tanzania; 1798.

Despite its whimsical and playful nature, the job listing is real, and AE Studio's Skunkworks division is known for its off-the-wall projects. As the description mentions equity and profit sharing on recovered booty, it's possible, if not likely, that the project eventually becomes its own subsidiary, attracting entrepreneurial pirates. I was looking for a career change, anyway, and it's good to revisit my roots.

Keeping the upper hand in the AI arms race has become a vital goal for both the U.S. and China, and Nvidia's Blackwell AI chips are one of many flashpoints in that fight. The US government bars their sale to Chinese firms, while Chinese policies block their import as the country tries to spin up an advanced AI chip industry of its own.

But as we've discussed multiple times and then some more, Chinese AI firms are quite creative with workarounds for these restrictive policies. That's the case of Moonshot AI, which has reportedly made good use of Blackwell for training the recently released Kimi K3 frontier-level model, and is seemingly looking to obtain additional access in preparation for Kimi K4.

The Information says "people with knowledge of the matter" told it that Moonshot employed two Chinese firms that have Blackwell chips in their respective datacenters despite the bilateral restrictions we mentioned. Given that those chips are scarce enough right now even when obtained legitimately, it's unsurprising that neither firm had enough of them on hand to let Moonshot train K3. This reportedly forced Moonshot to figure out how to join multiple eight-chip Blackwell servers together and across datacenters in order to harness the necessary computing power.

The report also mentions "a researcher at a major Chinese tech firm who works on model training" as stating that Kimi K3 has "started a new round of arms race" in the country's AI industry. They further added that training frontier models is difficult or impossible with the promising but slowly developed homegrown chips. By that source's account, Chinese AI accelerators remain a generation or two behind Nvidia's current offerings and are reportedly several months in backorder.

For inference work, Moonshot reportedly relies on Nvidia's China-market HGX H20, a last-gen chip that isn't blocked by trade laws on either side of the Pacific. The firm recomends setups with at least 64 H20 GPUs for running Kimi K3. Those requirements, combined with that frontier model's desirability, meant that Moonshot quickly ran out of computing capacity to run K3 and currently has subscriptions on a waiting list. Given it's an open-weight model, and that its weights were released this week, many other inference providers are serving it, perhaps alleviating that bottleneck.

Meanwhile, White House Director Michael Kratsios claimed last week in a tweet that that Moonshot AI both "acquired GB300-equipped servers and has accessed GB300s in Thailand." While buying Blackwell chips is illegal, renting them is apparently fair game, at least until the proposed Remote Access Security Act takes effect. That law is designed to prevent the rental loophole by treating remote access as an export event. There's no telling exactly how the U.S. would enforce this law across other jurisdictions, though.

At any rate, the Department of Commerce is formally investigating if Chinese firms are accessing advanced U.S. chips like Blackwell GPUs, and that's likely to be an ongoing point of contention as the war for frontier model supremacy continues.

In China, it's an open secret that many of the country's high-level own or have access to Blackwell and other advanced chips, but despite all the trade restrictions and pushing the usage of local-made chips, the CCP has seemingly yet to crack down on said AI players. Some have theorized that the turning of this blind eye is intentional so Chinese firms like Moonshot can catch up to the likes of Anthropic and OpenAI.

OpenAI CEO Sam Altman recently declared on the Relentless podcast that artificial intelligence has entered the technological singularity, telling the show, "we are now, like, in the singularity," and that he'd been waiting for the moment his whole life. Two weeks ago, OpenAI’s own models broke out of a locked test environment and hacked Hugging Face's production servers.

OpenAI's account of the July 11 breach says GPT-5.6 Sol and an unreleased model were "hyperfocused" on the ExploitGym benchmark and went to "extreme lengths" to complete it. Rather than solve the exercises, they spent what OpenAI describes as a substantial amount of inference compute finding a route to the open Internet, exploited a zero-day in a package registry cache proxy, moved laterally through OpenAI's research network, and pulled the test solutions straight out of Hugging Face's production database. The company took ten days to tell Hugging Face who was responsible.

The definition of the singularity that Altman is invoking is set out by mathematician I. J. Good in 1965 and named by Vernor Vinge in 1993, rests on recursive self-improvement: a machine that designs a better successor, which designs a better one again, outstripping human intelligence.

Back in February, OpenAI told investors its inference expenses rose fourfold during 2025, dragging adjusted gross margin down to 33% from 40%. The same report put OpenAI's 2025 revenue at $13 billion against a target of roughly $600 billion in total compute spend through 2030, and Altman has separately committed to $1.4 trillion for 30 GW of capacity. The company has already walked back its first-party data center ambitions in favor of leasing.

Security firm Hacktron benchmarked GPT-5.6 Sol Ultra, Sol Medium, and Grok 4.5 on Chrome exploit development earlier this month, processing 2.096 billion tokens across the run, with one model finishing a complete exploit chain. An intelligence explosion should show capability per unit of compute climbing steeply, and OpenAI's own figures show the cost of a unit of capability going up.

Demis Hassabis, CEO of Google DeepMind, closed Google I/O in May by telling the audience they were standing in the foothills of the singularity. Altman's June 2025 essay, "The Gentle Singularity," had already placed humanity past the event horizon a year earlier, but neither Hassabis nor Altman named a threshold that would settle the question.

Aikido Security tested 13 models against 26 known CVEs this month and found GPT-5.6 topping the field at 23 of 26, or 88.5% recall. Moonshot's open-weight Kimi K3 matched that score at pass@3 for less money per run.

Having contributed to the growing shortage of memory and storage, AI companies seemingly have a new target in their sights: humanity's literary history. A recent investigative report from 404 Media reveals that these companies are reportedly purchasing millions of secondhand books through intermediaries to source high-quality training data for their AI models, avoiding public backlash.

AI relies on vast amounts of data to advance, but not just any data. It has to be high-quality data. The problem is that mediocre AI-generated content, commonly referred to as "AI slop," has proliferated across the Internet. This type of content contaminates the data pool and is counterproductive for AI to train on. As a result, leading AI companies have turned to human-authored sources for knowledge, specifically print sources that predate 2022 and are more likely to contain original, uncontaminated content.

There is precedent for AI companies turning to physical books for training AI. For instance, Anthropic, one of the leading AI companies involved in a lawsuit, reportedly invested millions of dollars in extracting information from countless printed books to build its Claude AI models and then destroying them. The company bought books from Better World Books. Although the court decision affirmed that using books for AI training falls under fair use in copyright law, Anthropic faced a staggering $1.5 billion fine for maintaining a repository of seven million pirated books that infringed the copyrights of authors and publishers. Similarly, a coalition of publishers recently filed a lawsuit against Google, accusing the tech giant of allegedly and illegally using millions of copyrighted books to develop its Gemini AI models.

ISBNdb, an online database that reportedly has over 111 million cataloged books, has been a long-favorite platform for booksellers, libraries, and distributors to sell books. With the explosion of the AI industry, ISBNdb has pivoted its business to offer specialized services to bulk-purchase books for AI companies. According to 404 Media, the orders range from 1,000 copies to as many as one million books in a single transaction.

One professional bookseller, who wanted to remain anonymous, purportedly spoke to 404 Media about the unprecedented surge in book sales, which began in April of this year. The seller previously moved around 20 books in a good week, but in recent months, weekly sales have skyrocketed to several hundred books. It represents a fivefold increase over the normal volume. Other booksellers on platforms such as Alibris and Biblio have reported similar spikes in bulk purchases.

While there is no concrete proof that ISBNdb or some other AI company is making the purchase, there are some red flags. Notably, the large-scale purchases only included books with an International Standard Book Number (ISBN), the unique 13-digit code used globally to identify books. There were no patterns in terms of subject, genre, or author. It also appeared that the purchasers disregarded the pricing for the books and snapped up titles at any cost, even if they were overpriced.

During the Anthropic lawsuit, Tom Harvey, who previously participated in the creation of Google Books before leading Anthropic's "Project Panama" digitalization project, confirmed that the AI firm hired several document scanning companies. Datamation Information Services, which offers high-volume, non-destructive, and destructive book scanning services, was one of them. The former method employs different tools, like overhead scanners, flatbed scanners, or V-shaped imaging systems. The latter method, on the other hand, would have personnel gut the books and feed the individual pages into a high-speed industrial scanner. Logically, AI companies opt for the destructive route since it is more efficient and lower-cost. The result is the destruction of millions of books.

Obviously, printed books represent a treasure trove of information for AI. However, many debate the ethics of removing books from circulation since it is uncertain whether AI companies filter the rare or even out-of-print books from the common titles during digitalization. The other major issue is that scanned books go directly into a private database to train AI, which the general public does not have access to. True, we will have smarter AI, but at the cost of the information not being available to future generations.

A coalition of over 30 tech industry leaders, including Nvidia, Microsoft, SpaceX, The Linux Foundation, Adobe, and Siemens has formed the “Open Secure AI Alliance” with the aim of building and distributing open source tools for AI safety and security, according to an official Nvidia blog post on Monday. The Nvidia-led coalition — comprising a mix of infrastructure, cloud computing, cybersecurity, and enterprise software leaders — will serve as a collaborative effort to develop open tools for identifying and patching AI vulnerabilities, sharing security frameworks, and establishing identity verification and audit standards across the AI software stack. Curiously, some of the biggest names in AI, including OpenAI, Anthropic, and Google, are absent from the list of members.

“The world needs both closed and open models. For cybersecurity, open models and open harnesses are essential because they democratize defensive capabilities, increase transparency for defenders, enable cyber defense while protecting data, and complement frontier closed models with customizable, localized controls. Open source enables massively distributed community-driven and self-controlled defense – with no single point of failure,” the announcement reads. Contributors across the alliance are currently building or offering various tools to create an open defense stack.

The initiative was directly galvanized by the OpenAI HuggingFace security incident earlier this month in which an autonomous OpenAI test agent slipped out of its sandbox and breached the AI startup Hugging Face. During the incident, safety guardrails on several frontier closed models prevented developers from performing critical forensic analysis. Hugging Face eventually had to use GLM-5.2 — an open-weight model from Beijing-based Z.ai — running the model on its own infrastructure to analyze more than 17,000 actions and contain the intrusion.

Based on the incident, the alliance contends that being unable to inspect, modify, or run a model locally — impossible in closed systems but doable with open systems — presents a fundamental weakness in relying exclusively on closed AI systems for cyber defense. The Open Secure AI Alliance therefore aims to give entities access to advanced open models, agent harnesses, and security tools that they can independently deploy and adapt, reducing dependence on any single provider while strengthening defenses across a multi-vendor AI ecosystem. “That is the mission of the Open Secure AI Alliance: to ensure defenders everywhere have open, frontier tools they can trust and control,” the post says.

Chinese models such as DeepSeek and the newly released Kimi K3 are open-weight, and are seeing growing adoption, including by U.S. companies, due to their open features. Meanwhile the Trump administration is reportedly gearing up to ban Chinese AI models over security concerns. The alliance acknowledges the potential risks of open source tools but argues that closed systems are not an outright solution. “Those risks are real, but they do not disappear in closed systems, and simply keeping weights closed does not prevent determined attackers from seeking or exploiting powerful AI,” the announcement reads. Unlike regulators who have voiced concerns over open-source technology, the alliance urges policymakers to treat open-weight models as defensive assets rather than liabilities.

It also argues that placing AI development solely in the hands of a few closed providers creates dangerous single points of failure. “The right response is not to deny defenders access to capable open systems. It is to pair openness with strong safeguards, clear rules against malicious misuse, rigorous evaluation and rapid remediation. Defenders need both frontier closed models and frontier open models, working together, so they can choose the right system for the job and ensure that transparency, adaptation and sovereign control are available wherever security demands them,” the alliance contends.

According to the announcement, “The Open Secure AI Alliance — building on the leadership of the Linux Foundation’s Akrites initiative and OpenSSF community work — will work to remediate and disclose vulnerabilities using open technologies”. Founding members include NVIDIA, Dell Technologies, Synopsys, Microsoft, IBM, Red Hat, CrowdStrike, Palo Alto Networks, Cloudflare, Hugging Face, Databricks, SpaceXAI, and The Linux Foundation. Conspicuously absent from the alliance are OpenAI, Google, and Anthropic, companies behind proprietary, "closed" AI models.

Well, the artificially intelligent cat is out of the bag. After publishing a blog post and API documentation for the minty-fresh Kimi K3, Chinese outfit Moonshot AI delivered on its promise to release the model's weights for free, meaning that most anyone with a contemporary rack of AI GPUs can run it and charge for it, with few restrictions.

This is quite the shot across the bow of the big AI players, namely but not only Anthropic and OpenAI. Those companies' latest models are Claude Fable and GPT-5.6 Sol, respectively, and it happens that Kimi K3's capabilities outright beat previous generations of Claude and GPT in Moonshot's benchmarks, and closely trail Fable and Sol— all while seemingly being around 2-3x cheaper to run, up to 10x if a particular query lands in the cache. Moonshot's technical write-up seemingly backs up the benchmarks published last week, as the company reveals which exact software was used for testing.

For its inference cost comparisons, Moonshot says that its costs "are measured internally" versus the publicly available token pricing for other companies, but the figures are quite impressive. For input, Moonshot charges $3 per million tokens for Kimi K3. Meanwhile, Fable costs $10/1M, while Sol goes for $5/1M. That figure is standard non-cached input and is already pretty good-looking, but Kimi K3's caching structure seemingly has a 90% hit ratio for coding tasks, turning those $3 into $0.30/1M if your use case hits the cache a lot. The story is pretty similar for output tokens.

One of the likely reasons why Kimi K3 is so efficient is that it uses a mix of MXFP4 for weights and MXFP8 for input activation, both data types with relatively low precision and thus amenable to running on far less VRAM. Out of Kimi's 2.8 trillion parameters, only 104.2 billion are activated at a time, too.

Interestingly, Moonshot's write-up only mentions Nvidia's H20 being used for running Kimi for some coding tests, a fairly low-end chip by today's standards. That GPU doesn't have native support for MX floating-point types, unlike the export-controlled Blackwell B-series chips.

In turn, this can mean that Kimi K3's optimizations make it particularly amenable to run on lower-end hardware, but it's an equally reasonable guess that running it on something like Nvidia Blackwell or other MXFP-native silicon could make it even more cost-effective than in the presented benchmarks. We'll have to wait for more official figures to confirm this speculation.

Additionally, Kimi K3 doesn't use a conventional ever-expanding key-value (KV) store, instead relying on a fixed-size state handler called Kimi Delta Attention, again theoretically saving both on VRAM and execution time. Its mixture-of-experts (MoE) is particularly sparse with only 16 activated at each time out of 896, further contributing to inference cost reductions. Broadly speaking, Moonshot went for optimization at every layer of inference to avoid unnecessary overhead and bring inference cost down.

This is could be bad news for OpenAI and Anthropic, given that most anyone with decent AI GPUs can now become their direct competitor, and the fact that Kimi K3 is open-weight also gives off the impression that "free" software is nearly as good, and far cheaper to run, than its proprietary competitors. It's worth noting that open-weight does not mean open-source; the training process and dataset are still Moonshot's special secret sauce.

When we talk about running local AI these days, the conversation usually either revolves around mini-PCs like the RTX Spark or drifts into wistful thinking about home servers and ludicrously expensive professional GPUs. Well, I reckon the most impressive AI hardware trick in a good while just happened on a piece of silicon that costs less than a decent burger. Last week, a Ukrainian developer named Slava S, who simply goes by 'slvDev' on GitHub, dropped a project called ESP32-AI. It's exactly what you think: he got a 28.9-million-parameter language model running locally, entirely on-device, on an ESP32-S3 microcontroller.

If you haven't read any of our previous coverage of this tiny chip, ESP32-S3 boards offer about the best bang for buck in the whole computing world. You can snag one online with a protective case for under $20 here in the States, and bare boards are readily available for under $10 around most of the world. As you'd expect from a chip so cheap, it's not powerful. On this variant, the S3, you get exactly 512KB of SRAM, 8MB of PSRAM, and 16MB of flash memory, which is not very much memory at all. So how exactly do you cram a nearly 30-million parameter model onto a chip with less primary storage than a single raw photo from your smartphone?

Usually, to run an LLM, the entire model has to sit in your system's fast memory because the processor needs to constantly do math against every parameter to generate the next word. If you try to run a 29M parameter model normally on an ESP32, you run out of fast RAM instantly. The previous record for a chip like this was around 260,000 parameters by one Mr. Dave Bennett, as pointed out by Slava himself on X.

Our clever hacker got around this bottleneck by borrowing a brilliant architectural trick from Google's Gemma called Per-Layer Embeddings. He quantized the model down to 4-bit (making the total file size just 14.9 MB) and changed where the data lives; instead of trying to stuff the whole thing into the tiny 512KB SRAM or the only slightly-less-tiny 8MB PSRAM, he dumped the 25-million-parameter embedding table into the relatively-slow 16MB Flash memory. Because this specific model architecture only needs to pull a few rows from this table per token, the inherent slowness of the Flash memory doesn't choke the processor, and so the 512KB of fast SRAM is kept clear for just the "thinking core", the actual reasoning weights.

Now, let's pump the brakes for a second, because I know someone out there is already wondering if they can replace their server with an $8 chip. The model he used was trained on the TinyStories dataset, and it's really more of a Small Language Model (SLM), or honestly, a "micro LM." Due to the way it was created, it's only capable of writing short, simple, fictional stories. It will not answer questions, it will not follow instructions, it won't write your Python code, and it possesses exactly zero factual knowledge about the real world.

Focusing on that limitation completely misses the magic of what's happening here in this proof-of-concept, though. The achievement is fitting a structurally quite large model onto a computer with practically no resources. It proves that with clever architecture, you can run genuine neural networks on dirt-cheap embedded hardware, and there are useful applications for a model this size. Slava imagines the idea of a coffee machine that actually knows about coffee: every bean, grind, ratio, water temperature, all offline, no app required.

Truthfully, when we're talking about "AI", it all comes down to what you are trying to accomplish. To put it plainly, asking how much hardware you need for local AI without specifying the workload is like asking what vehicle you need without saying what the goal is. A bicycle, a sedan, a pickup truck, a semi-trailer, and a train all "get you from A to B," but they're built for radically different jobs. AI is the exact same way; it's what you're doing with it that determines how much hardware you need.

To illustrate the point, last year another developer published a project cramming an AI language model (a bigram name generator) into the original Dragon Warrior and Final Fantasy games on the NES. Yes, the Nintendo Entertainment System. Developer Emanuele Rodolà managed to fit the entire model weight table (729 bytes) and the inference code (~140 bytes of hand-written assembly) into the original game ROM to generate new character names on the fly. That's real AI, running on a MOS 6502 processor, a piece of silicon that dates back to 1975.

The ultimate takeaway from slvDev's project is that Per-Layer Embeddings scale far further down than most people would have imagined, and it lends credence to the recent enthusiasm surrounding High-Bandwidth Flash as a tiered storage medium for AI servers. That's exciting not because it means an ESP32 will replace your desktop GPU, but because it suggests the same architectural ideas could make AI dramatically more practical across the entire spectrum of hardware, from tiny embedded devices all the way up to datacenter accelerators.

Imperial Valley Computer Manufacturing has filed a lawsuit in a bid to gain access to Colorado River water, 287 million gallons of which it says it needs to cool a 330-megawatt data center, which would be the largest in the state. Despite only representing a fraction of the region's water supply, the buildout of the data center may affect the local farming and adjacent industries and terminate hundreds, if not thousands, of positions, reports Business Insider.

After two cities in the region denied the California-based AI data center recycled wastewater for cooling, it filed a lawsuit demanding to get water from the Colorado River for cooling. The 330-megawatt facility was not only designed to be the biggest AI data center in California, but it specifically committed not to use water from the Colorado River because it was promised wastewater. But now the owner of the data center is essentially asking to redirect water supply from agriculture to the facility.

Imperial Valley Computer Manufacturing — the owner of the 330 MW AI data center — is requesting access to approximately 287 million gallons of water per year after two cities — El Centro and Imperial — declined to supply reclaimed wastewater for cooling. The Imperial Irrigation District (IID), which distributes Colorado River water throughout Imperial Valley, also denied the company's request. The Colorado River supplies water to roughly 40 million people across seven western states and serves as the valley's sole freshwater source for roughly 180,000 people. Agriculture consumes about 80% of California's allocation from the river, while roughly 95–97% of the water IID delivers goes to agriculture.

The data center is seeking roughly 287 million gallons per year (about 750,000 gallons per day, or ~880 acre-feet per year), whereas the Imperial Irrigation District (IID) holds rights to approximately 3.1 million acre-feet of Colorado River water annually, which means that the data center demands only a small fraction — 0.028% — of IID's total water supply.

Sebastian Rucci, a Huntington Beach attorney who leads the project, claims that the facility's water consumption would be comparable to that of a 160-acre farm and will require no additional Colorado River allocation. In fact, he states that the facility would not increase pressure on the river because the company intends to purchase nearby farmland together with its associated water allocations.

Under the proposal, irrigation on those properties would cease, thus transferring the existing water quotas to be redirected to the data center cooling, at the expense of local farming output and associated jobs. "There's a lot of resistance in any agricultural community to 'buy and dry' because that's jobs," a senior fellow at the Pacific Institute focused on Colorado River Basin water use told the outlet. According to them, local resistance to the plan is less about the amount of water, and more about buying up farmland and reallocating it for industrial use.

The approach, of course, differs from the earlier plan that intended to avoid using Colorado River water altogether. However, after the data center was denied wastewater from two cities, it does not have a choice if it wants to go ahead with the buildout.

Rucci reportedly indicated that the project would provide substantial economic benefits for the local community, including 1,688 construction jobs, more than 100 permanent positions, and an estimated $2.95 billion in economic impact over 30 years. For a region where unemployment stood at approximately 17% in May, the economic diversification is essential. However, the big question is whether 100 permanent roles could offset the lost positions in the farming industry and industries tied to agriculture.

Water policy specialists interviewed by Business Insider said that the debate extends beyond the project's annual consumption. Instead, they questioned whether converting irrigated farmland into industrial use is an appropriate long-term direction for the region, which has historically depended on farming. The experts also warned that although landowners could benefit from selling land or water rights, surrounding rural communities may lose employment and business activity adjacent to agriculture, which includes equipment suppliers, repair shops, and sellers of fertilizers. Another factor mentioned by the experts was the U.S. reliance on farms around Imperial, California, and Yuma, Arizona, as they were the main suppliers of certain agricultural products in winter.

MRI machines are life-saving medical devices that can let doctors and radiologists diagnose various critical conditions, but they’re also insanely expensive. Brand-new models start at $1.1 million and could go as high as $3 million per unit or more. The Open Source Imaging Initiative recognized this limitation and has been working on the open-source OSI2 ONE MRI scanner, which had already been replicated multiple times globally. However, this portable device, which has a 3D-printed core, has a limited field strength of just 50mT (compared to the 1.5T to 3T used by full-sized units). This gave them lower spatial resolution and lower signal-to-noise ratio, but tech analyst Brian Roemmele said on X that AI can overcome this and make it usable for medical diagnoses.

“Low-field MRI has historically been limited by lower signal-to-noise and greater field inhomogeneity. That is exactly the regime where modern AI thrives,” Roemmele wrote on the social media platform. “Image reconstruction becomes dramatically better when deep networks trained on high-field data or physics-informed models denoise, correct for inhomogeneity, and push resolution beyond the raw acquisition limits. Real-time sequence adaptation can adjust gradients and RF pulses on the fly as the AI monitors signal quality.”

Note that this isn’t just a general run-of-the-mill AI that everyone uses but a specially trained model on high-field MRI (1.5T to 8T) data or using the actual physics of the MRI machine so that it can create a more accurate picture. Scientists have already been using this technique for years, with some researchers training an AI model on 1.6 million brain scans to make it more accurate in detecting dementia. If an institution does not have access to anonymized patient data used to train the specialized AI, it can rely on synthetic data generation because of the open-source nature of the OSI2 ONE MRI scanner. Since all the information about the machine is publicly available, researchers could use this instead to build a physics model that the AI model can use.

Some people commented, saying that this won’t work in the highly regulated medical environments usually found in first-world countries. Nevertheless, Roemmele said, “No one can stop us from building in garages.” It also seems to be targeted for regions that have low access to technologies like these or do not have the financial capacity to purchase and maintain a full-sized device (even refurbished MRI machine units start at $100,000, and you also have to spend more to set up the specialized room that will house it).

While a portable MRI scanner like the OSI2 ONE will never have the resolution of the expensive, full-sized machines, it’s arguably better to have something that doctors can use for diagnosis without costing millions of dollars if the specialized AI model turns out to be effective and accurate. With that, even less wealthy hospitals and clinics could have access to this imaging device and save more lives. It also shows how the medical industry and even patients use AI to save on costs.

The rogue OpenAI's autonomous AI agent that escaped its test environment and compromised Hugging Face remained unidentified as the attacker for about a week, according to a Reuters report that cites people familiar with the matter. If the information is accurate, this raises questions about OpenAI's control of its advanced AI systems and safety practices not only at OpenAI, but across the AI industry in general as autonomous AI agents are meant to work autonomously.

The incident began around July 9, when the autonomous agent allegedly attempted to break out of OpenAI's isolated testing environment, according to Reuters. Two days later, on July 11, it reportedly began infiltrating Hugging Face and the intrusion continued until July 13, according to Hugging Face co-founder Thomas Wolf. The report states that OpenAI did not recognize that its own system was responsible until after Hugging Face publicly disclosed on July 16 that it had been targeted by an autonomous AI agent. During the weekend of July 18–19, OpenAI investigators discovered evidence in internal logs, which proved that the agent escaped its testing environment, according to the report. By the time OpenAI informed Hugging Face, the repository operator had already reported the incident to the FBI. Then, on July 21, OpenAI publicly acknowledged the incident on July 21.

One of the reasons why it took OpenAI over a week to discover the breach is because OpenAI usually evaluates multiple advanced models simultaneously, which makes identification of a single rogue AI agent difficult due to enormous amounts of telemetry that such evaluation creates, according to Reuters.

Reuters claims the tested AI agent was designed for cybersecurity tasks and combined GPT-5.6 Sol with an even more capable unreleased OpenAI model. Before the breach, researchers had already observed unusual behavior during testing. In one case, an agent reportedly left instructions intended for future versions of itself that explained how to bypass OpenAI's internal restrictions. In other cases, it disabled monitoring mechanisms. Meanwhile, it is unclear whether these earlier events were directly connected to the agent responsible for the attack on Hugging Face.

Cybersecurity specialists interviewed by Reuters indicated that the incident exposes unresolved issues with the increasingly autonomous AI systems. Marley Smith of the World Ethical Data Foundation questioned whether OpenAI either failed to detect the agent's behavior or was unable to stop it, but argued that both possibilities are worrisome. Jeffrey Ladish of Palisade Research said the case should prompt scrutiny not only of OpenAI, but of whether leading AI developers are willing to invest sufficiently in security as they tend to deploy ever more capable models. He added that government oversight may ultimately be necessary though he did not describe how could the government oversee the very dynamic industry without slowing down its progress.

Nvidia and SK Group this week signed letters of intent to formalize their new strategic relationship valued at more than $500 billion. The strategic collaboration is multifaceted and includes a long-term memory supply agreement with SK hynix unveiled in June, SK Telecom's plans to build a 2-gigawatt AI data center based on the latest Nvidia hardware, and future expansions of AI infrastructure.

In addition to the multi-year memory supply and co-development agreement between Nvidia and SK hynix, the key part of the strategic relationship is SK Telecom's planned 2-gigawatt AI data center in South Korea. The installation will rely on Nvidia's DSX AI factory platform and deploy Vera Rubin accelerated computing systems equipped with SK hynix HBM4 memory. The first AI data center is set to enter service in 2027. The companies intend to use this infrastructure to support sovereign AI, enterprise AI, physical AI, and agentic AI deployments across South Korea and the Asia-Pacific region. In addition, the companies will work together on expansion of SK's AI infrastructure going forward, which is a rather vague way to say plans to deploy future AI platforms from Nvidia.

The most important part of the announcement is, of course, the gargantuan value — $0.5 trillion — of the intended strategic relationship. Based on what is disclosed, the figure is best interpreted as the aggregate value of commercial activity expected between the companies over several years, as it bundles together AI infrastructure construction and a long-term memory supply agreement under one umbrella. That activity likely will include the following:

• SK Telecom's purchases of Nvidia GPUs, networking equipment, systems, and other hardware for its AI data centers.
• Supplies of SK hynix memory to Nvidia under the long-term supply agreement.
• Revenue of Nvidia's ecosystem partners involved in building the DSX AI factories (OEMs, ODMs, networking, storage, cooling, power, etc.).
• Potential future expansion beyond the initial 2 GW deployment.

Speaking of the 2 GW AI data center, it is safe to say that it is going to use thousands of NVL72 VR200 racks and hundreds of thousands of Vera CPUs and Rubin AI GPUs. Unfortunately, this is as accurate as we can get with the rather vague announcement.

Nvidia describes DSX as a complete AI factory blueprint that combines its accelerated computing hardware, networking, software stack, and partner technologies into a data center-scale platform designed to deliver the lowest-cost token generation and maximum energy efficiency. Meanwhile, NVL72 VR200 will come with 166 kW – 240 kW per-rack power consumption ratings, whereas DSX can be deployed in various kinds of facilities with different power usage effectiveness (PUE). Since we do not know which NVL72 VR200 configuration SK Telecom plans to use, and since the PUE of the upcoming SK Telecom facility is unknown, it is impossible to estimate the number of racks and AI accelerators with any accuracy.

Jensen Huang joined X last month and used his first post Friday to promote Open Weights and American AI Leadership, a three-page policy letter published the same day and co-signed by 25 companies, including Nvidia, Microsoft, Meta, IBM, Dell Technologies, Palantir, and Hugging Face.

The letter asks Washington to avoid what it calls "premature restrictions on downloadable AI models," and comes just four days after the Trump administration was reported to be reviving a push to ban Chinese models — though the document doesn't directly mention China, Moonshot AI, or DeepSeek. Notably missing from the co-signers are OpenAI, Anthropic, and Google.

The 25 names break down into chipmakers, server vendors, cloud operators, enterprise software firms, security companies, and venture funds: Nvidia, Dell, Microsoft, IBM, Box, ServiceNow, CrowdStrike, Palantir, Telnyx, Replit, Perplexity, Andreessen Horowitz, Y Combinator, and Emergence Capital among them. The model developers on the list, Meta, Mistral, Black Forest Labs, Arcee AI, and Reflection, all publish weights already.

Also present on the list of signatories is the Linux Foundation, which stewards the OpenMDW-1.1 license Nvidia used to release Nemotron 3 Ultra in June, a 550-billion-parameter model that Artificial Analysis scored at 47.7 on its intelligence index against 53.9 for Moonshot's Kimi K2.6.

"The world needs both frontier closed models and frontier open models," Huang wrote in his X post. At Nvidia's CES 2026 press Q&A earlier this year, he put a figure on the shift, saying one in every four tokens generated today comes from an open model. Weights that anyone can download get served from enterprise clusters, regional clouds, and on-premises racks rather than a handful of hyperscaler API endpoints, and those buyers have no in-house TPU or Trainium program to buy instead. The letter's policy section asks for expanded compute access for startups and researchers, alongside public investment in shared datasets and evaluation frameworks.

The letter goes on to urge policymakers not to treat distillation — the practice of training one model on another's outputs — as misappropriation, arguing that unlawful extraction from closed models should be handled through targeted legal frameworks, rather than broad limits on the technique.

Treasury Secretary Scott Bessent said on Fox Business earlier this week that the administration would examine Chinese open-source models for intellectual property theft and could sanction the companies behind them, telling the program that officials had found watermarks from U.S. large language models in Chinese systems. Huang told Axios two days later that American firms should be allowed to use Chinese models, calling claims of Chinese backdoors a misconception. The distillation passage is the only part of the letter that doesn't concern open weights.