Anthropic IPO: The $895 Billion Question Behind Its Valuation

Anthropic IPO valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range blank. As of our research on 9 November, we found no later amendment.

A month ago, some investors were reportedly talking about valuing Anthropic at up to $2 trillion. By 6 November, Bloomberg reported that prospective buyers were discussing a range of $1.2 trillion to $1.3 trillion, and that some were weighing $1.1 trillion. That is the headline version of the Anthropic IPO valuation story.

The filing tells a more useful one. Anthropic’s November 2 S-1/A shows $17.0 billion of revenue in a single quarter and a nine-month net loss of $104.0 billion, most of it non-cash. It also shows roughly $895.4 billion in aggregate compute and infrastructure commitments. Read together, those numbers explain more about the price buyers will pay than any single bid range does.

Key Takeaways
  • Valuation talk has fallen in reports, not filings: from up to $2 trillion earlier in the year to $1.2 trillion to $1.3 trillion, with one source citing $1.1 trillion.
  • The S-1/A confirmed fast growth and an operating loss: $16.96 billion of Q3 revenue, and a $567 million loss after a profitable Q2.
  • About 91% of the $104.0 billion nine-month net loss is a non-cash fair-value charge on convertible notes, which should end once the existing notes convert.
  • The $895.4 billion is a commitment schedule, not debt. Half of it is leases that have not commenced, and about $213.8 billion is conditional or terminable.
  • The 13.2x ratio shows scale, not solvency. The more useful test is $69.8 billion due in 12 months against $131.8 billion of cash and short-term investments.
  • Commitments could grow. The filing estimates a further $150 billion to $175 billion under arrangements with no fixed dollar figure.
  • Price, size and date are unconfirmed. All three are blank or absent in the filing.

Quick Navigation


Anthropic IPO valuation: what is confirmed and what is reported?

The figures in circulation come from very different places. Some are in a document Anthropic filed with the Securities and Exchange Commission. Others come from unnamed people describing investor conversations. This table keeps them apart.

ItemFigure or developmentEvidence status
Amended registration statementS-1/A (Amendment No. 1) filed 2 November 2026SEC-filed
Q3 2026 revenue$16.96 billion (three months to 30 September)SEC-filed
Nine-month 2026 revenue$33.24 billion, against $2.55 billion a year earlierSEC-filed
Aggregate commitmentsAbout $895.4 billion, substantially all compute and infrastructureSEC-filed
$1.2T to $1.3T valuation rangeDiscussed by prospective buyers, per Bloomberg, 6 NovemberAnonymous-source reporting
$1.1T lower endSome buyers weighing it, “one of the people said” (Bloomberg)Anonymous-source reporting
Earlier $2T expectationsInvestors expected up to $2 trillion earlier in the year, per ReutersPress-reported
Last private valuation$965 billion post-money, $65 billion Series H, 28 May 2026Company-disclosed
IPO timingRoadshow expected from the week of 9 November, pricing the week after, per ReutersAnonymous-source reporting
IPO price range and share countBlank in the amended filingSEC-filed (blank)
Commitments relative to revenueAbout 13.2 times annualised Q3 revenueCalculated
Disclosed figures come from the SEC filing; valuation ranges come from anonymous-source press reports and are not offering terms.

How the Anthropic IPO valuation talk changed

Three numbers mark the slide. Reuters reported that earlier in the year, investors expected an October listing at a valuation of up to $2 trillion. Bloomberg’s earlier reporting, as summarised by Investing.com, put the range investors had passed to bankers at $1.4 trillion to $1.5 trillion. Then, on 6 November, Bloomberg reported that potential buyers were discussing $1.2 trillion to $1.3 trillion, according to people familiar with the matter.

None of these is an official valuation, a filed figure, a trade or an IPO price. They describe what some buyers will discuss before formal marketing begins. For background on how the business looked before the filing, see our earlier analysis of Anthropic’s reported revenue and compute economics.

The Bloomberg report followed a sharp selloff on 5 November, when the Associated Press reported the Nasdaq composite down 4.5% in afternoon trading. AP linked the drop to rising borrowing costs, doubts about AI stock prices, and Democratic midterm gains that raised the prospect of curbs on data center construction.

What the November 2 S-1/A actually shows

The amended S-1 adds third-quarter results to the prospectus first made public on 26 October. Anthropic plans to list Class A shares on the Nasdaq Global Select Market under the symbol “ANT”. Goldman Sachs and Morgan Stanley head the underwriting list. The number of shares and the expected price range are still blank.

Revenue growth and the Anthropic IPO valuation

Revenue for the three months to 30 September was $16,956 million, against $1,382 million a year earlier. That is about 12.3 times the prior-year quarter, and 47% more than the $11,555 million reported for the June quarter. Nine-month revenue was $33.24 billion.

Operating results moved the other way in the latest quarter. Anthropic earned an operating profit of $974 million in Q2, then recorded an operating loss of $567 million in Q3. The filing attributes the swing mainly to $5.0 billion of compute bought under short-term commitments and a $2.0 billion non-cash charge tied to its employee donation matching programme.

Buying short-notice capacity suggests demand ran ahead of contracted supply. It also shows how fast compute costs can swing a quarter from profit to loss.

A $104 billion loss that is mostly not cash

The nine-month net loss of $104.0 billion looks alarming until you trace it. The filing says the accumulated deficit includes $94.3 billion of fair-value changes on convertible notes and derivative liabilities during the nine months, “driven by increases in our enterprise valuation”. In Q3 alone, that line was $21.9 billion of a $23.3 billion net loss.

These are accounting remeasurements. When Anthropic’s valuation rises, the notes are worth more to their holders and the company books a loss, but no cash leaves the business. The prospectus assumes the notes convert into shares immediately before the offering closes, which should end these charges on the existing notes. The filing also says Anthropic may issue up to $77.0 billion more in convertible notes, subject to conditions.

Other items need more care. Stock-based compensation was $3.3 billion over the nine months, and the donation charge was $2.0 billion. Neither is cash today, but both affect shareholders. The cash figures point the other way. Operating activities generated $6.6 billion in the first nine months of 2026, compared with $2.0 billion of cash used a year earlier.

The $895.4 billion figure behind the Anthropic IPO valuation

This is the number most easily misread. The filing describes “an aggregate committed spend of approximately $895.4 billion, substantially all of which is related to compute and infrastructure”. About $447.5 billion is expected before 31 December 2030, and “substantially all of the remainder” between 2031 and 2045.

It is not debt, money already spent, or a single year’s expense, and most of it is not on the balance sheet. It is a schedule of future purchases and leases, often agreed before the capacity is built.

The three figures are nested: the $69.8 billion falls within the $447.5 billion, which falls within the $895.4 billion. Source: Anthropic S-1/A, 2 November 2026.
How the $895.4 billion adds up

The contractual obligations section of the filing lets us rebuild the total. Our addition of the parts comes to $895.39 billion:

ComponentAmountWhat it is
Fixed obligations at 30 September$320.0 billionPurchase commitments of $313.8 billion plus operating and finance leases of $6.2 billion
Leases signed but not yet commenced$451.2 billionMostly expected to begin between 2026 and 2028, with terms up to 20 years
Commitments signed after 30 September$100.2 billionMainly data center leases and cloud hosting agreements
Short-term contracts$24.0 billion$17.4 billion at quarter end plus $6.6 billion signed afterwards

Half the headline, about 50.4%, is leases that have not started. Only about 36% sits in the payment table as of the balance-sheet date. The rest was added later or will only become an obligation when a facility is delivered. This is a large jump from the $518 billion figure reported from the confidential draft in October, which we covered in Anthropic’s earlier $518 billion infrastructure commitments.

The named contracts show the scale: at least $110.0 billion with Amazon through April 2036, about $121.3 billion with Google through July 2033 and at least $44.9 billion with Microsoft through June 2033. Each applies “regardless of actual usage”.

The filing also lists arrangements that are not in the $895.4 billion because they carry no fixed dollar commitment. It estimates payments under these at about $150 billion to $175 billion. It gives separate estimates for extra Google TPU capacity ($125 billion to $150 billion) and an AMD agreement (more than $20 billion), both outside the $895.4 billion. The headline may understate eventual spending even as parts of it stay conditional.

Not all of the total is locked. The filing says about $213.8 billion, roughly 24%, is subject to exercisable termination rights or to conditions before the arrangement begins, such as a counterparty securing financing, sites or regulatory approval. In general, Anthropic can also terminate if counterparties miss delivery dates.

That flexibility cuts both ways. Terms that let Anthropic walk away if a data center is late also mean some planned capacity may never arrive.

Anthropic Direct and the case for locking in capacity

The filing describes a shift from cloud contracts toward what Anthropic calls Anthropic Direct: leasing chips directly and hosting them in dedicated facilities run on its behalf. It says this allows the company “to separate our commitments for data center capacity from our commitments for the compute infrastructure deployed inside them”.

Data centers take years to build but are the smaller part of compute cost, so securing buildings early and buying chips later keeps the costliest decisions open. The trade-off is rigidity: leases of up to 20 years are hard to unwind if demand slows.

The filing also says some data center projects rely on “financing sources or partners who guarantee the lease obligations”. Fortune’s 4 November analysis argues that this shifts part of the risk onto chip suppliers. It is part of the financing pressures across AI infrastructure that have pushed some bond investors to demand higher yields.

The 13.2x comparison: useful for scale, easy to misuse

Here is the calculation behind a figure that has circulated widely:

  • Q3 revenue: $16.956 billion × 4 = $67.8 billion annualised
  • $895.4 billion ÷ $67.8 billion = about 13.2 times

That ratio is a scale illustration. The $67.8 billion annualises one quarter; it is not a forecast or reported annual revenue. The $895.4 billion spans almost two decades. The result is not a debt-to-revenue ratio, an enterprise-value multiple or a solvency test.

Better comparisons look at matching time frames. The filing says about $69.8 billion of obligations is expected to be paid in the 12 months after 30 September. That is roughly equal to one year of revenue at the Q3 rate (about 103%). It is also about 1.8 times the annualised Q3 compute and infrastructure expense of $39.5 billion. These are our calculations, and both comparisons assume revenue stays flat, which recent quarters suggest it won’t.

The pre-2030 figure gives a second view. A simple average of $447.5 billion over the roughly four and a quarter years to the end of 2030 is about $105 billion a year. That is an illustration, not a schedule. The filing’s own table shows payments rising from $29.2 billion in 2027 to $47.8 billion in 2029, before the leases not yet commenced are added.

Why buyers may want a lower Anthropic IPO valuation

The evidence points to several pressures at once, without showing which matters most. The market backdrop is the clearest. Bloomberg tied the lower bids directly to the post-election selloff. Reuters, citing four people familiar with investor discussions, reported that some potential buyers see $1.5 trillion as the top of their range and want a bigger discount. Truist’s Keith Lerner, quoted by Reuters, called the mood “a buyers’ strike in tech”.

Company-specific concerns also feature. Reuters reported investor attention on Anthropic’s record of quarterly losses, its capital needs and its large commitments to partners. Investors also want an October revenue figure to judge whether growth has picked up again after a recent slowdown.

At $1.2 trillion, Anthropic would be valued at about 17.7 times annualised Q3 revenue. At $2 trillion, the figure would be about 29.5 times. These are our calculations, and they ignore whether the reported figures are pre- or post-money.

The private round adds another reference point. Anthropic raised $65 billion at a $965 billion post-money valuation in May, per Reuters. Even the $1.1 trillion lower end is about 14% higher. The two figures are not directly comparable, though. A private round prices preferred shares with negotiated rights, while an IPO prices common stock in an open market and adds new shares.

Cash, liquidity and the Anthropic IPO valuation

Profitability and liquidity are different questions. Anthropic is not consistently profitable on an operating basis, but it holds a lot of cash.

At 30 September, the filing shows $95.6 billion of cash and cash equivalents and $36.3 billion of short-term investments. It also shows $14.8 billion available under a $15.0 billion revolving credit facility that matures in 2031. Cash and short-term investments of $131.8 billion cover the $69.8 billion due over the next 12 months about 1.9 times.

That cushion came mostly from investors, not from operations. Financing activities brought in $110.7 billion over the nine months. Investing activities used $36.5 billion, mainly to buy short-term securities. Spending on property and equipment was only $925 million, plus $2.0 billion of prepayments for leased assets.

The filing warns this will change. It expects more compute investment to need “significant upfront payments” before the compute is operational, and significant net cash outflows “for the foreseeable future”. It says its resources cover at least the next 12 months.

What the IPO could change

The filing says the offering aims to increase Anthropic’s “capitalization and financial flexibility” and create a public market for its shares. Proceeds are for general corporate purposes, including “investments in compute and infrastructure”. Reuters reported that some expect the deal to raise as much as $100 billion, although the filing gives no amount.

A listing would convert the existing notes and end their fair-value charges, making net income easier to read. It would give Anthropic a public currency for future raises. It would also reprice the company daily, so the commitment schedule is judged every quarter rather than once per funding round.

What the Anthropic IPO valuation debate can’t answer yet

Several facts that would settle the argument are not public. The price range and share count are blank. The split between new shares and shares sold by existing holders is unknown, which determines how much cash Anthropic actually raises.

The filing does not give a year-by-year schedule for the $451.2 billion in leases not yet commenced. Nor does it say how the $150 billion to $175 billion of variable arrangements will be phased. Most importantly, nobody outside the company knows how much of the contracted capacity will be needed by the time it arrives.

What to Watch Next

These would change this analysis, roughly in the order they are likely to appear:

  1. The next S-1 amendment: any change to the $895.4 billion or the $69.8 billion due in 12 months.
  2. The price range: the first company-set valuation signal, replacing press-reported ranges.
  3. The share count: needed to turn a price into a market capitalisation.
  4. New versus selling-stockholder shares: how much cash reaches Anthropic.
  5. The pricing date: a slip past the reported November window would be material.
  6. Updated financials, including the October revenue investors reportedly want.
  7. Timing changes confirmed by the company or a filing, not by sources.
  8. Revised investor discussions, treated as reporting, not offering terms.

FAQ

What is the Anthropic IPO valuation in 2026?

There isn’t one yet; the S-1/A leaves the price range blank. Bloomberg reported on 6 November, citing unnamed sources, that buyers were discussing $1.2 trillion to $1.3 trillion.

Why has the reported Anthropic IPO valuation fallen?

Reports link it to the AI stock selloff after the US midterms and to concerns about losses and compute commitments. Which factor weighs most is unclear.

Is the Anthropic IPO valuation higher than its last private valuation?

Based on reported discussions, yes. Anthropic’s May 2026 round valued it at $965 billion post-money. Even $1.1 trillion would be about 14% higher, though private and public valuations are not directly comparable.

How much revenue did Anthropic report in Q3 2026?

$16.96 billion for the three months to 30 September 2026, according to the S-1/A. That is about 12 times the $1.38 billion reported a year earlier.

What are Anthropic’s $895.4 billion compute commitments?

Purchase commitments and leases, substantially all for compute and infrastructure, including leases not yet started. About $447.5 billion falls before 2031 and most of the rest between 2031 and 2045.

Is the $895.4 billion current debt?

No. Most of it is future spending under contracts and leases that have not begun. About $69.8 billion is expected to be paid in the 12 months after 30 September 2026.

Has the Anthropic IPO valuation or price been set?

No. The price range is blank, and reported figures are investor discussions, not offering terms.

When is Anthropic expected to go public?

Reuters reported a roadshow from the week of 9 November and pricing the week after, while noting investor doubts about that timing. Anthropic has not confirmed a date.

Why do compute commitments matter to the Anthropic IPO valuation?

They lock in large future costs before the revenue to pay for them exists. Buyers have to judge whether demand will grow fast enough to use the capacity Anthropic has contracted.

What would change this Anthropic IPO valuation analysis?

A filed price range, the share count, the split between new and existing shares, and any change to the commitment figures in the next S-1 amendment.

This article is for informational and educational purposes only. It is not investment advice, a recommendation to buy or sell securities, or a prediction of Anthropic’s IPO valuation or share price. Reported investor discussions should not be interpreted as confirmed offering terms.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Claude Opus vs Sonnet

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max subscription prices, and partner platforms can price differently.

A million output tokens from Claude Haiku 5.5 costs $0.50. The same million from Claude Fable 5.1 costs $50. That 100x spread across Anthropic’s four current models makes Claude Opus vs Sonnet only part of the decision, and price alone a poor guide to which model is the bargain.

The gap doesn’t mean Fable is 100 times more capable. It doesn’t even mean a task costs 100 times more, because input prices, long-prompt surcharges, caching and the number of attempts a task takes all change the bill. With all four Claude models compared on Anthropic’s API pricing, this guide shows what each costs and which workloads each one suits.

Key Takeaways
  • Output prices span 100x, from Haiku 5.5’s $0.50 to Fable 5.1’s $50 per million tokens. Opus 5.5 is exactly twice Sonnet 5.5.
  • Haiku 5.5 has a cliff at 100K tokens. Above it, the whole request is billed at five times the rate, cached tokens included.
  • List prices overstate the saving from a new model. Haiku 5.5 is 90% cheaper per token than Haiku 4.5, but Anthropic estimates about 75% cheaper per task.
  • Sonnet 5.5 is the everyday default for well-scoped coding, bug fixes and documents.
  • In Claude Opus vs Sonnet terms, Opus 5.5 earns its premium on hard, long-running work, where fewer retries can offset the higher price.
  • Fable 5.1 is Mythos 5.1 with safeguards. Mythos is restricted to vetted organisations; Fable blocks exploit development and redirects some security and biology work.
  • Caching can cut agent input costs by about three-quarters, leaving output as the bigger cost.
  • Choose by workload. Cost per successful task matters more than price per token.

Quick Navigation


Claude Opus vs Sonnet: four models, four jobs

Anthropic’s model overview positions each model for a different kind of work:

  • Claude Haiku 5.5 (released 7 October 2026) is for “high-volume, latency-sensitive tasks such as classification, extraction, and routing”. Anthropic describes it as its fastest model.
  • Claude Sonnet 5.5 (28 September) is billed as “the best combination of speed and intelligence”.
  • Claude Opus 5.5 (22 September) is for “long-running agentic coding and knowledge work”.
  • Claude Fable 5.1 (1 September) is for “demanding reasoning and long-horizon agentic work”. It’s also for cases where your evaluations of Opus 5.5 at higher effort still fall short.

All four are active and share more than the pricing suggests. Each has a 1-million-token context window, a 128,000-token maximum output, adaptive thinking and a June 2026 knowledge cutoff. The differences are speed, depth of reasoning and price. Opus and Fable have thinking always on; Sonnet and Haiku can run without it.

Claude Opus vs Sonnet: what the API prices reveal

Here are the standard rates from Anthropic’s pricing page:

ModelInputOutputCache read5-minute cache write1-hour cache write
Haiku 5.5 (prompts up to 100K tokens)$0.10$0.50$0.01$0.125$0.20
Haiku 5.5 (prompts over 100K tokens)$0.50$2.50$0.05$0.625$1.00
Sonnet 5.5$2$10$0.10$2.50$4
Opus 5.5$4$20$0.20$5$8
Fable 5.1$10$50$0.25$12.50$20

Opus costs exactly twice Sonnet on every line, caching included. Sonnet’s input and output cost 20 times Haiku’s short-prompt rates. Fable costs 2.5 times Opus. The Batch API halves input and output prices for work that can wait, and US-only inference adds a 10% premium.

For a quick sense of scale, take an illustrative short request: 8,000 input tokens (a file plus instructions) and 2,000 output tokens. Every model here uses the same newer tokenizer, so the same text gives roughly the same count on each.

ModelInput costOutput costTotal
Haiku 5.5$0.0008$0.0010$0.0018
Sonnet 5.5$0.016$0.020$0.036
Opus 5.5$0.032$0.040$0.072
Fable 5.1$0.080$0.100$0.180

At that size, even Fable’s request costs 18 cents. The differences only matter at volume, or when a long-running agent multiplies the calls.

Standard Claude API prices per million tokens. Output costs five times input on every model, and Haiku's rates rise above 100K-token prompts.

Claude Haiku 5.5: why cheap tokens aren’t always cheap tasks

Haiku 5.5 is the most interesting pricing story in the lineup, for two reasons.

The first is the 100,000-token threshold. Up to that size, Haiku costs $0.10 input and $0.50 output. Above it, every token in the request is billed at $0.50 and $2.50, including any cached tokens. Anthropic’s pricing page says a request over the threshold “pays the higher prices even when part of its prompt is a cache hit”.

That creates a cliff. On our arithmetic, a 90,000-token prompt with 2,000 tokens of output costs about $0.010. A 110,000-token prompt with the same output costs about $0.060, six times more for 22% more input. For long-document work, splitting inputs to stay under 100K tokens can matter more than the choice of model. Our comparison of LLM context windows and long-context pricing covers how other providers handle the same trade-off.

The second reason is the tokenizer. Haiku 4.5 was priced at $1 input and $5 output, so Haiku 5.5’s list prices are 90% lower. But Anthropic says the new model costs “around 75% less to run” on average. Two things close the gap.

Anthropic’s token-counting docs say Claude 4.7 and later models use a newer tokenizer that produces about 30% more tokens for the same text. That alone turns a 90% input-price cut into about 87% for the same document. Anthropic’s Haiku 5.5 page adds that the model “uses slightly more tokens per task”, which pushes the average saving down further.

The lesson applies to every model change. Price per million tokens and cost per task are different numbers, and the only reliable way to compare them is to count real prompts against the model you plan to use. The token-counting endpoint is free.

Within those limits, Haiku 5.5 is a large step up. Anthropic reports it scoring 72.4% on its offline subset of OSWorld 2.1, against 15.7% for Haiku 4.5. It suggests using it for summaries, classification, live customer support and as a subagent alongside Opus or Sonnet in coding work.

Claude Opus vs Sonnet for everyday work: where Sonnet 5.5 fits

Sonnet 5.5 kept Sonnet 5’s per-token price but, according to Anthropic, does the work more efficiently. The company says it “generates outputs 30%+ faster than Sonnet 5” and, in its testing, costs “up to 30% less per task”. The saving comes from needing fewer tokens for the same work, not from a lower price, so results will vary by workload.

Anthropic positions it for well-scoped everyday tasks: bug fixing, routine development and polished documents, slides and spreadsheets. It also says Sonnet 5.5 can follow slide templates closely enough that decks need little editing. Effort settings run from low to max. Lower effort answers faster with fewer tokens, which suits routine work.

Anthropic is also clear about where Claude Opus vs Sonnet tips the other way. It says Opus 5.5 “remains clearly stronger” at complex, open-ended work that needs sustained judgment. That’s the honest Claude Opus vs Sonnet line: Sonnet for work you can describe clearly, Opus for work where the model has to figure out what the problem is.

Claude Opus vs Sonnet: when Opus 5.5 is worth twice the price

Opus 5.5 is cheaper than the model it replaced. Its rates are $4 and $20, down from Opus 5’s $5 and $25, and Anthropic says it costs “40% less than Opus 5 on typical workloads” at default settings. That’s Anthropic’s measurement, and it depends on default effort.

In Claude Opus vs Sonnet decisions, paying twice Sonnet’s price makes sense in a few situations:

  • Long-running coding agents working across a large codebase for hours, where one wrong turn wastes everything after it.
  • Complex debugging and architectural changes where the model has to hold many interacting parts in mind.
  • Large migrations and repository analysis. Anthropic cites a tester completing a 680,000-line migration in under a day.
  • Tasks where retries are expensive, because each failed attempt repeats a large context.

The last point is where the economics can flip. If Sonnet needs three attempts at a hard task and Opus needs one, Opus can be cheaper overall. That’s a possibility to test, not a rule: on tasks Sonnet handles first time, Opus simply costs twice as much.

Claude Opus vs Sonnet speed: what Opus Fast Mode changes

Opus 5.5 also offers Fast Mode at $8 input and $40 output, twice the standard rate. Anthropic says it delivers “up to 2.5x higher output tokens per second”. It’s the same model on a faster serving configuration: “no change to intelligence or capabilities”.

The speed-up applies to output generation, “not time to first token”. If a request spends most of its time thinking before it answers, Fast Mode won’t remove that wait. For a long streamed answer, it can. A response that streams for 60 seconds might, at best, finish streaming in about 24, at double the cost. Our analysis of how Claude’s reasoning settings affect response speed found effort level usually matters more than model choice.

Fast Mode has its own rate limits, doesn’t work with the Batch API, and is available on the Claude API, Google Cloud (Anthropic managed) and Microsoft Foundry.

Claude Fable 5.1 and the Mythos connection

Fable 5.1 is the most capable model most developers can use, and the hardest to explain. Anthropic says Fable 5.1 and Claude Mythos 5.1 are “the same model, but with different levels of safeguards”.

Mythos 5.1 isn’t generally available. It’s offered to vetted organisations through trusted access programmes: a Cyber Verification Program for defensive security teams and a Life Sciences Verification Program for researchers. Anthropic says these are currently limited to US organisations, with plans to expand.

Fable 5.1 is the version with safeguards. According to Anthropic’s Fable and Mythos 5.1 announcement, it can identify software vulnerabilities in source code but won’t develop exploits. Penetration testing, exploit generation and binary-based vulnerability scanning are redirected to Opus models. Some life-sciences research questions are also routed to Opus, though Anthropic says biology safeguards now trigger 85% less often on benign questions. Opus 5.5 has its own cyber safeguards: Anthropic says cybersecurity tasks on it are mostly rerouted to Opus 4.8.

So Fable and Mythos share underlying capability but behave differently in deployment. For most coding, research and reasoning work, the safeguards won’t come up. For security work, they will.

At $10 and $50, Fable is 2.5 times the price of Opus. Anthropic’s own guidance is to reach for it when evaluations show Opus 5.5 at higher effort still isn’t good enough. Fable 5.1 did cut its cache-read price by 75% to $0.25, and Anthropic says that lowers typical workload costs by about 25%, and highly agentic ones by up to about 45%.

Claude Opus vs Sonnet: how caching changes the economics

Prompt caching stores a stable part of your prompt, such as a system prompt, tool definitions or a repository snapshot, so later requests can reuse it. You pay a premium to write the cache, 1.25 times the input price for five minutes or twice it for an hour, and then a fraction of the price to read it.

That fraction varies, which is the hidden pricing story in Claude Opus vs Sonnet comparisons. According to Anthropic’s prompt caching docs, cache reads cost 10% of input on Haiku 5.5, 5% on Sonnet and Opus, and 2.5% on Fable. The more expensive the model, the more caching saves in percentage terms.

Here’s an illustrative agent session with assumed numbers. An agent makes 40 calls in a short burst. Each call sends the same 60,000-token repository context plus 3,000 new tokens, and returns 1,500 tokens. With caching, the context is written once to the five-minute cache and read 39 times. For simplicity, the conversation history isn’t growing between calls.

ModelWithout cachingWith cachingOutput’s share of the cached cost
Haiku 5.5$0.28$0.0741%
Sonnet 5.5$5.64$1.2249%
Opus 5.5$11.28$2.4549%
Fable 5.1$28.20$5.5454%

The formula behind it: total API cost = input cost + output cost + cache-write cost + cache-read cost. Caching cut each session by roughly three-quarters. It doesn’t touch output, so after caching, output becomes about half the bill. At that point the model that writes less, or finishes in fewer steps, wins on cost.

Caching won’t help much for one-off prompts or ones that change every time, or when calls are spread out beyond the cache lifetime. It also has a minimum: prompts under 512 tokens on these models aren’t cached.

Claude Opus vs Sonnet: rate limits and throughput

Price isn’t the only constraint in Claude Opus vs Sonnet planning. Anthropic’s rate limits cap requests per minute (RPM), input tokens per minute (ITPM) and output tokens per minute (OTPM) by usage tier:

TierHaiku, Sonnet and Opus 5.5 (each)Fable 5.x
Start4,000 RPM, 2M ITPM, 400K OTPM4,000 RPM, 500K ITPM, 100K OTPM
Build10,000 RPM, 5M ITPM, 1M OTPM10,000 RPM, 1.5M ITPM, 300K OTPM
Scale13,000 RPM, 10M ITPM, 2M OTPM13,000 RPM, 4M ITPM, 800K OTPM

Fable gets a quarter of the others’ token throughput at the Start tier, and its limit is shared between Fable 5.1 and Fable 5. Opus 5.5 and Sonnet 5.5 each have their own budget. A high-volume service could hit Fable’s output ceiling long before its budget.

One useful detail: cache reads don’t count toward input-token limits, so caching raises effective throughput as well as cutting cost. Limits also differ by organisation, so check your actual numbers in the Anthropic Console. Our guide to Claude API rate limits and concurrent request capacity goes deeper into how many parallel sessions those limits allow.

Claude Opus vs Sonnet vs Haiku vs Fable: which model to use

The right Claude Opus vs Sonnet comparison isn’t cost per million tokens. It’s cost per completed task, and ultimately cost per successful production outcome, which includes retries, human review and failures. A cheaper model that needs more attempts can cost more than a dearer one that gets it right.

ModelUse this forWhyCost consideration
Haiku 5.5Classification, routing, extraction, summaries, subagents, simple codeFastest, cheapest per token, strong for its sizeStay under 100K-token prompts, or the whole request costs 5x more
Sonnet 5.5Everyday coding, bug fixes, documents and slides, general agentsBest speed-to-intelligence balance, per AnthropicUsually the default; drop effort for routine work
Opus 5.5Long-running coding agents, complex debugging, architecture, large refactors, hard knowledge workStronger sustained judgment on open-ended tasksTwice Sonnet’s price; justified when it saves retries
Fable 5.1Demanding reasoning, long-horizon agents, complex researchMost capable generally available model2.5x Opus and lower throughput; use when evaluations show Opus isn’t enough
A starting point for choosing a Claude model. Test on your own workload before committing.

Many teams will end up using more than one. A common pattern is Opus or Sonnet planning and checking work while Haiku subagents handle the high-volume steps. Whatever the mix, test on your own workload. When it comes to Claude Opus vs Sonnet, the right answer depends on how often Sonnet gets your hardest tasks right first time.

FAQ

Claude Opus vs Sonnet: what’s the difference?

Opus 5.5 is Anthropic’s model for long-running agentic coding and complex knowledge work, at $4 input and $20 output per million tokens. Sonnet 5.5 is faster and half the price, aimed at everyday development and documents.

Claude Opus vs Sonnet: is Opus 5.5 worth the higher price?

It is for complex, open-ended tasks where it avoids retries. For well-scoped tasks Sonnet handles first time, it just costs twice as much.

Is Claude Haiku 5.5 the cheapest Claude model?

Yes, at $0.10 input and $0.50 output per million tokens for prompts up to 100,000 tokens. Longer prompts are billed at $0.50 and $2.50.

What is the difference between Claude Haiku and Sonnet?

Haiku 5.5 is the fastest and cheapest model, built for high-volume tasks like classification and routing. Sonnet 5.5 handles more complex reasoning and everyday development, at 20 times Haiku’s short-prompt price.

What is Claude Fable 5.1?

Claude Fable 5.1 is Anthropic’s most capable generally available model, priced at $10 input and $50 output per million tokens. It shares its underlying model with Mythos 5.1 but adds cybersecurity and biology safeguards.

Is Claude Mythos 5.1 publicly available?

No. Mythos 5.1 is available only to vetted organisations through Anthropic’s cyber and life-sciences verification programmes, which are currently limited to US organisations.

Does Claude Haiku charge more for long prompts?

Yes. If a Haiku 5.5 prompt exceeds 100,000 tokens, the entire request is billed at $0.50 input and $2.50 output, cached tokens included.

How much does Claude prompt caching save?

Cache reads cost 10% of the input price on Haiku 5.5, 5% on Sonnet and Opus 5.5, and 2.5% on Fable 5.1. Caching doesn’t reduce output costs, so total savings depend on how much context you reuse.

What is Claude Opus Fast Mode?

Fast Mode runs Opus 5.5 on a faster serving setup for up to 2.5x higher output speed, at twice the standard price. It doesn’t shorten time to first token or change the model’s intelligence.

Claude Opus vs Sonnet: which is best for coding?

Sonnet 5.5 suits most everyday coding and bug fixing. Opus 5.5 is better for long-running agents, large refactors and hard debugging, according to Anthropic.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

Did AI Break RSA? What DeepMind Actually Found

RSA-1024

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet.

No, AI did not break modern RSA encryption. Google DeepMind reported two new weaknesses in legacy RSA-1024, found by AI agents working under human supervision, and its researchers say the results don’t threaten 2048-bit and larger RSA.

That’s less dramatic than the headlines quoting “1,600 times faster”. It’s still a real result, arriving days after OpenAI reported AI-assisted vulnerability discovery at scale in the Linux kernel. AI agents helped produce new mathematics against a cryptosystem that has been studied for decades, and 1024-bit keys are still in use in places many organisations have stopped looking.

Key Takeaways
  • AI didn’t break modern RSA. DeepMind’s findings concern legacy RSA-1024, and its researchers say 2048-bit and larger RSA isn’t threatened by them.
  • Two different problems were solved. One forges signatures without the key; the other cuts the cost of factoring many keys in a batch.
  • The 1,600× figure is theoretical. It applies to forging when an attacker controls a 32-byte part of the signed block.
  • The 3.5× figure was measured, by reproducing an earlier attack on an already-broken benchmark key, not a fresh one.
  • The 30× figure is an asymptotic estimate for the average cost of additional keys in a batch, and no implementation exists.
  • Humans stayed in charge. Agents generated and verified proofs and wrote code under human supervision, alongside experienced cryptographers.
  • Inventory legacy keys now. Firmware signing, old certificates, SSH, VPNs and HSMs are the places to check first.

Quick Navigation


What DeepMind’s RSA-1024 research actually found

DeepMind announced the work on 6 November 2026, with Pushmeet Kohli presenting it as an advance in cryptanalysis, the science of breaking codes. It’s described in two working papers published on 5 and 6 November: “Modular Roots from a Restricted Oracle” and “Fan Factories”. Dj Dvijotham and Abhradeep Thakurta led the research. Their co-authors include the cryptographers Nadia Heninger of UC San Diego and Inria, and Emmanuel Thomé of Inria.

The two papers solve different problems. The first shows how to forge certain RSA signatures without ever recovering the private key. The second makes factoring cheaper when an attacker wants to break many RSA-1024 keys rather than one. Neither has been through peer review.

The AI agents did real work, but they didn’t work alone. The Fan Factories paper says its results came from “a two-agent AI harness: one model generated the proofs, and a second model verified them.” Its algebraic identities were checked in Lean 4, a formal proof language, while calculus steps were checked numerically. Coverage of the announcement describes the agents as working under human supervision, alongside the cryptographers on the team.

The first RSA-1024 weakness: forging signatures without the key

An RSA signature proves that a message was approved by whoever holds a private key. The signer hashes the message, wraps the hash in a fixed padding format and applies the private key. Anyone can check the result with the public key. The common padding format, PKCS#1 v1.5, is defined in RFC 8017: fixed bytes, then an identifier for the hash algorithm, then the hash itself.

Padding exists partly to stop attackers from exploiting RSA’s mathematical structure. The weakness DeepMind studied applies when an attacker can get a device to sign data they partly control. Think of a hardware security module (HSM) or signing service that will sign blocks where some bytes are chosen by whoever sends the request. The paper’s title refers to this as a “restricted oracle”: a signer the attacker can query, but only through a constrained format.

The line of research goes back to a 2007 paper by Joux, Naccache and Thomé, which showed that computing RSA roots with a signing oracle can be easier than factoring. In September, Laura Shea, Miro Haller, Adam Suhl, Heninger and Thomé turned that into a practical attack on 1024-bit RSA, using an HSM as the oracle. It took about 1,380 CPU core-years of precomputation and around 4 billion signing queries.

DeepMind’s work extends that line in two ways, according to reporting on the announcement.

  1. When the attacker controls about half the block or more, PKCS#1 v1.5 padding adds almost no protection: forging is no harder than against unpadded RSA. A 1024-bit RSA block is 128 bytes, so a 64-byte field, the size of a SHA-512 hash, is half of it.
  2. When the attacker controls much less, such as a 32-byte field the size of a SHA-256 hash, the agents produced a new algorithm. DeepMind estimates it is about 1,600 times better than the previous best method for 1024-bit keys.

That 1,600× is a theoretical estimate based on how the algorithm’s cost scales. It wasn’t demonstrated by running a full attack at that scale.

What was measured is narrower. The agents’ implementation reproduced the earlier September computation against the same, already-broken 1024-bit benchmark key. It reportedly found its first root in 391 CPU core-years, about 3.5 times less than the original, running for 3.2 days on up to 300,000 CPU cores and 16 GPUs. That’s an engineering improvement on a known result in a controlled research setting. It isn’t the cracking of a fresh key belonging to a real organisation.

Forgery and factoring are different outcomes. A forger can produce valid signatures on chosen messages but never learns the private key, and needs repeated access to the signer to do it. Factoring recovers the key itself, after which the attacker can sign and decrypt anything.

The two DeepMind findings solve different problems. One forges signatures without the key; the other cheapens factoring across a batch of keys.

The second RSA-1024 weakness: factoring many keys at once

An RSA public key contains a modulus, a large number made by multiplying two secret primes. Anyone who can factor the modulus back into its primes can rebuild the private key. RSA’s security rests on factoring being impractically expensive at the key sizes in use.

The best general method is the number field sieve (NFS). Batch factoring asks a different question: if you want to factor many numbers of the same size, can you share work between them? Earlier techniques, including Coppersmith’s factorisation factory, Bernstein and Lange’s Batch NFS, and the multiple number field sieve (MNFS), showed that expensive precomputation can make each additional factorisation cheaper.

Fan Factories gives each target number its own family, or “fan”, of number fields, all fed by a shared part of the computation. The paper works out the cheapest cost per additional number for every possible precomputation budget.

The headline result: with a precomputation budget equal to one factorisation, each further 1024-bit number costs about 1/58 of a standard NFS run, which the paper says is roughly 30 times less than MNFS. The paper is careful about what that means. The figures are leading-order estimates with smaller terms set to zero, and it states that “no fan factory has been implemented”. It also notes that memory requirements and how it compares with a well-tuned NFS in practice are open questions.

So the 30× figure is about the average cost of additional keys in a batch, under asymptotic assumptions. It doesn’t mean any single RSA-1024 key can be factored 30 times faster, and it hasn’t been demonstrated against real keys. It matters for security teams because it changes the economics for an attacker targeting a large population of legacy keys. One expensive setup could then make each extra key far cheaper to break.

What the 1,600× and 30× RSA-1024 numbers really mean

The two figures describe different problems, different kinds of evidence and different attackers. Neither should be read as a general speed-up for breaking RSA.

FigureWhat it applies toKind of evidenceWhat it doesn’t mean
About 1,600×Forging 1024-bit signatures when an attacker controls a small, 32-byte part of the signed blockTheoretical estimateThat RSA signatures can generally be forged 1,600 times faster
About 3.5×Reproducing September’s attack on an already-broken 1024-bit benchmark keyMeasured, in a research settingThat a fresh, deployed key was cracked
About 30×Average cost of each additional 1024-bit key in a batch, against MNFSAsymptotic estimate, no implementationThat one RSA-1024 key can be factored 30 times faster

Adding the two together, or describing them as “1,600 times faster at breaking RSA”, gets both wrong. The signature figure needs an attacker with ongoing access to a signer. The factoring figure needs a large precomputation and a batch of targets.

RSA-1024 vs RSA-2048: why bigger keys are a different story

The number in “RSA-1024” is the size of the modulus in bits. Each added bit makes factoring harder, but not in a straight line: the cost of the number field sieve grows sub-exponentially with key size. NIST’s key-management guidance, SP 800-57, puts RSA-2048 at about 112 bits of security, the current minimum for most uses. NIST’s transition guidance already disallows generating new RSA signatures with keys shorter than 2048 bits, and allows verifying 1024-bit signatures only for legacy use.

The Fan Factories authors state: “Our results do not threaten deployed cryptosystems today that are based on 2048-bit and larger RSA.” That’s a statement about these particular findings. It isn’t a statement that RSA-2048 is safe from everything, and several other risks deserve attention:

  • Implementation flaws, such as weak padding checks, can break RSA at any key size.
  • Poor key generation and weak randomness have produced real keys that share primes and can be factored instantly.
  • Side-channel attacks extract keys from timing, power use or faults rather than from the maths.
  • Protocol and configuration mistakes, such as a signer that accepts attacker-controlled raw input, create exactly the oracle these attacks need.
  • Quantum computing threatens all RSA key sizes in the long run. NIST’s 2024 draft transition plan, IR 8547, proposed deprecating 112-bit RSA after 2030 and disallowing RSA after 2035. A final version was published in October 2026, so check it for current dates.

The September HSM paper adds a further warning. Its authors estimate that RSA with a signing oracle is 15 to 30 bits weaker than factoring-based estimates suggest, across 1024- to 4096-bit keys. That doesn’t break RSA-2048. It does mean that systems letting outsiders request raw RSA signatures deserve scrutiny at any key size.

Where RSA-1024 may still be hiding

RSA-1024 has been disallowed for new signatures under NIST guidance since the 2010s, yet it lingers in systems built when it was standard and rarely touched since. Not every old system uses it, so each one needs checking. Places worth looking include:

  • Firmware and code signing. Devices that verify updates with a key burned into hardware can’t easily change it.
  • Embedded and IoT devices, industrial controllers and network gear with long service lives.
  • Old internal certificates and private certificate authorities that never went through public-CA key-size rules.
  • SSH host and user keys generated years ago and carried between servers.
  • Older VPN appliances and their management certificates.
  • Hardware security modules, especially older models or partitions configured for raw RSA signing, which is the oracle these attacks exploit.
  • DNS and email signing. In a Sectigo podcast discussion of the September HSM research, the hosts cited figures suggesting 1024-bit RSA is still common in DNSSEC zone-signing keys and in DKIM email-signing keys. Those are their estimates, not a formal survey.
  • Archived applications and long-lived machine identities, such as service accounts and API clients, whose keys were never rotated.

To find them, start with certificate inventories and scanning tools, which report key length for every certificate they see. Server and device configurations, HSM key listings and code-signing setups need checking directly. Standard tools show key size: OpenSSL prints it for certificates and keys, and ssh-keygen -l shows it for SSH keys. Only test systems you own or are authorised to assess.

Start with an inventory. Not every old system uses RSA-1024, so verify key lengths before planning replacements.

An RSA-1024 checklist for security teams

None of this needs panic. It needs an inventory and a plan. Follow your organisation’s cryptographic policy, applicable standards and vendor guidance throughout.

  1. Inventory RSA key lengths across certificates, keys and cryptographic services.
  2. Flag every 1024-bit RSA key and certificate, including expired ones still trusted somewhere.
  3. Check firmware-signing and code-signing configurations, including keys embedded in shipped devices.
  4. Review SSH and VPN configurations, host keys, user keys and appliance certificates.
  5. Inspect HSM settings, especially any raw RSA signing modes and the applications that can reach them.
  6. Identify dependent devices and applications that will break when a key changes.
  7. Plan migration to approved configurations, such as RSA-2048 or larger, or elliptic-curve keys where supported, with post-quantum algorithms in mind.
  8. Test replacement keys before retiring old ones.
  9. Review certificate chains and trust stores, so legacy roots and intermediates are removed too.
  10. Make cryptographic inventory a recurring review, not a one-off project.

For organisations already on RSA-2048 or larger, these findings alone aren’t a reason to replace every key. They are a reason to confirm that’s actually what you have.

AI is entering mathematical security research

The DeepMind papers arrive alongside other AI-assisted security results, but they aren’t the same kind of achievement.

OpenAI’s agents found 948 distinct Linux kernel privilege-escalation flaws in one run. That’s vulnerability discovery and exploit development: finding mistakes in code. VicOne reported 28 AI-assisted zero-day findings in robotics tooling, which we covered in our look at robotics security risks. Google says its Gemini 4 Carbon model scores strongly on finding, proving and fixing vulnerabilities. All three are about software that was written wrong.

Cryptanalysis is different. RSA-1024 wasn’t badly coded; the DeepMind work changes what’s mathematically possible against it, though the forgery attack still needs a signer that accepts attacker-shaped input. That’s closer to research mathematics than to bug-hunting, and it rests on proofs and complexity analysis rather than crash reports.

What connects them is speed. AI agents are compressing work that used to take specialists months, whether that’s auditing code or exploring number-field constructions. In each case, though, humans set the direction, checked the results and decided what to publish. The Fan Factories paper’s own framing is that its significance lies in how quickly AI-assisted research can advance a slow-moving field.

That’s the reason to pay attention. Cryptographic assumptions that held for years can now be tested faster. RSA-1024 was already obsolete; this research makes keeping it around harder to justify.

FAQ

Did Google DeepMind break RSA encryption?

No. DeepMind reported two weaknesses in legacy 1024-bit RSA, and its researchers say the results don’t threaten 2048-bit and larger RSA.

What is RSA-1024?

RSA-1024 is RSA public-key cryptography using a 1024-bit modulus. NIST disallows it for generating new signatures and treats it as legacy.

What did DeepMind’s AI agents discover about RSA-1024?

A faster way to forge some RSA-1024 signatures when an attacker can query a signer, and a cheaper way to factor many RSA-1024 keys in a batch.

What is the 1,600× RSA improvement?

It’s a theoretical estimate of how much better the new forgery algorithm is than the previous best method, when an attacker controls a 32-byte part of the signed data. It wasn’t demonstrated at that scale.

Does the 30× factoring improvement mean RSA keys can be cracked 30 times faster?

No. It’s an estimated reduction in the average cost of each additional 1024-bit key in a large batch, after a big shared precomputation.

Is RSA-2048 affected by DeepMind’s findings?

The researchers say their results don’t threaten 2048-bit and larger RSA. Other risks, such as implementation flaws and quantum computing, still apply.

What is the difference between RSA signature forgery and key factoring?

Forgery produces valid signatures without learning the private key and needs access to a signer. Factoring recovers the private key itself.

Where are RSA-1024 keys still used?

Mostly in legacy systems: firmware and code signing, embedded devices, old internal certificates, SSH and VPN setups, older HSMs, and some DNS and email signing keys.

Should organisations replace their RSA-2048 keys?

Not because of this research alone. Follow your migration plan and NIST’s post-quantum transition guidance.

How did AI agents contribute to the cryptography research?

They explored mathematical approaches, generated and checked proofs, and wrote the implementation used in the reproduction, under human supervision.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

Model Distillation Explained: When AI Learning Becomes Extraction

Model Distillation

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court.

A support team trains a small, cheap model to answer routine questions by learning from its own large model. A lab allegedly runs thousands of fake accounts to harvest a rival’s reasoning, then trains on the results. Both are model distillation. The technique is the same. What separates them is permission.

That gap is now a policy fight. In September 2026, three US agencies accused six Chinese AI companies of “industrial-scale” distillation of American models, and China rejected the claims. In October, Anthropic said new safeguards had cut the data distillers harvest from its platform by 90 to 99%.

Key Takeaways
  • Model distillation is a 2015 technique built for efficiency. Hinton, Vinyals and Dean used soft targets to compress large models into small ones.
  • A student learns behaviour, not weights. It imitates the teacher’s outputs on the inputs it sees and rarely matches it everywhere.
  • Access is what differs. Logit and feature distillation need internal access; API distillation uses only outputs, including reasoning where exposed.
  • The US advisory is an allegation, not a ruling. NSA, FBI and CISA named six Chinese companies on 8 September 2026, and China rejected the claims.
  • Anthropic’s 90 to 99% cut is platform-specific. It describes data harvested from Claude, measured by Anthropic, not global distillation.
  • Terms of service draw the commercial line. Google and OpenAI both bar using outputs to build competing models, but breaching terms isn’t automatically theft.
  • The economics still favour distillation. Cheaper inference, lower latency and on-device deployment explain why it’s everywhere.
  • Buyers should ask about provenance. What teachers and data a model learned from now affects licensing and supplier risk.

Quick Navigation


Model distillation began as an engineering fix

The idea was formalised in a 2015 paper by Geoffrey Hinton, Oriol Vinyals and Jeff Dean, “Distilling the Knowledge in a Neural Network”. Ensembles of many models were more accurate than any single one, but too slow and expensive to deploy. They wanted to “compress the knowledge in an ensemble into a single model”.

Their answer was to train a small student on the probabilities a large teacher assigns to every possible answer, as well as on the correct label. Those probabilities, which the paper calls “soft targets”, carry information a plain label throws away. A teacher that says an image is 90% a 2, 9% a 7 and 1% a 3 is telling the student which mistakes are reasonable.

On MNIST, a small network trained normally made 146 test errors. The same network trained on the teacher’s soft targets made 74, close to the large model’s 67. On a commercial speech system, a single distilled model recovered most of the accuracy gain of a 10-model ensemble.

Distillation isn’t the same as the other ways of shrinking a model. Quantisation stores the same model’s weights in fewer bits. Pruning removes weights or whole parts of a network. Fine-tuning adjusts an existing model on new data. Distillation trains a different, usually smaller, model to imitate the behaviour of a larger one. The methods are often combined.

How model distillation actually works

Strip away the maths and model distillation has four steps.

  1. Choose inputs. Collect prompts or examples that cover the tasks the student needs to handle.
  2. Ask the teacher. Run each input through the teacher and record what it produces: probabilities, answers, sometimes step-by-step reasoning.
  3. Train the student. Optimise the smaller model to match those outputs.
  4. Evaluate. Test the student against the teacher and, more importantly, against the real task.

The paper’s key trick is temperature. A model’s raw scores, called logits, pass through a softmax function to become probabilities. Dividing the logits by a temperature above 1 flattens the distribution, so the small probabilities on wrong-but-plausible answers become visible. The student learns from that softer distribution, usually alongside the true labels.

A simple example: a teacher reading the review “Not bad, but not worth the price” might assign 60% negative, 35% neutral and 5% positive. A plain label just says “negative”. The soft version tells the student the review is mixed, which helps it handle similar cases later.

Two limits matter. The student never receives the teacher’s weights; it learns some of the teacher’s behaviour on the inputs it was shown. And it won’t reproduce everything. Results depend on the teacher, the inputs, the training objective, the student’s size and architecture, and what you evaluate it on. A small student can match a large teacher on a narrow task and fall short elsewhere.

The student learns from what the teacher produces, not from the teacher's parameters.

Model distillation methods, from logits to API outputs

“Distillation” covers several techniques that need very different access to the teacher, which is exactly what the current dispute turns on.

MethodWhat the student learns fromAccess needed to the teacherTypical authorisation context
Logit-basedFull probability distributions (soft targets)Internal outputs, usually your own modelInternal, or under licence
Response-basedGenerated answers as input-output pairsOnly the outputs, via a product or APIInternal, licensed, or governed by API terms
Feature-basedIntermediate representations inside the networkThe model’s internals, effectively the weightsInternal or open-weight teachers
OnlineA teacher and student trained togetherFull training controlInternal
Self-distillationThe model’s own earlier outputs or stronger settingsThe same modelInternal
API-based black-boxOutputs, including reasoning text where exposedA public API, at scaleSet by the provider’s terms, and disputed when terms forbid it

Response-based distillation is the form most relevant to large language models today. A developer prompts a strong model, saves the answers, and fine-tunes a smaller model on them as synthetic training data. If the teacher shows its step-by-step reasoning, the student can also learn how each answer was reached.

API-based distillation never touches the teacher’s weights, but it can still capture a lot. Anthropic reported that a model distilled on full reasoning transcripts from Claude scored 80.4% on the SWE-bench Verified coding benchmark, against 71.8% when trained only on summarised transcripts. That’s a company-run test, but it shows why labs now guard their models’ reasoning more closely than their answers.

Why AI companies are fighting over model distillation

What the US advisory alleges

On 8 September 2026, the NSA, FBI and CISA published joint advisory AA26-251A, “China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies”. It named DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI.

According to summaries by the Cloud Security Alliance and The Next Web, the agencies alleged campaigns against versions of Claude, GPT, Gemini and Grok from at least late 2024 to mid-2026, totalling billions of tokens across millions of exchanges. The methods described include fraudulent accounts with obscured metadata, bulk commercial subscriptions, jailbreak prompts designed to expose hidden reasoning, and “transfer stations”: grey-market API proxies that resell access and get around regional blocks. The agencies also said the campaigns ran “likely with Chinese government awareness”, and called distillation “the core, not merely a supplement” of these companies’ development.

The advisory isn’t a court finding. As reported, the activity it describes is querying deployed models at scale; none of the summaries we read mention access to model weights. The agencies recommended that AI providers detect anomalous usage, share threat intelligence across the industry, and consider subtly altering responses to suspected distillers.

China’s response

China rejected the allegations. In a statement to the Associated Press, reported by Al Jazeera, the Commerce Ministry accused the US of seeking a “monopoly of the AI industry”, said distillation is commonplace in the industry including among US companies, and warned of “resolute countermeasures”. Foreign Ministry spokesperson Mao Ning urged the US to “refrain from making unfounded accusations or smears”.

The named companies didn’t respond publicly to requests for comment in the days after the advisory, according to The Next Web and Al Jazeera. None has admitted the conduct described.

What Anthropic’s September report claims

Anthropic, which is a party to this dispute, made its own allegations two days later. Its September 2026 threat intelligence report described campaigns it attributed to seven China-based labs. As summarised in independent coverage, the largest was attributed to Alibaba: more than 151 million exchanges between May and July, which Anthropic called “the largest distillation attack we have ever measured”. It also attributed more than 23 million exchanges to Moonshot AI and about 12 million in 14 days to DeepSeek, and named Zhipu, Xiaomi, SenseTime and MiniMax.

Anthropic said labs reached Claude through networks of fake accounts paid for with false identities or stolen cards, and through proxy services that resell access and sometimes sell the saved exchanges on. It described a “cross-session replay” technique: saving a signed reasoning token from one response, then prompting Claude in a new session to rebuild reasoning that would otherwise have been summarised.

The most serious allegation concerns Moonshot. Anthropic said that in one 10-day period, Moonshot silently forwarded nearly 300,000 requests from its own Kimi customers to Claude through 5,380 fraudulent accounts, and served Claude’s answers as Kimi’s. If accurate, that’s a data-governance problem as well as an IP one. Kimi users’ prompts, some containing sensitive data according to Anthropic, went to a provider they hadn’t chosen. Anthropic says it doesn’t know whether those customers were told.

These are Anthropic’s findings from its own telemetry. They haven’t been independently verified, and the named companies hadn’t published detailed responses when we checked.

Anthropic’s October defences against model distillation

On 12 October, Anthropic published an update on its distillation defences. Its headline claim: “early evidence suggests that these methods have reduced the amount of data harvested by distillers by around 90 to 99%”. It also said the number of reasoning tokens extracted by distillers “is consistently 10 to 100 times lower than it was before”.

Read those numbers carefully. Anthropic estimates extracted tokens “on our own platform”, so they describe what it observes on Claude. They don’t show that global distillation fell by 90 to 99%, and they don’t cover other providers, data resellers or transcripts harvested before the defences existed. Anthropic doesn’t describe the estimation method in detail.

The safeguards fall into three groups:

  • Controlling where reasoning goes. A feature called preserved thinking stops new API accounts, created from 31 August 2026, from editing earlier context. Anthropic also stopped earlier, less protected models from reading newer models’ reasoning, and with Claude Sonnet 5.5, limited reasoning transcripts to the organisation that made the request. That’s aimed squarely at cross-session replay.
  • Detecting and blocking extraction. A two-stage classifier based on Anthropic’s constitutional classifier research screens for extraction attempts. Anthropic puts its false-positive rate at under 0.1%.
  • Raising the cost of trying again. Accounts that repeatedly attempt extraction face stricter limits or bans. Since 24 September, Anthropic has also charged for requests its safeguards block.

Anthropic acknowledges trade-offs. Preserved thinking required some developers to update their integrations. A false-positive rate under 0.1% still means some legitimate requests get blocked, and since 24 September, billed. Anthropic says it has “turned away meaningful revenue and trillions of tokens’ worth of paying traffic”. It also concedes the goal of not affecting legitimate users hasn’t been fully met, and calls distillation “a cat-and-mouse game”. Researchers who study model reasoning may also find the limits get in their way.

Anti-distillation is becoming part of platform security, alongside fraud and abuse prevention. Reasoning traces in particular are now treated as assets to protect.

When model distillation becomes a question of authorisation

The five scenarios below use near-identical techniques. What separates them is access, permission and the terms that apply.

ScenarioWho owns the teacherPermissionMain questions
1. Internal distillationYouImplicitMostly engineering quality
2. Licensed distillationAnother providerExplicit, by contractScope of the licence
3. Research distillationVariesDepends on data rights and termsWhether the terms and data rights cover the research use
4. Third-party API distillationAnother providerGoverned by API termsCompetitive-use clauses
5. Covert large-scale extraction (alleged)Another providerNone, with controls bypassedFraud, terms breaches, possibly trade secrets

Scenario 1 is uncontroversial; labs routinely distil their own large models into smaller ones. Scenario 2 is the same with a contract.

Scenario 4 is where most real ambiguity sits. Major providers restrict it in their terms. Google’s service terms for AI/ML services say customers won’t use generated output “to develop a similar or competing product or service”, and separately prohibit using output to “create or improve models similar to a Google Model”. OpenAI’s terms of use prohibit using output “to develop models that compete with OpenAI”. Those are contract terms. Breaking them can mean suspended accounts or a breach-of-contract claim, but whether it amounts to theft is a separate question.

The legal picture is unsettled. Copyright protection for AI-generated outputs is uncertain in many jurisdictions. Trade-secret claims may depend on whether a provider took reasonable steps to keep material like reasoning traces secret, which is one reason labs now hide or summarise them. Rules also differ between the US, China and the EU. Nothing here is legal advice. Anyone planning to train on another provider’s outputs needs a lawyer to read the specific terms.

Scenario 5, as the advisory and Anthropic describe it, is different in kind. Fake identities, stolen payment cards, proxy resale and covert relaying of customers’ prompts aren’t distillation techniques. They’re ways around controls, and they raise fraud and privacy questions whatever anyone thinks about training on outputs.

The technique is the same on every path. What changes is authorisation and the terms that apply.

What model distillation means for AI buyers

For a company choosing a model, the dispute turns into a provenance question. If a model was trained substantially on another provider’s outputs in breach of its terms, the buyer could face uncertainty about licensing, continued availability or sanctions in some markets. That’s an assessment for each buyer, not a conclusion about any named model.

Our comparison of Chinese open-weight models found that quality at the top has converged, so licensing, hardware and customer identity now drive the choice. Provenance belongs on that list. Ask suppliers what data and teacher models a model was trained on, whether third-party outputs were used and under what terms, and what indemnities they offer.

Distilled models also raise the same trust questions as any modified model. A student can inherit a teacher’s biases or safety gaps, or lose safeguards the teacher had. As our look at editing AI models through machine unlearning argued, a changed model needs its own behavioural and security testing. Don’t assume it inherits the original’s evaluation.

The economics of model distillation

The controversy doesn’t change why organisations distil. Smaller models are cheaper and faster, need less memory, run on phones or on-premises hardware, and cut dependence on expensive frontier APIs.

Here’s an illustrative example. Every number is an assumption, not a measured figure. A company answers 1 million routine support enquiries a month with a large teacher model, at an assumed $0.02 per enquiry: $20,000 a month. It decides to distil a small student:

Step (illustrative)AssumptionCost
Generate training data200,000 teacher answers at $0.02 each$4,000
Train the studentFine-tuning compute, assumed$3,000
Evaluate and reviewEngineer time and test runs, assumed$8,000
One-off total$15,000
Run the student$0.003 per enquiry, assumed$3,000 a month

On those assumptions, the student saves $17,000 a month and pays back its one-off cost within the first month. But the example only works if the student is good enough. If it handles 80% of enquiries well and the rest must go back to the teacher, monthly costs rise to about $7,000, still well below $20,000. If quality drops and customers notice, the savings may not be worth it.

The example uses the company’s own teacher, which is scenario 1. Generating the same 200,000 answers from a third-party API to build a competing product could breach that provider’s terms. The economics are identical. The risk isn’t.

Open weights change the maths again. When a teacher is released under a permissive licence, distilling it can be explicitly allowed. As our coverage of Inkling 975B’s open weights noted, permissive weights can support training a smaller student, subject to the licence.

What comes next for model distillation

Expect platform controls to keep tightening. Hiding or summarising reasoning, binding reasoning to the organisation that requested it, detecting extraction patterns and suspending suspicious accounts are now standard tools, and the advisory encourages providers to share intelligence about distillers. The awkward recommendation is subtly altering responses to suspected distillers, which risks degrading answers for legitimate users caught by mistake.

Three open questions will shape the field. Can providers protect reasoning without making their models less useful to researchers and developers? Will courts treat bulk API extraction as a contract dispute, a trade-secret case or something else? And will governments act on the advisory through sanctions or procurement bans, given China’s warning of countermeasures?

The technique itself isn’t in question. Model distillation is how much of the industry turns expensive models into practical ones. The fight is over access, permission and what a contract allows.

FAQ

What is model distillation in AI?

Model distillation is a training technique in which a smaller “student” model learns to imitate a larger “teacher” model’s outputs. It’s used to make models cheaper, faster and easier to deploy.

How does knowledge distillation work?

The teacher produces outputs, such as probability distributions or answers, for a set of inputs, and the student is trained to match them. Softened probabilities, called soft targets, carry more information than single correct labels.

What is the difference between model distillation and fine-tuning?

Fine-tuning adjusts an existing model on new data. Model distillation trains a separate, usually smaller, model to copy another model’s behaviour, often by fine-tuning it on the teacher’s outputs.

Is model distillation the same as model compression?

It’s one form of model compression. Quantisation and pruning shrink the same model, while distillation trains a new, smaller one.

Can a smaller AI model learn from a larger model?

Yes, on the tasks it’s trained for. A distilled student can come close to its teacher on narrow tasks but usually falls short on broad ones.

It depends on the provider’s terms and the jurisdiction. Many providers, including Google and OpenAI, prohibit using outputs to build competing models, so get legal advice before trying it.

Why are AI companies concerned about distillation attacks?

Because rivals can capture expensive capabilities, especially reasoning, by querying a model at scale. Labs also say covert campaigns rely on fraud and can expose customers’ data.

What did Anthropic announce about distillation defences in October 2026?

On 12 October, Anthropic said new safeguards cut the data harvested by distillers on its platform by around 90 to 99%. The measures include limits on where reasoning can go, extraction classifiers and penalties for repeat attempts.

How does model distillation reduce AI inference costs?

A smaller student needs less compute and memory per request than its teacher. For high-volume, repetitive tasks, that can cut running costs substantially once the one-off training cost is paid.

What should businesses check before deploying a distilled model?

Check where the training data and teacher outputs came from, the licence and terms that applied, and the model’s own safety and quality testing. Ask the supplier about indemnities.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

Visa Tested AI Shopping Agents. 42.8% of Runs Failed, and Many Still Bought

AI shopping agents

Last verified: 7 November 2026. Benchmark figures are from Visa’s announcement. Model rankings are from Fortune.

A shopper asks for a TV. The agent finds a well-reviewed 65-inch set at a fair price and buys it. It never asked whether the TV needed to work with a child’s games console, or whether the shopper needed a 30-day return window. The purchase looks reasonable. It’s also wrong.

That’s the failure Visa set out to measure. On 5 November 2026, Visa published results from its new Agentic Commerce Benchmark, which put AI shopping agents built on 22 models through 15 shopping tasks. The agents failed 42.8% of test runs. In more than half of those failures, they decided to buy anyway.

Key Takeaways
  • AI shopping agents failed 42.8% of Visa’s 990 test runs, with model pass rates ranging from 28.9% to 82.2%.
  • Requirement discovery was the clearest dividing line. Models that uncovered the most hidden needs passed 70.2% of runs, against 44.4% for those that uncovered the fewest.
  • 54% of failed runs still ended in a purchase decision, so many agents acted without enough information.
  • Consistency is the bigger problem. All three attempts passed for only 34.2% of model and scenario pairs.
  • Cheaper per run isn’t cheaper per success. Once wrong purchases have to be unwound, a higher pass rate can outweigh a higher model price.
  • Consumers want control as well as accuracy. In FIS’s U.S. survey, half want to approve every AI transaction and 58% want a refund guarantee.
  • Visa’s first round didn’t test checkout or payment. It measures discovery and decisions, not payment readiness.

Quick Navigation


What Visa actually asked AI shopping agents to do

The first round tested 22 AI models from 12 labs on 15 shopping scenarios, with three attempts per model per scenario. The products were everyday purchases: a TV, a laptop and a personal-care appliance (Fortune describes it as a hair appliance).

The design choice that matters is that the shopper didn’t say everything up front. According to Fortune’s report, the shopper was itself an agent, given a list of required attributes, which volunteered only some of them. For a TV, Visa’s example requirements were budget, format compatibility, HDR10+ support and gaming capability. Fortune’s examples included compatibility with a child’s console, a 30-day return window and Dolby Vision.

A run passed only if the agent did two things. It had to uncover every requirement defined for that task, and it had to make the correct decision: buy a suitable product, or buy nothing if nothing fit. Visa says it added the second condition “to prevent lucky guesses”. An agent that happens to pick the right TV without establishing why still fails.

Visa says this is the first agentic commerce benchmark to require both. It’s a strict rule, and the right one.

What the first round didn’t test matters just as much. Visa’s release says it “will extend testing to checkout, payment, and order placement” in future rounds. So the “purchase” in these results is the agent’s decision to buy, scored by the benchmark, not a completed order or payment. Visa’s release doesn’t describe the product catalogue or execution environment further, and the whitepaper it mentions wasn’t linked when we checked.

How often AI shopping agents failed, and what each number measures

Visa’s figures are easy to misread, because several of them use different denominators.

MeasurementResultWhat it actually counts
Overall pass rate57.2%Share of all test runs that passed
Overall failure rate42.8%Share of all test runs that failed
Best-performing model82.2%That model’s share of runs passed
Worst-performing model28.9%That model’s share of runs passed
All three attempts passed34.2%Share of model and scenario pairs where every attempt passed
Failed runs ending in a purchase54%Share of failed runs, not of all purchases
Top five at uncovering hidden requirements70.2%Average pass rate of those five models
Bottom five at uncovering hidden requirements44.4%Average pass rate of those five models
Five most expensive models per run67.1%Average pass rate of those five models
Five least expensive models per run50.2%Average pass rate of those five models

The structure implies 990 runs in total: 22 models × 15 scenarios × 3 attempts. That’s our arithmetic, not a figure Visa published, but the reported percentages fit it. Each model had 45 runs, so 82.2% is 37 passes and 28.9% is 13. Across all models, roughly 424 runs failed, and about 229 of those ended in a purchase decision.

Visa says the results aren’t a claim that agents aren’t ready for commerce, only that consistency and reliability remain challenges. That’s fair: 82.2% is capable, and 28.9% is not.

Which models did best

Visa’s release doesn’t name the 22 models. Fortune reported that agents built on Google’s Gemini and on a Meta model tied for first at 82%, a Claude agent placed third at 76%, and an OpenAI agent placed sixth at 64%. The Next Web and others have repeated those rankings, citing Fortune.

Reported rankAgentPass rateSource
Joint 1stAgent built on a Google Gemini model82%Fortune
Joint 1stAgent built on a Meta model82%Fortune
3rdClaude agent76%Fortune
6thOpenAI agent64%Fortune

Fortune’s text gives version names we couldn’t match to published models, so we’ve left them out. These are agents built on particular model versions at a particular time, not verdicts on each lab. With 45 runs per model, the gap between 82% and 76% is about three runs.

Why the best AI shopping agents asked better questions

The most useful finding in the benchmark isn’t the failure rate. It’s this: the five models that uncovered the most hidden buying factors through conversation passed 70.2% of runs. The five that uncovered the fewest passed 44.4%.

Shopping involves several distinct jobs. Product search finds items that match a query, and recommendation ranks them. Preference discovery works out what the shopper cares about, and constraint identification separates hard requirements from nice-to-haves. The purchase decision comes last.

Search and ranking are mature. Visa’s results suggest the middle two are where agents struggle. A shopper says “a good 65-inch TV under $1,000”. But if the shopper’s child plays on a console that needs a particular HDMI feature, if the shopper owns a streaming box that only outputs one HDR format, or if they need delivery before a date, the best-reviewed TV on the list can still be the wrong one.

That doesn’t mean more questions are better. A shopper facing 15 questions before seeing a TV will leave. The skill is asking the few that change the decision: compatibility with what the shopper owns, hard budget limits, return conditions, timing. Visa’s metric measures requirements uncovered, not conversation length.

An agent should only buy once the shopper's requirements are satisfied. Otherwise it should ask another question or decline.

When AI shopping agents buy anyway

Visa reported that about 54% of failed runs still ended with the AI making a purchase. Visa describes two ways that happened: the agent recommended a product that didn’t meet the shopper’s identified requirements, or it bought before uncovering all of them.

The first is a matching failure: the agent knew what was needed and chose badly. The second is a judgment failure: it acted without enough information. The second is more worrying, because the agent didn’t recognise its own uncertainty. A careful sales assistant who isn’t sure asks another question. These agents committed.

Be precise about what the 54% means. It isn’t the share of all purchases that were wrong. It’s the share of failed runs that ended in a decision to buy, roughly 229 of about 424. The other 46% ended without a purchase, a better way to fail because nothing has to be unwound.

In this benchmark, a bad purchase decision stopped at the decision, since order placement isn’t tested yet. In a live deployment, the same decision moves through stages, each more expensive to reverse:

StageWhat has happenedWhat it takes to reverse
Incorrect recommendationThe agent suggested the wrong productNothing, if the shopper notices
Purchase decisionThe agent decided to buyNothing yet, if a human confirms first
Order placedThe merchant has the orderA cancellation, possibly a fee
Payment completedMoney has movedA refund or chargeback
Product deliveredThe wrong item is in the houseA return, shipping, restocking and support time

That’s why the 54% figure matters more as agents gain autonomy. Most shopping assistants today stop at the first or second row. Visa’s later rounds, and the industry’s agent payment products, aim lower down, where every failed decision becomes a return, a support call or a dispute. As Fortune noted, who bears liability for an agent’s mistaken or fraudulent purchase is still an open question.

Why AI shopping agents can’t repeat a good decision

Here’s the number that should worry developers most. Across all models and scenarios, all three attempts passed only 34.2% of the time.

That’s a consistency measure, not overall success. In about two-thirds of model and scenario pairs, at least one of the three attempts failed.

A quick check shows that failures weren’t purely random. If every run were an independent coin flip with a 57.2% chance of passing, all three attempts would pass about 18.7% of the time. The observed 34.2% is higher, which suggests some model and scenario pairs are reliably solved while others fail more often. That’s our arithmetic on Visa’s averages, and it’s only indicative, since pass rates vary by model.

Variation between runs isn’t automatically a fault. As our explainer on LLM determinism notes, reproducibility isn’t correctness. An agent can phrase questions differently or suggest a different but equally suitable TV and still pass. What matters is whether the final decision stays correct.

In a shopping conversation, small differences compound. A different first question leads to a different second one, and the agent may never get round to return policy. Sampling, prompt sensitivity, the order of tool calls and the products a search happens to return can all shift the outcome. Academic work points the same way: the τ-bench paper introduced a pass^k metric because agents that succeed on one attempt often fail on repeats. In its retail domain, pass^8 was below 25%.

A shopper doesn’t experience the average. They experience one run, and can’t tell whether they got the good one.

The cost of an AI shopping agent getting it wrong

Visa also compared model cost with performance. The five models with the highest average cost per run passed 67.1% of runs, and the five cheapest passed 50.2%. Visa didn’t publish per-model prices with the release, and the figures are averages across groups, so they can’t be divided into exact cost comparisons for individual models.

They do raise the right question. The useful measure isn’t cost per run but cost per successful task:

Cost per successful task = total execution cost ÷ number of successful tasks

For a single agent, that’s the cost per run divided by its pass rate. Our guide to LLM cost per task sets out the same method for API work in general.

Here’s an illustrative example with made-up numbers. Agent A costs $0.20 a run and passes 50% of the time. Agent B costs $1.00 a run and passes 80% of the time.

Measure (hypothetical)Agent AAgent B
Cost per run$0.20$1.00
Pass rate50%80%
Model cost per successful task$0.40$1.25
Wrong purchases per run (failures × 54%)0.270.11
Total cost per successful task, at $15 to unwind each wrong purchase$8.50$3.28

On model cost alone, Agent A is three times cheaper. Once a hypothetical $15 cost to handle each wrong purchase is included, through returns, refunds and support time, Agent B is less than half the price per correct outcome. The $15 is an assumption chosen only to show the effect; real figures vary widely by product and retailer. We’ve also applied Visa’s 54% figure to both agents, though in practice it may differ by model.

The expensive agent doesn’t always win. With human approval before every purchase, failures cost far less and a cheaper model may be right. But API spend is the most visible cost, not the largest.

API spend is the cost you can see. Returns, support and lost trust can cost far more.

Shoppers will take advice from AI, not hand over their wallets

Consumer research shows the same divide between help and authority. Visa’s own Trust Index, a Harris Poll survey of 2,065 U.S. consumers carried out in May and published in September, found that 72% had used an AI assistant. Only 23% trusted generative AI to handle payment transactions on their behalf.

The FIS 2026 Consumer Pulse Survey, released on 5 November, explains where that trust comes from. FIS and Kantar surveyed 2,000 U.S. adults online between 16 and 30 September 2026:

  • 50% want to approve every transaction an AI assistant makes.
  • 57% are comfortable with AI flagging or freezing suspicious charges without asking first.
  • 58% chose a refund guarantee for mistakes as a top-three condition for trusting AI with money.
  • 56% chose access to a human who can review or override decisions.

Both surveys cover U.S. adults only, and FIS notes its data are unweighted and self-reported. Within that limit, people are more comfortable with AI that protects their money than AI that spends it. What reassures them isn’t mainly accuracy. It’s control, a human to appeal to and a way to undo mistakes.

Even an agent that passed every run wouldn’t meet those conditions on its own. Benchmarks measure accuracy; trust also needs accountability.

What a trustworthy AI shopping agent looks like

The distinction worth holding onto is between being able to buy something and being authorised to. An agent connected to a payment method can technically complete a purchase. Whether it should is a separate decision that belongs to the shopper and the payment system, not the model.

It helps to think about reliability in four dimensions. This is our framework, built from the research above, not an industry standard:

DimensionQuestion it answersCovered by Visa’s first round?
Discovery accuracyDid the agent understand what the shopper needs?Yes
Decision accuracyDid it choose the right product, or decline?Yes
Execution reliabilityDid it carry out the authorised action correctly?No, planned
Financial accountabilityCan a mistake be traced, attributed and reversed?No

Visa’s first round measures the top two rows. The bottom two depend on agent design and payment infrastructure, and no single safeguard covers them. A confirmation prompt helps, but a shopper approving dozens of purchases a week stops reading them.

A layered design spreads the job across several points. The model handles discovery and decides when it lacks information. The application enforces limits the model can’t override: spending caps, approved merchants and product categories, and approval thresholds above which a human must confirm. The payment layer adds its own controls. Visa Intelligent Commerce, announced in 2025, swaps card details for tokenised credentials that authorised agents can use within consumer-set limits. After the purchase, transaction logs tied to a specific agent identity make it possible to see what happened, and revocable permissions let the shopper switch an agent off.

This is the same principle we covered in AI agent authorization: a login proves access, not permission. An agent should get narrow, logged, revocable rights, enforced where money actually moves rather than in the agent’s instructions.

What Visa’s benchmark doesn’t tell us

Visa’s benchmark is a useful early measurement. It’s still a first round, with clear limits.

  • The scope is small. Fifteen scenarios across three product types can’t represent the range of things people buy, from groceries to flights. Three attempts give a rough view of consistency, not a precise one.
  • The setup isn’t fully documented. The release doesn’t explain how product information was supplied, how the simulated shopper decided what to reveal, or how hidden requirements were scored. It also doesn’t say whether every model ran in the same agent framework with the same tools.
  • Cost per run isn’t defined. It isn’t clear whether “cost per run” includes only model calls or the full agent system.
  • There’s no independent replication yet. Visa says it shared the benchmark with model providers for feedback and made it available to try on Visa Payments Frontier. Outside groups haven’t published their own results.
  • Real shoppers are messier. A simulated shopper with a fixed list of requirements is consistent in a way real people aren’t. Real shoppers change their minds, contradict themselves and leave mid-conversation.

None of this makes the results unreliable. They show how agents did on Visa’s tasks, not how ready agentic commerce is overall. And for a payments company with a stake in agentic commerce, Visa published notably critical findings.

What retailers and developers should measure next

Visa’s results point to a short list of measurements for anyone building or deploying a shopping agent:

  • Pass rate across repeated runs, not single runs. Track how often a scenario passes every time.
  • Requirement coverage. Measure how many decision-relevant constraints the agent establishes before it recommends anything.
  • Wrong-purchase rate. Separate failures that end in a purchase from failures that end in no purchase. Only the first kind costs money.
  • Cost per successful task, including failure handling. Add returns, refunds and support time to model costs.
  • Escalation behaviour. Check whether the agent asks for help or declines when it lacks information.

Measure them on your own catalogue. A benchmark shows what an agent can do; your own data shows what it will do.

If an AI shopping agent can spend someone’s money, it needs more than a good average. It has to get the same task right repeatedly, know when it doesn’t know and work inside limits that make its mistakes cheap to reverse. Visa’s first round shows the industry isn’t there yet, and gives it a way to measure progress.

FAQ

What are AI shopping agents?

AI shopping agents are AI systems that find, compare and sometimes buy products on a shopper’s behalf. Unlike search tools, they hold a conversation, weigh requirements and can take actions such as placing an order.

What did Visa’s AI shopping benchmark test?

It tested whether AI models could uncover a shopper’s requirements through conversation and make the right purchase or no-purchase decision. Visa ran 22 models from 12 labs on 15 scenarios, three times each.

Why did AI shopping agents fail 42.8% of Visa’s test runs?

A run failed if the agent missed any task-defined requirement or made the wrong decision. Visa’s results tie failure closely to missing the shopper’s unstated needs.

Why did some failed AI shopping agents still make purchases?

They either chose a product that didn’t meet the identified requirements or decided to buy before finding all of them. That happened in 54% of failed runs.

Which AI models performed best in Visa’s benchmark?

According to Fortune, agents built on Google’s Gemini and on a Meta model tied for first at 82%, with a Claude agent third at 76%. Visa’s own release didn’t name the models.

Are expensive AI shopping agents more reliable?

On average, yes in this benchmark: the five costliest models passed 67.1% of runs and the five cheapest 50.2%. But price alone doesn’t decide value, so compare cost per successful task.

Does Visa’s benchmark test actual payments?

No. The first round covered product discovery and the purchase decision only. Visa says checkout, payment and order placement will be added later.

Can AI shopping agents make purchases without human approval?

Technically, some can, if they’re connected to a payment method. Whether they’re allowed to depends on the limits and approval rules set by the shopper, the application and the payment network.

How can retailers make AI shopping safer?

Use spending limits, merchant and category restrictions, approval thresholds, tokenised credentials, transaction logs and easy refunds. Then measure agents on repeated runs over your own catalogue.

Are AI shopping agents ready for everyday use?

For finding and comparing products, often yes. For unsupervised spending, Visa’s own results suggest caution: even the best model failed about one run in six.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

LLM Quantization Explained: Why 4-Bit Models Are Bigger Than the Math Says

LLM quantization

Last verified: 6 November 2026. All file sizes come from Hugging Face repository listings. Nothing here was downloaded or benchmarked by UniverseBlend.

Kimi K3 is a 2.8-trillion-parameter model trained to run at 4 bits. Multiply 2.8 trillion by half a byte and you get 1.4 TB. The official checkpoint on Hugging Face is 1.56 TB, about 161 GB more than the formula promised.

That gap is the part of LLM quantization most guides skip. The arithmetic is right, but a real download carries scaling factors, layers kept at higher precision and sometimes whole components the headline parameter count leaves out. Running the model then needs memory the files never mention.

Key Takeaways
  • LLM quantization changes how many bits each weight uses, which shrinks files and memory traffic, but every scheme also stores scales.
  • The formula is a floor. Real checkpoints for five models came out 6% to 30% larger than parameters × bits ÷ 8.
  • Effective bits per weight is the number to track. Hy4 FP8 averages 8.35, Kimi K3 4-bit 4.49 and DeepSeek’s 2-bit build 2.61.
  • Mixed precision is normal. Kimi K3 keeps 57 billion parameters in BF16, adding 114 GB to a 4-bit checkpoint.
  • Headline parameter counts can leave things out. Hy4’s MTP layer, DeepSeek’s Engram tables and Gemma’s per-layer embeddings all change the size.
  • Checkpoint size isn’t VRAM. KV cache, activations and framework reservation come on top.
  • Context length drives runtime memory. Concurrent long requests can need more memory than the weights.
  • Read the repository manifest before downloading, and test quality on your own task.

Quick Navigation


LLM quantization starts with one formula

Every sizing estimate begins in the same place:

Theoretical weight size (bytes) = parameter count × bits per parameter ÷ 8

It assumes every parameter uses the same bit width, nothing else is in the file, and the advertised parameter count matches what’s stored. As the examples below show, none of that is reliably true.

Three worked examples, in decimal units:

  • A 70-billion-parameter model in BF16: 70 × 10⁹ × 16 ÷ 8 = 140 GB.
  • Tencent’s Hy4 at its headline 770 billion parameters in FP8: 770 × 10⁹ × 8 ÷ 8 = 770 GB.
  • DeepSeek V4.1 Flash, 763.2 billion parameters, at 2 bits: 763.2 × 10⁹ × 2 ÷ 8 = 190.8 GB.
PrecisionBits per parameterTheoretical storage per billion parameters
FP32324 GB
FP16 / BF16162 GB
FP8 / INT881 GB
4-bit40.5 GB
2-bit20.25 GB

These are floor estimates for weights alone, not download sizes and not memory requirements.

Units matter too. Hugging Face and most model cards use decimal gigabytes, where 1 GB is 1,000,000,000 bytes. Operating systems and GPU tools often report binary gibibytes, where 1 GiB is 1,073,741,824 bytes, about 7.4% larger. So Hy4’s 813.78 GB repository shows up as 757.9 GiB on disk, and Kimi K3’s 1.561 TB is 1.420 TiB. When two tools disagree about whether a file fits, check the units first.

The textbook estimate for a 100B-parameter model. Real checkpoints come out larger, as the examples below show.

What FP8, 4-bit and 2-bit LLM quantization actually change

Models are trained in floating point because weights and activations span a huge range of values. BF16 keeps FP32’s 8-bit exponent but cuts the mantissa to 7 bits. FP16 trades some of that range for more precision.

FP8 halves that again. NVIDIA’s FP8 primer describes two variants: E4M3, with more precision and a maximum of ±448, and E5M2, with more range and less precision. FP8 values are paired with scaling factors. MXFP8, which Hy4 uses, stores one 8-bit power-of-two scale for every block of 32 values, a detail worth 23.6 GB in Hy4’s checkpoint.

INT8, 4-bit and 2-bit formats map weights onto a small set of integer levels, again with scales. A 4-bit weight can take only 16 values, and a 2-bit weight only four. It works because most weights tolerate the lost precision. A small set of outliers and salient channels don’t, and that’s where most of the quality loss comes from. The AWQ paper found that protecting just 1% of salient weights greatly reduces quantization error.

The name of a format tells you less than you’d think. “4-bit” covers very different schemes:

FormatWhat it isWhere it runsEffective bits
FP8 (E4M3, MXFP8)8-bit floating point with per-tensor or per-block scalesHopper and Blackwell GPUs, vLLM, SGLangAbout 8.25 with MX scales
INT88-bit integer weights, often with 8-bit activationsBroad GPU and CPU supportAbout 8 plus scales
GPTQPost-training method that quantizes weights using second-order error correctionGPU servers through Transformers and vLLM3 to 4 nominal, plus group scales
AWQPost-training 4-bit method that rescales salient channels before quantizingGPU servers through vLLM and Transformers4 nominal, plus group scales
NF44-bit “normal float” levels used by bitsandbytes for on-the-fly loading and QLoRAGPUs through Transformers4 nominal, plus block scales
GGUF Q4_0llama.cpp file with a 16-bit scale per block of 32 weightsCPUs, Apple Silicon, consumer GPUs4.5 per quantized block
GGUF Q4_K_Mllama.cpp k-quant mixing 4-bit and higher-precision tensorsSame as above4.89 on Llama 3.1 8B
GGUF Q2_K / IQ2_XXSllama.cpp 2-bit quants, IQ variants built with an importance matrixSame as above3.16 and 2.38 on Llama 3.1 8B

The effective-bit figures for the GGUF formats come from llama.cpp’s quantize documentation, measured on Llama 3.1 8B. Scales and higher-precision tensors push them all above the nominal number: Q2_K averages 3.16 bits, not 2.

Fewer bits doesn’t mean proportionally faster inference either. Token generation is mostly limited by memory bandwidth, so smaller weights help, but only if the hardware and engine have fast kernels for that format. NVIDIA’s own documentation lists FP8 as a Hopper feature and MXFP8 and NVFP4 as Blackwell additions. A format your GPU can’t compute natively has to be unpacked first, and that costs time.

LLM quantization in the real world: three large checkpoints

Here’s what the formula predicts against what’s actually published. Every size comes from the repository’s own file listing.

Tencent Hy4: an FP8 checkpoint 44 GB over the estimate

The Hy4-preview-FP8 model card gives 770 billion backbone parameters, 49 billion active per token, plus a 10-billion-parameter multi-token prediction (MTP) layer that isn’t in the headline figure. The repository holds 130 safetensors shards totalling 813.77 GB.

At the headline 770 billion parameters, FP8 predicts 770 GB. Hugging Face’s per-dtype tensor counts show where the extra 43.8 GB comes from:

  • 770.3 billion FP8 weights: 770.3 GB
  • 23.6 billion U8 values, about one for every 33 FP8 weights, which matches MXFP8’s one-byte scale per block of 32: 23.6 GB
  • 9.6 billion parameters kept in BF16 at two bytes each: 19.3 GB
  • 31 million FP32 values: 0.1 GB
  • safetensors headers: about 0.5 GB

The config’s exclusion list explains the BF16 part: embeddings, output head, router gates and some attention projections stay unquantized. Together the tensors account for 813.25 GB of the 813.77 GB.

Hugging Face’s header lists the model at “804B params”, because it counts the 23.6 billion scale bytes as parameters. The real count is 780 billion: the 770-billion backbone plus the MTP layer.

DeepSeek V4.1 Flash: the 2-bit build that isn’t all 2-bit

The official DeepSeek-V4.1-Flash-1017 checkpoint is a mixed FP8 and FP4 release: 48 shards, 510.30 GB. The popular way to run it at home is ISTA-DASLab’s GSQ-RCO GGUF build, whose IQ2_XXS version is described as 2 bits per weight.

At 763.2 billion parameters, 2 bits predicts 190.8 GB. The card lists the IQ2_XXS build at 248.84 GB, 30% more. This time the gap is a specific component, not overhead.

The card splits the model into a 551.9-billion-parameter backbone and 196.6 billion parameters of Engram tables, lookup data the model reads a few rows at a time. Only the backbone is quantized to 2 bits: its files total 138.24 GB, which is 2.00 bits per weight. The Engram tables are stored separately in IQ4_NL at 4.50 bits per weight, adding 110.60 GB. Vision support needs a further 0.97 GB projector file.

So the “2-bit” build averages 2.6 bits per parameter. The card says the Engram file stays memory-mapped on disk and needs no VRAM or RAM, which is why it recommends an SSD. Our guide to running DeepSeek V4.1 Flash on a 12 GB GPU covers what that means for RAM and disk speed.

One caution: the card says the file layout changed on 27 October 2026, from four shards plus a separate Engram file to six shards per build. Check which revision you’re downloading.

Kimi K3: native 4-bit LLM quantization at 1.56 TB

Kimi K3 was trained with quantization-aware training, so its MXFP4 weights are the official release, not a post-hoc compression. The repository has 96 safetensors shards totalling 1,560.94 GB, or 1.561 TB.

The formula, at 2.8 trillion parameters and 4 bits, gives 1.40 TB. Hugging Face’s tensor counts again explain the difference. Assuming the standard MXFP4 layout, with two weights per byte and an 8-bit scale per 32 weights, the counts work out like this:

  • 2,722.7 billion 4-bit weights: 1,361.4 GB
  • their block scales: 85.1 GB
  • 57.2 billion BF16 parameters: 114.4 GB
  • FP32 tensors: 0.04 GB

That totals 1,560.86 GB, within 0.1 GB of the actual shards.

A figure of 1.63 TB has circulated for this download. We couldn’t match it to the repository manifest, which totals 1.56 TB (1.42 TiB). Our Kimi K3.1 Pro hardware guide shows the newer model’s 1.56 TB checkpoint lands in almost the same place.

Why LLM quantization files exceed the formula

The cases point to a short list of causes. Not every model has all of them, so there’s no fixed overhead to apply:

  • Quantization scales and metadata. Every block-scaled format stores extra numbers. They added 23.6 GB to Hy4 and 85.1 GB to Kimi K3.
  • Tensors kept at higher precision. Embeddings, output heads, router gates and normalisation layers are often left in BF16 because they’re sensitive or small. That was 19.3 GB for Hy4 and 114.4 GB for Kimi K3.
  • Components outside the headline count. Hy4’s MTP layer adds 10 billion parameters the “770B” figure leaves out.
  • Architecture-specific data at a different bit width. DeepSeek’s Engram tables are 44% of the 2-bit build.
  • Separate files you may need. Vision projectors, tokenizers and chat templates. Usually small, but Gemma’s projector is nearly 1 GB.
The file on disk and the memory needed to run it are separate numbers. Not every model has every component shown.

The useful number to calculate is effective bits per weight: actual file bytes × 8 ÷ parameter count. Hy4’s FP8 checkpoint works out at 8.35, Kimi K3’s 4-bit release at 4.49, and DeepSeek’s 2-bit build at 2.61. Use a format’s real effective rate, not its name, for your next estimate.

LLM quantization for small models: Gemma 4 E4B and LFM3

The same gaps matter more at the small end, where a few hundred megabytes decide whether a model fits on a phone.

Gemma 4 E4B: 4.5 billion effective, 8 billion stored

Google’s Gemma 4 E4B is marketed by its effective parameter count: 4.5 billion. With embeddings it’s 8 billion, and that’s what the files hold. Per-Layer Embeddings give each decoder layer its own lookup table, adding stored weights without much compute.

So which number goes into the formula? At 4 bits, 4.5 billion predicts 2.25 GB and 8 billion predicts 4.0 GB. Google’s official Q4_0 GGUF is 5.15 GB, plus a 0.99 GB projector for image and audio input. That’s 5.16 effective bits per weight across all 8 billion parameters.

Google’s memory table adds a third set of numbers: about 4.5 GB to load the Q4_0 model, 2.5 GB for its mobile build and 2.2 GB for mobile text-only, using LiteRT-LM. Those are loading-memory estimates, not file sizes, and Google says they exclude the KV cache. Even the 4.5 GB Q4_0 figure is below the 5.15 GB Q4_0 file, and the page doesn’t explain why. Its own notes also disagree on whether a 20% loading overhead is included. A 5 GB download and a 2.2 GB phone footprint can both be quoted for the same model.

LFM3-1.7B: where “about 1 GB” depends on the unit

Liquid AI’s LFM3-1.7B is a 1.73-billion-parameter text model built from 13 gated short-convolution layers, 5 sliding-window attention layers and 6 global attention layers. The card says that at 4-bit precision it takes about 1 GB of memory.

The formula gives 0.86 GB. The official GGUF repository has a Q4_0 file of 1,049,615,680 bytes and a Q4_K_M file of 1.10 GB. In decimal units that Q4_0 file is slightly over 1 GB. In binary units it’s 0.978 GiB, comfortably under.

A model this size fits in a phone’s or a low-end laptop’s memory with room left for context. The hybrid design helps: convolution layers don’t build up a KV cache the way global attention does, so long prompts cost less memory.

Model and buildParameters countedTheoretical weight sizeActual weight file(s)Effective bitsWhat explains the gap
Hy4-preview-FP8770B (780B with MTP)770 GB813.77 GB8.35MXFP8 scales, BF16 layers, MTP
DeepSeek V4.1 Flash, ISTA IQ2_XXS GGUF763.2B190.8 GB248.84 GB2.61Engram tables at 4.5 bits
Kimi K3, native MXFP42.8T1,400 GB1,560.94 GB4.49MXFP4 scales, 57B BF16 parameters
Gemma 4 E4B, official Q4_0 GGUF8.0B (4.5B effective)4.0 GB5.15 GB (+0.99 GB projector)5.16Higher-precision tensors, PLE tables
LFM3-1.7B, official Q4_0 GGUF1.73B0.86 GB1.05 GB4.86Q4_0 block scales, higher-precision tensors

All sizes are decimal GB from Hugging Face file listings, read 6 November 2026. Effective bits are our calculation from file bytes and parameter counts.

LLM quantization and VRAM: why the download isn’t the runtime

A checkpoint tells you how much space the weights need, not how much memory the model needs to run. On top of the weights, an inference engine needs:

  • KV cache, which stores attention keys and values for every token in context. It grows with context length and with the number of requests running at once.
  • Activations and workspace, the temporary buffers used while computing each layer.
  • Framework reservation. Engines such as vLLM reserve a fixed share of GPU memory up front, so the memory you see in use isn’t the minimum the model needs.
  • Fragmentation and multi-GPU copies. Allocators leave gaps, and some tensors may be replicated on every GPU, depending on how the model is split.

Here’s an illustrative example with stated assumptions. Take a hypothetical dense model with a 10 GB 4-bit checkpoint, 32 layers, 8 key-value heads of dimension 128 and an FP16 KV cache. Each token needs 2 × 32 × 8 × 128 × 2 bytes = 131,072 bytes of cache. At a 32,768-token context that’s 4.3 GB for one request. Serve four such requests at once and it’s 17.2 GB, which is more than the weights themselves. Before activations or framework overhead, the 10 GB model now needs about 27 GB.

Offloading changes the picture again. DeepSeek’s 2-bit build runs on a 12 GB GPU only because most of its 248.8 GB sits in system RAM and on an SSD, with the GPU handling a slice of each step. Every token then depends on RAM and disk bandwidth as much as on the GPU.

What you lose with more aggressive LLM quantization

FP8 is usually the safe step. Tencent publishes an official FP8 Hy4 checkpoint alongside the BF16 one, DeepSeek’s official release is itself FP8 and FP4, and most serving stacks support FP8 directly on current GPUs.

At 4 bits, results depend heavily on how the model got there. Kimi K3 and Gemma’s Q4_0 builds use quantization-aware training, so the model learned to work at low precision. Post-training methods such as GPTQ and AWQ compress a model after the fact. The GPTQ paper reported 3 to 4 bits per weight with little accuracy loss on a 175-billion-parameter model, but results vary by architecture and task.

At 2 bits, the evidence is thinner and mostly comes from the people making the quants. ISTA-DASLab reports that its IQ2_XXS DeepSeek build matched the base model on AIME25, GPQA-Diamond and LiveCodeBench v6 at reasoning effort 50, a 100% task recovery. Its 1.75-bit IQ1_M build recovered 98.7%. That’s three benchmarks at one setting, published by the quantizer, not an independent evaluation.

The pattern practitioners commonly report: larger models usually tolerate aggressive quantization better than small ones, reasoning and code tasks tend to show losses before chat does, and output can become less consistent between runs. Test the quantized model on your own workload before you commit hardware to it.

Choosing an LLM quantization format for your workload

SituationStart withWhyCheck first
Production serving on Hopper or Blackwell GPUsFP8 (or the official release format)Near-original quality, native hardware supportYour engine supports the model’s FP8 variant
A model released natively in 4 bitsThe official checkpointTrained for that precision, no extra lossTotal shard size and BF16 share
Fitting a model onto fewer GPUsAWQ or GPTQ 4-bitMature GPU kernelsAccuracy on your own evaluation set
Local use on a Mac, CPU or single consumer GPUGGUF Q4_K_M or Q4_0Broad runtime support, good size-quality balanceEffective file size and context memory
A very large model on modest hardware2-bit GGUF with offloadingMakes the model runnable at allRAM, SSD speed and task quality
Fine-tuning or high-stakes outputsBF16 or FP8Keeps the most precisionWhether the budget allows it

Before downloading any checkpoint, read the repository’s file list as well as the model card. Add up the shards you actually need, note any projector or auxiliary files, and confirm the publisher. A popular model attracts unofficial copies, and our guide on how to verify model weights before you download covers the checks.

To estimate memory, start from the real file size, add the KV cache for your context length and concurrency, and leave headroom for activations and overhead. If it doesn’t fit, a shorter context or fewer concurrent requests may cost less quality than a smaller quant.

LLM quantization is still the most effective way to fit a large model on hardware you can afford. Plan from the files, not the formula.

FAQ

What is LLM quantization?

LLM quantization stores a model’s weights, and sometimes its activations, in fewer bits than it was trained with, such as 8, 4 or 2 instead of 16. That cuts file size and memory traffic, at some risk to quality.

What is the difference between FP8 and 4-bit quantization?

FP8 uses 8-bit floating-point numbers and usually keeps quality close to the original. 4-bit formats halve the size again but have only 16 levels per weight, so the quantization method matters much more.

How much smaller does a 4-bit LLM become?

In theory, a quarter of its BF16 size. In practice, scales and higher-precision layers push real files to roughly 4.5 to 5.2 bits per weight in the examples here.

What is 2-bit quantization?

It stores most weights with just four possible values, cutting size to about an eighth of BF16. It usually relies on importance-weighted methods and keeps sensitive tensors at higher precision.

Why are LLM quantization files larger than theoretical estimates?

Because the formula ignores scaling factors, tensors kept in BF16, and components outside the headline parameter count. For DeepSeek V4.1 Flash, 4.5-bit Engram tables alone add 110.6 GB.

Does a 4-bit model use exactly 4 bits per parameter?

No. Kimi K3’s 4-bit checkpoint averages 4.49 bits, and llama.cpp’s Q4_K_M averages 4.89 bits on Llama 3.1 8B.

Is model file size the same as GPU VRAM usage?

No. VRAM also has to hold the KV cache, activations and the inference engine’s own reservation, and the KV cache grows with context length.

Does LLM quantization reduce accuracy?

It can, and the loss usually grows as bits fall. FP8 is typically close to the original, while 4-bit and 2-bit results depend on the method, the model and the task.

Which quantization format is best for running LLMs locally?

GGUF Q4_K_M or Q4_0 is the common starting point for llama.cpp, Ollama and LM Studio. Use the model publisher’s own GGUF when one exists.

How do I calculate the memory needed for LLM quantization?

Start from the actual file size, then add KV cache: 2 × layers × KV heads × head dimension × bytes per value × tokens × concurrent requests. Leave headroom for activations and framework overhead.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

OpenAI Found 948 Linux Kernel Flaws. Who Will Fix Them?

OpenAI Linux

Last verified: 5 November 2026. All figures are OpenAI-reported and haven’t been independently audited.

OpenAI says an autonomous agent pipeline found 948 distinct OpenAI Linux kernel vulnerabilities in a single run, each one a working path from an ordinary user account to root. The bill was $1,213,430 in API credits. According to OpenAI’s 4 November research publication, ten days after the scan and manual review finished, 61 of those flaws had been patched upstream.

That second number is the more interesting one. AI is turning kernel bug-hunting into a question of compute. Getting fixes reviewed, merged and onto real machines still runs on human time.

Key Takeaways
  • 948 is a count of distinct flaws. OpenAI’s agents found 948 distinct local privilege-escalation vulnerabilities, backed by 1,169 working exploits.
  • The funnel matters. 2,308 candidates became 1,724 reproduced bugs. The 291 information-leak PoCs are a separate measurement, not extra root exploits.
  • $1,279 is an average API cost, not a price. It’s $1,213,430 in reported API credits divided by 948 flaws, and OpenAI calls it an upper bound.
  • Remediation isn’t in that figure. Human review, maintainer time, backports and deployment all cost extra.
  • Human checks caught real errors. 20 of 200 early “successful” exploits had reached root through the wrong bug.
  • A generated patch isn’t a deployed fix. Ten days after the scan, 61 flaws were patched upstream and 43 had staging patches.
  • These are local flaws. An attacker needs existing access first, so isolation and least privilege still limit the damage.
  • Discovery now scales faster than repair. The next problem for AI security research is review, disclosure and distribution capacity.

Quick Navigation


OpenAI Linux kernel vulnerabilities: what happened in the experiment

In mid-October 2026, OpenAI’s security researchers pointed a multi-agent system at the latest Linux kernel master branch. The agents ran on what OpenAI calls an upcoming cyber model, which it hasn’t named or released. Their brief was narrow: find flaws that let a low-privileged local user become root, prove them, and draft a fix for each.

The company’s experiment found 948 distinct local privilege-escalation (LPE) vulnerabilities, backed by 1,169 working exploits and a candidate patch for each distinct flaw. OpenAI also reported 291 proof-of-concept programs for information leaks, a separate and less severe class of bug.

Two context points matter before the numbers. First, the agents audited about 7% of the kernel, not all of it. Second, every figure here comes from OpenAI. The Linux kernel security team hasn’t published its own count, and no outside group has audited the results.

OpenAI also ran the same harness in July with an earlier model, GPT-5.6 Sol. That run found 166 unique LPEs for $513,690, or roughly $3,095 each. In three months, the yield per run rose more than fivefold and the average cost per flaw fell by more than half.

Inside the pipeline behind the OpenAI Linux kernel vulnerabilities

The published methodology describes five stages, each narrowing the work handed to the next.

  1. Scouting. Scout agents mapped the kernel’s 40-million-plus lines and picked code a low-privileged user can actually reach. They chose 5,034 audit targets covering about 2.8 million lines, for $3,426 in API credits. A flaw only root can trigger can’t be used to become root, so this filter is the cheapest win in the run.
  2. Analysis. Analyst agents read those targets and produced 2,308 candidate findings in about 12 hours, at a cost of $316,549. A candidate is a hypothesis: the model believes some code path is unsafe. Many turn out to be wrong, unreachable or harmless.
  3. Dynamic validation. Triage agents then had to prove each candidate. They wrote small proof-of-concept programs and ran them inside isolated virtual machines built with the Kernel Address Sanitizer (KASAN), a debugging tool that flags invalid memory accesses at the moment they happen. Over 30 hours, 1,724 candidates reproduced, a rate of about 74.7%, for $73,330.
    • This step is what separates the run from static analysis. A static tool reports that code looks dangerous. A reproduced finding comes with runtime evidence that the bug fires. OpenAI puts the share of failures caused by wrong analysis at only about 3.1%. Most of the others needed elevated privileges to start, or relied on race conditions and fault injection that are hard to trigger on demand.
  4. Exploitation. Exploit agents tried to turn validated bugs into either an information leak or full root access. They worked on virtual machines configured like a stock desktop distribution, with standard kernel self-protection features switched on:
    • SMEP stops the kernel from running code placed in user memory.
    • SMAP stops the kernel from reading or writing user memory unless it means to.
    • KASLR randomises where the kernel sits in memory, so an attacker has to find it first.
    • HARDENED_USERCOPY checks the size and bounds of copies between the kernel and user programs.
    • An exploit that only works with these defences off proves far less. This stage was the most expensive by far, at $775,929.
  5. Patching and human review. For each validated flaw, the system worked out the root cause and drafted a candidate patch. It then ran variant analysis, which looks for the same mistake elsewhere and groups exploits that share one fix. Finally, human researchers reviewed each exploit, patch and proposed severity before anything went to kernel maintainers.
The headline numbers measure different things: 1,169 is a count of exploits, 948 a count of distinct flaws. Source: OpenAI.

How the OpenAI Linux kernel vulnerabilities numbers narrow down

The headline figures measure different things, and mixing them up is the easiest way to misreport this research.

MeasurementCountWhat it counts
Candidate findings2,308Suspected flaws flagged by analyst agents
Dynamically reproduced1,724Candidates proven to fire in a KASAN virtual machine
Information-leak PoCs291Programs that expose kernel memory, not root exploits
Working LPE exploits1,169Exploits that reached root on a protected test VM
Distinct LPE vulnerabilities948Unique flaws after variant analysis, one candidate patch each

The step from 1,169 to 948 is the one most coverage glosses over. Some flaws were reached by more than one working exploit. Variant analysis grouped exploits by the patch that closes them, so 948 counts distinct problems and 1,169 counts working attacks.

The 291 information-leak programs sit to one side. They show a bug can expose memory an attacker shouldn’t see, which can help defeat KASLR, but they aren’t additional root exploits. OpenAI also hasn’t published how many reproduced bugs were judged unexploitable, so the gap between 1,724 and the exploit counts isn’t fully explained.

OpenAI Linux kernel vulnerabilities: what $1,279 per flaw really means

OpenAI reported that the run cost $1,213,430 in API credits from start to finish. Divided across the distinct flaws, that works out as:

$1,213,430 ÷ 948 ≈ $1,280

OpenAI’s own write-up gives the average as about $1,279. Here’s where the money went, using the stage costs OpenAI reported:

Pipeline stageReported API costShare of total
Scouting$3,4260.3%
Candidate analysis$316,54926.1%
Dynamic validation$73,3306.0%
Exploit development$775,92963.9%
Not itemised in the stage breakdown (our subtraction)$44,1963.6%
Total$1,213,430100%

Finding the bugs was cheap. Proving they could become root was where nearly two-thirds of the budget went.

Inside that exploitation stage, success and failure cost very different amounts. Successful attempts averaged about $359. The 69 attempts that never worked cost far more each, mostly because agents kept retrying stubborn race conditions. A race condition depends on two operations happening in a precise order, so an agent can spend hours rerunning a test that fails because of timing, not because the analysis was wrong.

That makes the $1,279 figure useful as a signal and risky as a benchmark. It’s the reported API spend divided by distinct flaws, nothing more. It doesn’t include:

  • the salaries of the researchers who reviewed every exploit and patch
  • maintainer time spent triaging, reviewing and merging fixes
  • distribution packaging, backports or rollout to real servers
  • the cost of building the harness itself
  • any guarantee that another codebase or model would produce the same yield

OpenAI also frames the costs as an upper bound. The run was designed to measure what the model could do, not to minimise spend, and the company says better harness engineering could bring the costs down. Read the number as the price of one experiment, not as a market rate for kernel bugs.

OpenAI’s bounty comparison needs the same caution. Priced at historical Pwn2Own and TyphoonPWN rates, it values the haul at $18.9 million to $66.3 million. Google’s kernelCTF programme pays $71,337 per eligible exploit, but only for 0-days against a hardened target, and only once the patch lands upstream. Many of the 948 flaws would never qualify.

Why patching the OpenAI Linux kernel vulnerabilities is the harder problem

Here is the status OpenAI reported ten days after the scan and manual review:

Status after 10 daysCountWhat it means
Patched upstream61A fix has been merged into the mainline kernel
Staging patches43A fix is queued in a maintainer tree, not yet in mainline
Publicly reported and discussed299The flaw is being handled in public kernel discussion
Still in the reporting pipelineNot statedOpenAI hasn’t given a count for the remainder

These categories describe stages, not a tally of fixes. Adding them up and calling the result “fixed” would be wrong, and so would reading the gap as maintainers ignoring reports. OpenAI says it started with the most critical flaws, following Linux kernel community guidance, and sent hundreds of reports and patches. It’s reporting the rest through Patch the Planet, its open-source effort with partners including Trail of Bits, Calif and HackerOne.

Ten days is a short window for kernel work. The kernel’s own security process asks maintainers to verify a report, agree a fix and get it merged. Publication of a fix can be held back for at most seven days once the release process starts, or 14 by agreement. Each fix also has to pass review, regression testing and compatibility checks across a huge range of hardware.

Upstream is only the first stop. A patch in mainline has to be backported to the stable and long-term kernels that most organisations actually run. Distributions like Debian, Ubuntu and Red Hat package it, test it and issue advisories on their own schedules. Then every administrator has to install the update and reboot or live-patch. A fix that’s “in Linux” can take weeks or months to reach a given server.

A candidate patch still has to clear human review, maintainer acceptance and distribution before it protects a real server.

The kernel documentation now has specific rules for AI-assisted reports: keep them concise, avoid speculative impact claims, and include a tested reproducer and fix. It also says bugs found with AI assistance should be treated as public, because someone else’s tool may find them too.

That isn’t a hypothetical concern. In May, the embargo on Dirty Frag, a kernel LPE, broke early amid a parallel discovery of a related bug, iTnews reported. The researcher behind the second bug said no AI was involved, but maintainers warned that LLM-assisted research makes parallel discovery more likely. When several teams’ agents scan the same code, the window for quiet, coordinated repair gets shorter.

Why AI-generated security patches still need humans

The most telling detail in OpenAI’s report is a failure it caught. In an early exploitation run, the pipeline reported 200 successful LPE exploits. Human review found that 20 of them had reached root through a different, unknown vulnerability, not the one the agent had been assigned.

The cause was a loose definition of success. The test asked whether the agent got a root shell. Those 20 agents did, just by another route. A result like that looks like a pass, but it ties the exploit to the wrong bug, which means the wrong patch, the wrong severity and a real flaw left unrecorded. OpenAI tightened the task constraints and added an independent check that every final exploit used the vulnerability it was assigned.

The same discipline applies to patches. OpenAI says early AI-written patches were sometimes correct but padded with unnecessary code or out of step with kernel style, and took further iterations to become minimal, conventional and complete across variants. In a few cases, the system caught problems in human-written patches before they merged.

Independent research urges caution about automated fixes generally. In August, 1Password’s Off-By-1 Labs tested 6,080 patches from two frontier models against six real vulnerabilities, including a Linux privilege-escalation flaw. It found that 53.9% failed to fix the bug, introduced a new one or both, SecurityBrief reported. Those were one-shot patches, not OpenAI’s reviewed pipeline, so the numbers don’t transfer. They do show why a generated patch is a proposal, not a fix.

We made a similar point about the hidden costs of AI coding agents: generating code is cheap, but review, testing and rework are where the real cost sits. Kernel security is that problem at its sharpest.

What the OpenAI Linux kernel vulnerabilities mean for Linux security

A local privilege-escalation flaw lets someone who already has limited access to a machine become root. It doesn’t, on its own, let a stranger on the internet break into a server. An attacker first needs a foothold: a user account, a compromised web app, a malicious package or code running in a container.

That still makes LPEs serious in plenty of places:

  • shared servers and multi-user systems, such as university or research clusters
  • cloud hosts and CI runners that execute untrusted code
  • containers, where a kernel flaw can break the isolation boundary between workloads
  • developer laptops, where a malicious dependency can run as the user
  • any system where an attacker has already compromised one account

OpenAI hasn’t published affected kernel versions, CVE identifiers or a list of vulnerable distributions. It has also withheld details of ten exploitation techniques that it and outside kernel specialists considered new. Treat any list of affected versions circulating online with suspicion until OpenAI or the kernel community publishes one.

For administrators, the practical advice is unexciting and correct. Follow your distribution’s security advisories and apply supported kernel updates promptly as fixes arrive. Reduce who and what can run code locally. Use least privilege, sandboxing and container isolation, and monitor for unexpected privilege changes. Defence in depth matters more when the number of known paths to root is rising.

Beyond OpenAI: what autonomous security research means for open source

OpenAI isn’t alone. Anthropic’s Project Glasswing, announced in April, used Claude Mythos Preview to find thousands of zero-days across major operating systems and browsers, including chained Linux kernel flaws that turned user access into full control. For Gemini 4 Carbon, which we covered in our look at its cybersecurity scores, Google reports strong results on benchmarks for finding and fixing vulnerabilities.

These efforts measure different things, from bugs found to exploits against hardened targets, and almost none report patches accepted and deployed. Raw counts aren’t comparable. On Google’s kernelCTF environment, which has a reduced attack surface, OpenAI’s pipeline produced 21 LPE exploits and 25 information-leak PoCs in 112 hours for about $32,936. The target was built to be hard, and the haul shows it.

The pattern holds well beyond the kernel. When VicOne used AI-assisted research on robotics software, it reported 28 zero-day findings in under two days, as we covered in our robotics security analysis. Discovery speeds up, and patching doesn’t.

The open question is who absorbs the extra load: more reports, more duplicates and more automated patches, often from several labs scanning the same code. Programmes like Patch the Planet and Glasswing’s funding for open-source security groups put some money and expert triage on the maintainers’ side. Whether that scales is the test for every lab now publishing big vulnerability counts.

AI changes how much security research can be generated. It doesn’t change who decides what gets trusted and merged.

Frequently asked questions

What are the OpenAI Linux kernel vulnerabilities?

They’re 948 distinct local privilege-escalation flaws that OpenAI’s autonomous agents found in the Linux kernel in October 2026. Each one let a low-privileged user gain root on a test machine with standard protections enabled.

How did OpenAI find 948 distinct Linux kernel vulnerabilities?

It used a five-stage agent pipeline that scouted reachable code, flagged candidates, reproduced them in KASAN virtual machines, built exploits and drafted patches. Humans reviewed the results before reporting.

What is a local privilege-escalation vulnerability?

It’s a flaw that lets someone who already has limited access to a system gain higher privileges, usually root. It isn’t a way in from outside; the attacker needs a foothold first.

How much did it cost to find the OpenAI Linux kernel vulnerabilities?

OpenAI reported $1,213,430 in API credits for the full run, or about $1,279 per distinct flaw. That excludes staff time, maintainer work and deployment.

What is the difference between 1,169 exploits and 948 vulnerabilities?

1,169 is the number of working exploits, and 948 is the number of distinct flaws behind them. Some flaws were reached by more than one exploit, and variant analysis grouped them by the patch that fixes each one.

Have all the OpenAI Linux kernel vulnerabilities been patched?

No. Ten days after the scan, OpenAI reported 61 patched upstream, 43 with staging patches and 299 being discussed publicly. Even an upstream fix still has to reach distribution kernels and individual servers.

Can the OpenAI Linux kernel vulnerabilities be exploited remotely?

Not on their own. They’re local privilege-escalation flaws, so an attacker first needs some access to the machine, such as a user account or code running in a container.

Why do AI-generated security patches need human review?

Because a patch can look right and still be incomplete or wrong. OpenAI’s early patches needed several iterations, and its pipeline once tied 20 exploits to the wrong bug.

How does AI change vulnerability research?

It makes finding and proving bugs far cheaper and faster. Validation, disclosure and patch review still depend on human experts and maintainers.

What should Linux administrators do about the OpenAI Linux kernel vulnerabilities?

Follow your distribution’s security advisories and apply supported kernel updates as they’re released. OpenAI hasn’t published affected versions, so there’s no specific emergency patch to chase yet.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

NeurIPS 2026 Camera-Ready and Code Requirements

NeurIPS 2026

The NeurIPS 2026 camera-ready deadline is 6 November 2026, Anywhere on Earth, for both main track and Datasets and Benchmarks papers. The 40th conference runs 6 to 12 December in Sydney, with satellite events in Atlanta and Paris from 9 to 13 December.

Last verified: 5 November 2026 against neurips.cc. Some third-party deadline trackers list a different camera-ready date, so we checked the official Dates page directly.

Key Takeaways
  • The NeurIPS 2026 camera-ready deadline is 6 November 2026 at 23:59 AoE, which is 11:59 UTC on 7 November.
  • Upload one PDF in OpenReview with up to 10 content pages, plus references, appendices and the completed checklist.
  • Add a funding statement and a competing-interests disclosure, both covering the 36 months before submission.
  • You may reorder authors but not add or remove them, and title or abstract edits must stay close to the submission.
  • Code release is strongly encouraged, not required by default. Every paper still needs a reasonable way to reproduce its results.
  • Replace anonymised links with real ones, and check the commands and licenses they point to.
  • Workshop papers follow each workshop’s own deadline and don’t appear in the proceedings.
  • At least one author must register in person, and each paper must be presented in Sydney or at a satellite site.

Quick Navigation


Quick answers

These are the questions authors ask most this week, answered from official NeurIPS pages.

  • When is the NeurIPS 2026 camera-ready deadline? 6 November 2026 at 23:59 Anywhere on Earth, according to the official Dates page.
  • What is that in UTC? 11:59 UTC on Saturday 7 November.
  • Where do I upload it? In OpenReview, by editing your existing submission and choosing the camera-ready version, as the Main Track Handbook describes.
  • Is code release mandatory? No. The paper checklist guidance encourages it but says “no is an acceptable answer.”
  • Can I add an author? No. The handbook allows reordering but not adding or removing authors.
  • Do workshop papers share this deadline? No. Each workshop sets its own timeline, according to the workshop guidance.

NeurIPS 2026 at a glance

ItemDetailSource
Edition40th Annual Conference on Neural Information Processing Systemsneurips.cc
Main conferenceSydney, 6 to 12 December 2026neurips.cc
Satellite eventsAtlanta and Paris, 9 to 13 December 2026neurips.cc
Camera-ready deadline6 November 2026, 23:59 AoEDates page
Camera-ready page limit10 content pages (9 at submission, plus 1)Main Track Handbook
Required disclosuresFunding statement and competing interestsMain Track Handbook
Code releaseStrongly encouraged, not required by defaultPaper checklist guidance
PresentationIn person in Sydney or at a satellite siteMain Track Handbook

NeurIPS 2026 key dates

All dates below come from the official NeurIPS 2026 Dates page. Status is as of 5 November 2026.

MilestoneDateStatus
Abstract submission deadline4 May 2026 (AoE)Passed
Full paper submission deadline6 May 2026 (AoE)Passed
Reviews released to authors22 July 2026 (AoE)Passed
Author notifications24 September 2026 (AoE)Passed
Presentation site preference form30 September 2026 (AoE)Passed
Paper location assignment notifications6 October 2026, 17:00 UTCPassed
Early registration deadline30 October 2026 (AoE)Passed
Last chance for a registration refund4 November 2026 (AoE)Passed
Camera-ready deadline (main track and Datasets and Benchmarks)6 November 2026 (AoE)Upcoming
Child care registration deadline (Sydney and Atlanta)7 November 2026, 01:00 UTCUpcoming
Poster topics deadline15 November 2026 (AoE)Upcoming
Last chance to move session without affecting poster groupings15 November 2026 (AoE)Upcoming
Sydney main conference6 to 12 December 2026Upcoming
Atlanta and Paris satellites9 to 13 December 2026Upcoming

Two dates fall close to the camera-ready deadline. The child care registration deadline for Sydney and Atlanta lands just hours later, at 01:00 UTC on 7 November. The poster topics deadline and the last chance to move your session without breaking up poster groupings both fall on 15 November.

Day-by-day schedule in each city

Each city runs its own programme. The Dates page gives this schedule:

CityDatesWhat happens
Sydney6 DecemberExpo day
Sydney7 DecemberTutorial day
Sydney8 to 10 DecemberMain conference (exhibit hall open 7 to 10 December)
Sydney11 and 12 DecemberWorkshops and competitions
Atlanta9 DecemberMain conference and tutorials
Atlanta10 and 11 DecemberMain conference (exhibit hall open 9 to 12 December)
Atlanta12 and 13 DecemberWorkshops
Paris9 to 11 DecemberMain conference and tutorials (exhibit hall open)
Paris12 and 13 DecemberWorkshops

If you were assigned to a satellite site, plan travel around that city’s dates rather than Sydney’s. Your location assignment arrived on 6 October.

What “Anywhere on Earth” means for your deadline

One deadline, five clocks. Every time shown is the same moment.

Anywhere on Earth (AoE) is UTC−12, the last time zone on the planet to reach the end of each day. A deadline of 23:59 AoE on 6 November passes at 11:59 UTC on 7 November. If it’s still 6 November anywhere on the planet, you’re on time.

LocationDeadline in local time
UTC11:59, Saturday 7 November
London (GMT, UTC+0)11:59, Saturday 7 November
Paris (CET, UTC+1)12:59, Saturday 7 November
US Pacific (PST, UTC−8)03:59, Saturday 7 November
US Eastern (EST, UTC−5)06:59, Saturday 7 November
India (IST, UTC+5:30)17:29, Saturday 7 November
Sydney (AEDT, UTC+11)22:59, Saturday 7 November

US daylight saving ended on 1 November, and the UK and Europe changed clocks on 25 October, so those regions are now on standard time. Sydney has been on daylight time since early October. In every location listed, the deadline falls on Saturday 7 November, local time.

The extra hours are a safety margin, not a plan. OpenReview can slow down near a major deadline, and a failed upload at the last minute leaves no time to fix it. Aim to upload a complete version a day early, then replace it if you make final edits.

What the NeurIPS 2026 camera-ready version must include

The Main Track Handbook sets out the camera-ready rules. In short, you upload one PDF in OpenReview that contains the final paper, the required disclosures and the completed checklist.

How to upload in OpenReview

Open your paper’s page in OpenReview and select Edit in the top right corner. Then choose the camera-ready version and upload your files there. You’re editing the existing submission, so the paper keeps its ID, reviews and discussion history.

One PDF, with an extra page

Upload a single PDF combining the paper, references, any text appendices and the completed paper checklist. Submissions had a nine-page content limit, and accepted papers get one extra content page. References, appendices and the checklist don’t count toward that limit. Use the current NeurIPS 2026 style file, which also contains the checklist instructions.

The extra page is meant for changes requested in review. The handbook asks authors to update the main paper in response to reviewer comments and the discussion period.

Funding and competing interests

The handbook asks every camera-ready paper for a funding statement and a list of competing interests. Both cover the 36 months before submission.

  • Funding: list all third-party support for the work, including grants, donated compute and programming support.
  • Competing interests: list paid relationships that could be seen to sway the work, even if they didn’t fund it. Include all revenue paid or promised. You don’t need to repeat the group already named as your main employer.

These two statements are easy to miss because the anonymous submission didn’t need them. Draft them before you start final formatting, so you can confirm details with co-authors in time.

What you can and can’t change

According to the handbook, you may edit the title, keywords and abstract, as long as they don’t differ substantially from the submission. You may reorder authors freely, but you can’t add or remove anyone.

A change of title that keeps the same meaning is fine. A new title describing a different contribution is not, because it would differ substantially from what reviewers assessed.

A lay summary

The handbook also asks for a lay summary: one paragraph for the general public, written without jargon. Write it for a curious reader with no machine learning background. Say what problem the paper tackles, what you found and why it matters.

Registration and in-person presentation

At least one author must register for the main conference, and the handbook states that “a ‘Virtual Only Pass’ is not sufficient.” A student author needs only a student registration, and one registration can cover several accepted papers.

Each accepted paper must be presented in person in Sydney or at a satellite site. The handbook warns that a paper can lose its accepted status if no author registers and presents.

Your reviews will become public

For accepted papers, the handbook says reviews, meta-reviews and author discussion are made public. Reviewer, area chair and senior area chair identities stay anonymous. If your rebuttal promised changes, readers will be able to see whether the camera-ready made them.

A last-hour checklist
The six things to check before you upload.

Before you press submit, run through the points the handbook and checklist guidance cover:

  1. The PDF uses the 2026 style file and stays within 10 content pages.
  2. The funding statement and competing-interests disclosure are both in the paper.
  3. The paper checklist is filled in and included at the end of the same PDF.
  4. Repository links are de-anonymised and point to the version you want readers to use.
  5. The author list matches the submission, even if the order has changed.
  6. The lay summary is uploaded, and at least one author holds a full registration.

If you’re unsure about a rule, the handbook is the place to check. Emails and forum posts from earlier years may describe policies that no longer apply.

Code and data requirements

NeurIPS 2026 encourages code release but doesn’t make it a blanket requirement. The official paper checklist guidance and the Main Track Handbook set the rules. The Call for Papers itself doesn’t contain code rules.

What is required
  • A completed paper checklist. The guidance says papers without it “will be desk rejected.”
  • “Some reasonable avenue for reproducibility.” The guidance notes that NeurIPS “does not require releasing code,” but every paper needs some way for others to reproduce or verify its results. For a new algorithm, the paper should make clear how to reproduce it.
  • Citations and license names for existing code, data or models you used, including the version of each asset. For scraped data, state the source’s copyright and terms of service.
  • Documentation for any new assets you release, covering training, license and limitations, and how consent was obtained from people whose data is used.
What is encouraged
  • Releasing code, data and instructions to reproduce the main results, including “the exact command and environment needed.”
  • De-anonymised links in the camera-ready. The handbook says accepted papers “should provide de-anonymized links for reproducibility.”
When “no” is an acceptable answer

The checklist is explicit that “no is an acceptable answer” to the code question. Papers can’t be rejected simply for not including code, unless code is central to the contribution, as with a new open-source benchmark. The guidance gives proprietary code as an example of a valid reason for answering no.

More broadly, the guidance says that answering “no” or “n/a” is “not grounds for rejection.” What matters is an honest answer with a brief justification.

At submission, the checklist asked authors to share anonymised versions of code and assets. For the camera-ready, replace any anonymised repository links with your real ones. Check that each link opens, that the repository’s README gives the commands the checklist describes, and that the license file matches what the paper states.

Workshop deadlines are separate

Workshop papers follow each workshop’s own timeline, not the main camera-ready date. The workshop guidance lets organisers set their own schedules. The only fixed dates are the suggested submission date of 29 August and the mandatory notification date of 29 September, both listed on the Dates page.

The guidance also states that “all NeurIPS workshop papers are non-archival and therefore do not appear in proceedings.” Organisers decide whether to share accepted papers, for example through OpenReview. Check your workshop’s website or OpenReview page for its camera-ready date, format and any poster requirements.

Why code release matters

A result that others can rerun is easier to trust and build on. Released code lets reviewers, readers and later authors check a claim, rather than relying on the paper’s description alone.

Benchmark numbers show why this matters. Scores depend on prompts, versions and settings, which is why our comparison of LLM benchmark scores treats them as evidence rather than a leaderboard. Even the same prompt can produce different outputs from one run to the next, as our explainer on LLM determinism shows. Released code, pinned versions and the exact environment narrow that gap.

The checklist’s requests line up with this. It asks for the exact command and environment, the version of each asset and the license for each dataset. Those details are what another lab needs to get the same numbers.

The AI Reviewing Experiment

Peer review itself is under study this year. NeurIPS is running a voluntary AI Reviewing Experiment to study how reviewers use large language models. Reviewers were randomly assigned, per paper, to no language-model help, open-ended help or structured help. Only papers whose authors opted in at submission were included.

NeurIPS says the tool is meant to help reviewers understand submissions, not to write reviews for them. It also says participation “will have no bearing on paper decisions,” and area chairs assessed reviews without knowing each review’s condition.

Frequently asked questions

Can I add an author at camera-ready?

No. The handbook allows reordering but not adding or removing authors, so anyone missing from the submission can only be thanked in the acknowledgements.

What time zone is the NeurIPS deadline in?

Anywhere on Earth, which is UTC−12. If any place on the planet is still on 6 November, the deadline hasn’t passed.

Do I need a new OpenReview submission for the camera-ready?

No. You edit the existing submission and choose the camera-ready version, so the paper keeps its ID and review history.

Will my reviews become public?

Yes, for accepted papers. Reviews, meta-reviews and author discussion are published, while reviewer and area chair identities stay anonymous.

Is releasing code mandatory for NeurIPS 2026?

No, unless the code is central to the contribution, such as a new open-source benchmark. You still need some reasonable way for others to reproduce your results.

Does the extra page apply to Datasets and Benchmarks papers?

The extra content page is described in the Main Track Handbook. Datasets and Benchmarks authors share the same 6 November deadline, but should check their own track’s guidance for formatting rules.

Can I present my paper online instead of in person?

No. Each accepted paper must be presented in person in Sydney or at a satellite site, and a virtual-only pass doesn’t meet the registration requirement.

Are NeurIPS workshop papers published in the proceedings?

No. The workshop guidance states that all NeurIPS workshop papers are non-archival and don’t appear in the proceedings.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

Claude API Rate Limits in 2026: How Many Requests Can You Run?

Claude API rate limits

Claude API rate limits on the Start tier allow most current models 2,000,000 input tokens and 400,000 output tokens per minute, with 1,000 or 4,000 requests per minute depending on the model. There is no fixed number of concurrent sessions: how many requests you can keep in flight depends on which of those per-minute limits your workload hits first, and how long each request takes.

Last verified: 5 November 2026, against Anthropic’s rate limits documentation.

Key Takeaways
  • The Claude API sets per-minute limits on requests, input tokens and output tokens, and none of them is a fixed concurrent-session count.
  • For any workload, the lowest of RPM, ITPM ÷ input per call and OTPM ÷ output per call sets your throughput.
  • Multiply that throughput by average request duration, divided by 60, to estimate requests in flight.
  • Cache reads don’t count toward ITPM on most models, so caching can lift input-bound workloads several times over.
  • Workspace overrides can lower a team’s effective limit below the organisation’s.
  • Plan below the maximum, read the rate-limit headers and retry with backoff and jitter.

Quick Navigation


Current Claude API rate limits by tier

Anthropic now groups organisations into Start, Build and Scale tiers, plus a Custom tier arranged with its account team. New organisations may begin in an Evaluation tier with lower limits while they build a usage history. Anthropic places organisations on a tier automatically, and you can ask for an increase from the Rate limits page in the Claude Console.

Each model group has three separate limits. Requests per minute (RPM) counts API calls. Input tokens per minute (ITPM) counts the prompt tokens you send. Output tokens per minute (OTPM) counts the tokens the model generates.

TierModel groupRPMITPMOTPM
StartOpus 5.5, Sonnet 5.5, Haiku 5.54,0002,000,000400,000
StartOpus 5, Opus 4.x, Sonnet 5, Sonnet 4.x, Haiku 4.51,0002,000,000400,000
StartFable 5.x4,000500,000100,000
BuildOpus 5.5, Sonnet 5.5, Haiku 5.510,0005,000,0001,000,000
BuildOpus 5, Opus 4.x, Sonnet 5, Sonnet 4.x, Haiku 4.55,0005,000,0001,000,000
BuildFable 5.x10,0001,500,000300,000
ScaleOpus 5.5, Sonnet 5.5, Haiku 5.513,00010,000,0002,000,000
ScaleOpus 5, Opus 4.x, Sonnet 5, Sonnet 4.x, Haiku 4.510,00010,000,0002,000,000
ScaleFable 5.x13,0004,000,000800,000

Source: Anthropic rate limits documentation, Messages API tables, checked 5 November 2026.

Each row in the table describes a limit for one model group, and groups don’t share a budget. Opus 4.8, 4.7, 4.6 and 4.5 draw from one combined Opus 4.x limit, while Opus 5.5 and Opus 5 each have their own. Sonnet 4.6 and 4.5 share a Sonnet 4.x limit, and Fable 5.1 and Fable 5 share a Fable limit. The Rate Limits API lists exactly which model IDs count against each group for your organisation.

Each tier also carries a monthly spend cap of $500 on Start, $1,000 on Build and $200,000 on Scale. Reaching it pauses usage until the first day of the next month, unless you get a higher limit approved sooner.

How many concurrent requests can you run?

An illustrative way to estimate concurrency from published rate limits.

The API publishes per-minute limits, not a cap on simultaneous connections. To estimate concurrency, work out how many requests per minute each limit allows for your workload, take the lowest, and multiply by how long a request lasts.

The formula

Estimated in-flight requests = permitted requests per minute × average request duration in seconds ÷ 60.

Permitted requests per minute is the smallest of three numbers:

  • your RPM limit;
  • your ITPM limit divided by the input tokens that count against it per request;
  • your OTPM limit divided by the output tokens per request.

The result is a sustainable average for a steady workload. It doesn’t promise that a given number of requests can start at the same instant.

Worked example 1: an output-limited workload

This illustrative workload runs on the Start tier with Opus 5, which allows 1,000 RPM, 2,000,000 ITPM and 400,000 OTPM.

  1. Each prompt is 20,000 tokens, and 80% of them are read from the prompt cache. Cache reads don’t count toward ITPM on this model, so each call counts 20,000 × 0.2 = 4,000 uncached input tokens.
  2. Input allows 2,000,000 ÷ 4,000 = 500 calls per minute.
  3. Each response is 2,000 tokens. Output allows 400,000 ÷ 2,000 = 200 calls per minute.
  4. RPM allows 1,000 calls per minute.
  5. The lowest of 500, 200 and 1,000 is 200 calls per minute, so output is the binding limit.
  6. With an average call lasting 30 seconds, in-flight requests come to 200 × 30 ÷ 60 = 100.

Output binds here because each response is long relative to the uncached prompt. On Opus 5.5, the RPM figure would rise to 4,000, but the answer would stay at 200 calls a minute because the token limits are the same. Even then, 100 is an average to plan around, and bursts above it can still trigger 429 errors.

Worked example 2: an input-limited workload

This second illustrative workload uses the same Start-tier limits for Opus 5, but each request summarises a fresh document.

  1. Each prompt is 50,000 tokens. Every document is new, so the cache hit rate is 0% and all 50,000 tokens count toward ITPM.
  2. Input allows 2,000,000 ÷ 50,000 = 40 calls per minute.
  3. Each summary is 1,000 tokens. Output allows 400,000 ÷ 1,000 = 400 calls per minute.
  4. RPM allows 1,000 calls per minute.
  5. The lowest of 40, 400 and 1,000 is 40 calls per minute, so input is the binding limit.
  6. With an average call lasting 15 seconds, in-flight requests come to 40 × 15 ÷ 60 = 10.

Caching changes this case sharply. If a 30,000-token instruction block were cached and only 20,000 tokens per call were new, input would allow 2,000,000 ÷ 20,000 = 100 calls per minute. Output would still allow 400, so the binding limit would rise from 40 to 100 calls a minute.

Where the estimate breaks down

The formula assumes steady request sizes and durations, which real traffic rarely has. Long and short prompts mix, streaming responses hold connections open longer, and network latency and queueing add time that the model isn’t using. Retries add load at the moment you can least afford it.

The rate limits are also enforced more finely than a minute. Anthropic uses a token bucket that refills continuously, and notes that a limit of 60 RPM might be enforced as one request per second. Sharp rises in an organisation’s traffic can also hit separate acceleration limits, so Anthropic advises ramping up gradually.

Two details help planning. ITPM is estimated when a request starts and corrected as it runs. OTPM counts only tokens actually generated, so a high max_tokens setting doesn’t use up the allowance on its own. Most teams plan well below the theoretical maximum to leave room for bursts and retries.

How prompt caching raises effective input throughput

At an 80% cache hit rate, a 2 million ITPM limit can carry about 10 million input tokens a minute.

For most Claude models, only uncached input tokens count toward ITPM. The API reports three kinds of input token: input_tokens after the last cache breakpoint, cache_creation_input_tokens written to the cache, and cache_read_input_tokens read from it. The first two count toward ITPM, and cache reads don’t.

Anthropic’s own example uses a 2,000,000 ITPM limit and an 80% cache hit rate. In that case, 20% of incoming tokens count, so the limit supports 2,000,000 ÷ 0.2 = 10,000,000 total input tokens per minute: 2 million uncached and 8 million cached.

The benefit applies only to the input limit. Caching doesn’t raise RPM or OTPM, and the first request that writes a cache entry still counts in full. The retired Claude Haiku 3.5 is an exception, because it counts cache reads toward ITPM. Billing for cached tokens follows a separate price schedule from rate limiting. Our guide to structuring prompts for caching covers how to keep a stable prefix that the cache can reuse.

What happens when you hit a limit

Exceeding any one limit returns an HTTP 429 with the type rate_limit_error that names the limit you crossed. When the response includes a retry-after header, Anthropic says to wait that many seconds, because earlier retries will fail. A 429 caused by the monthly spend cap carries no retry-after header and keeps failing until access resumes, so retrying it won’t help.

Successful responses carry rate-limit headers you can use to schedule work before you hit a wall:

  • anthropic-ratelimit-requests-limit, -remaining and -reset track requests.
  • anthropic-ratelimit-input-tokens-limit, -remaining and -reset track input tokens.
  • anthropic-ratelimit-output-tokens-limit, -remaining and -reset track output tokens.
  • anthropic-ratelimit-tokens-limit, -remaining and -reset show whichever token limit is most restrictive right now.

The reset headers use RFC 3339 timestamps, and the token “remaining” values are rounded to the nearest thousand. A scheduler can slow its dispatch rate as remaining capacity falls, which avoids most 429s in the first place.

When 429s do arrive, use exponential backoff with random jitter so that many workers don’t retry at the same moment. Anthropic’s official SDKs retry automatically, twice by default, and honour retry-after. A shared queue with a fixed concurrency cap is usually safer than letting each worker retry on its own.

Workspace limits and Priority Tier

Organisation limits are the ceiling, and workspace limits can be set lower to stop one team or app using everything. Without an override, a workspace inherits the organisation’s limit. The Rate Limits API can set workspace overrides for requests, input and output tokens per minute, cache-aware input tokens per minute, tokens per minute, tokens per day and tool uses per second. The lower of the workspace and organisation values applies, and changes take effect within about an hour.

Priority Tier is a separate capacity commitment measured in input and output tokens per minute for a specific model. Anthropic says new commitments are no longer available for purchase, though existing contracts continue until they end. Priority requests still draw on the ordinary rate limits, and traffic beyond the commitment falls back to the standard tier.

Claude.ai, Claude Code and API limits are separate

Usage limits on Claude.ai and Claude Code subscriptions are a different system from the API rate limits above. Anthropic bills the API separately from paid Claude plans, and its support documentation explains how the two relate. For plan allowances, check the current articles on Claude’s help centre.

How Claude API rate limits compare with other providers

Other providers combine request limits, token throughput, account tiers, daily caps and per-model rules in different ways, so their figures can’t be compared directly. Our overview of AI API rate limits across providers sets them side by side, and our guide to LLM cost per task shows how to price the same workloads.

Frequently asked questions

Does the Claude API have a fixed concurrent-session limit?

The rate-limit documentation doesn’t list one. Concurrency follows from the per-minute limits and request length, so a workload with short responses can run far more parallel calls than one producing long outputs.

Can multiple applications share the same Anthropic API rate limits?

Yes. Every key in an organisation draws on the same organisation limits, and the anthropic-workspace-id response header shows which workspace a request counted against. Giving each application its own workspace with lower overrides stops one from using all the capacity, though the organisation limits still cap the total.

What is the difference between a 429 rate-limit error and a server error?

A 429 means your organisation has used its allowance, so the fix is to slow down or wait for retry-after. A 500 signals an internal error and a 529 signals that the API is overloaded for everyone. Both are temporary and worth retrying with backoff.

Can prompt caching increase Claude API request concurrency?

Only when input tokens are the binding limit. Caching leaves RPM and OTPM unchanged, so an output-bound workload gets no extra concurrency from it.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

Enterprise AI Spending Hit $177B. Agents Are Driving the Bill

Enterprise AI Spending

Figures checked against Menlo Ventures’ 2026 State of Enterprise AI report on 4 November 2026. Market sizes are Menlo estimates, shown as annualised run rates.

The price of AI keeps falling. Menlo Ventures says the average open-source model token now costs about $0.13 per million, down 3.3x in a year, and closed models fell 24% to a blended $0.70. Yet enterprise AI spending, by Menlo’s estimate, rose 5.4x to $176.8 billion.

Cheaper inputs and much bigger bills sound contradictory. They aren’t. Menlo’s 2026 State of Enterprise AI report, published on 3 November, shows companies moving from paying for people to use AI towards paying for AI to do work. Work done by agents is measured in tokens, and agents use a lot of them.

Key Takeaways
  • Menlo estimates enterprise AI deployment spending at $176.8 billion by September 2026, separate from $102.5 billion in development spending.
  • Adoption rose 10 points; average spend per company rose 4.7x. Intensity, not new adopters, drove the growth.
  • On OpenRouter, agents now generate about 80% of tokens, a signal from a developer-heavy gateway, not an enterprise census.
  • Open-source models took 19% of tokens but 4% of spending, a gap almost entirely explained by Menlo’s average price difference.
  • Frontier labs hold 69% of deployment spending. Cost per finished task, not per token, may explain why buyers pay more.
  • Coding and assistants make up 76% of application spending, because coding gives agents clear, testable work.
  • Budgets need to become consumption budgets, with per-task tracking and limits.
  • Read the report with its methodology in mind: a US survey, a restated baseline and investment ties to Anthropic and OpenRouter.

Quick Navigation


Enterprise AI spending grew far faster than adoption

Menlo’s $176.8 billion is deployment spending: money companies spend using and running AI, split between $99.5 billion of infrastructure and $77.3 billion of applications. It’s separate from the $102.5 billion Menlo estimates for development, mostly training compute, which is money spent building models. The two shouldn’t be added together casually, and neither is the total global AI market.

Measure (Menlo estimates)Prior year2026Change
Enterprise AI deployment spending$33B$176.8B5.4x
AI development spendingNot stated here$102.5B5.3x
Enterprise AI adoption55%65%+10 points
Average spend per enterprise1x4.7x4.7x

The adoption line is the interesting one. Ten more percentage points of enterprises used AI, roughly 18% more adopters. Average spend per enterprise rose 4.7x. Almost all of the growth in enterprise AI spending came from companies that were already using AI and started using much more of it.

A rough check, as UniverseBlend analysis: 1.18 times more adopters, each spending 4.7 times as much on average, gives about 5.5x. That’s close to Menlo’s 5.4x market figure. The survey average and the market estimate are different measures, so this is a sanity check, not a decomposition. But it points the same way: intensity, not reach, is driving enterprise AI spending.

How agents change enterprise AI spending

A seat licence prices access. One employee, one monthly fee, whatever they do with it. An agent prices work. It takes a task, calls a model many times, reads files and tool outputs, and keeps going until it finishes or fails.

Menlo’s evidence for the shift comes from OpenRouter, a service that routes requests to many model providers through one API. According to the report, agent traffic overtook human traffic there in early February 2026. Since then, agent token traffic grew 37x while human-driven traffic grew 5x. Agents now account for about 80% of OpenRouter tokens, about 130.9 trillion a week. On those shares, agents generate roughly four times as many tokens as people do.

Those figures need context. OpenRouter is one gateway, and the report itself notes that its users skew towards individual developers and startups rather than enterprise buyers. Large companies often go directly to Anthropic, OpenAI, Google or their cloud provider, and OpenRouter’s own rankings page notes that it measures traffic routed through the service, not users or spend. The OpenRouter data shows the direction of travel, not a census of enterprise AI usage, and it comes from a different population than Menlo’s enterprise survey.

Enterprise AI spending is becoming a token-consumption problem

Seats predict access. They don't predict how much work agents will do.

Agents multiply tokens for mechanical reasons. Each step usually resends the conversation so far, so a 20-step task pays for its early context many times over. Tool results, such as search pages, file contents and test logs, land back in the context. Planning and self-checking add calls. Failed steps are retried. Parallel agents each carry their own copy of shared context.

Anthropic measured this on its own system in 2025. In its write-up of a multi-agent research system, it found that agents “typically use about 4× more tokens than chat interactions,” and multi-agent systems “about 15× more tokens than chats.” As UniverseBlend’s analysis of when adding an agent stops paying for itself put it, the unit of cost isn’t the agent but the model call, and “every call pays for its whole input again.”

That’s how prices and bills move in opposite directions. If a token costs a third as much but a task uses ten times as many tokens, the task costs more than three times as much. Enterprise AI spending stops tracking headcount and starts tracking how much work agents are given.

Open-source models take the volume. Frontier labs take the money

Open-source models do a fifth of the token work for a twenty-fifth of the spending. Menlo Ventures estimates.

Menlo reports that open-source models handled about 19% of tokens but captured only 4% of model spending. Its words: “Open-source is gaining ground in usage, but losing spending share.”

Token economics: 19% of tokens, 4% of enterprise AI spending
Menlo estimateOpen-source modelsAll other models
Share of tokens19%81%
Share of model spending4%96%
Average price per million tokens~$0.13 (open-source average)~$0.70 (closed-model blended)

The arithmetic is worth doing (UniverseBlend analysis). Open-source models earn 4 points of spending for 19 points of tokens, about 0.21 per point. Other models earn 96 for 81, about 1.19 per point. That’s a gap of about 5.6x per token. Menlo’s average prices differ by about 5.4x, $0.70 against $0.13. If both shares describe the same traffic, the spending gap is almost entirely a price gap. Open-source models are doing a growing share of the work. They’re just much cheaper per unit.

A terminology note. Menlo says “open-source”, but most of these models are open-weight: the trained weights can be downloaded, while training data and code often aren’t released. The Open Source Initiative’s Open Source AI Definition requires data information and complete training code as well. And $0.13 is Menlo’s estimated average, not a price every provider charges.

Self-hosting changes the economics again. A company running an open-weight model on its own GPUs pays nothing per token to a model vendor, but it pays for hardware, power, engineering time and idle capacity. Some of that spending shows up as infrastructure rather than model spend. Our comparison of Chinese open-weight models shows how hardware needs vary across popular options.

Why frontier labs keep 69% of enterprise AI spending

Anthropic, OpenAI and Google together hold 69% of enterprise AI deployment spending, about $122.7 billion, up from 50%. On a narrower measure, enterprise LLM API spending, Menlo puts Anthropic at 55% (from 40%), OpenAI at 31% (from 27%) and Google at 9% (from 21%). These are different denominators. Deployment spending includes infrastructure and applications. API spending covers only model calls. Neither is a share of tokens.

A qualification belongs here. Menlo Ventures is an investor in Anthropic and OpenRouter, both central to the report, and it marks portfolio companies with asterisks. The research is valuable primary data. But its authors’ commercial position is relevant to how readers weigh its market-share findings, especially Anthropic’s rise. OpenRouter’s ownership is also changing: Stripe agreed to acquire it in August.

Why pay five times more per token? The report doesn’t measure this directly, so what follows is interpretation. For agentic work, the cost that matters is cost per completed task, not cost per token. A model that finishes a coding task in fewer steps, or without a failed run, can be cheaper overall. Enterprises also pay for reliability, security reviews, existing contracts and integration with tools they already use. The data shows the premium persisting. It doesn’t prove why.

Where the $177B of enterprise AI spending goes

Category (Menlo estimates)Amount
Deployment total$176.8B
Infrastructure$99.5B
Applications$77.3B
of which coding$34.0B
of which assistants and chatbots$25.0B
of which healthcare$3.7B
Development (separate)$102.5B

Infrastructure, the stack that runs models and agents, is the larger half. Within applications, coding and assistants take 76%. Healthcare, in third place at $3.7 billion, is a long way behind.

Why coding leads enterprise AI spending

Coding suits agents better than almost any other job, which is why it dominates enterprise AI spending on applications. The work lives in a repository. Tools are scriptable. Compilers and test suites give fast, objective feedback, so an agent can try, fail, check and retry without a human. Success is easier to define than in a sales forecast or a legal review.

That’s also why coding is expensive. Every test run and retry is more tokens. UniverseBlend’s look at who’s paying for coding agents’ tokens found that the larger cost often comes after generation, in review and rework. Functions with subjective decisions, scattered data or unclear success criteria will adopt agents more slowly, and their spending will grow more slowly too.

Budgets fell behind enterprise AI spending

The budget figures show how badly forecasts missed. Menlo’s survey found:

Survey respondentsPlannedActual
Average spend vs prior year1.9x4.7x
Median spend vs prior year1.8x2.2x

On average, companies spent about 2.5 times what they had planned to grow by. The median company overshot only modestly, about 1.2 times its plan. The gap between average and median means a minority of heavy users is pulling the average up: companies where agents went from pilot to production and consumption took off. It does not mean every company spent 2.5 times its budget.

Most of the growth in enterprise AI spending is new money rather than reallocated budget. Menlo says 55% of incremental AI spending came from new budgets and 22% from existing software budgets. Another 13% came from incumbents converting SaaS licences to AI, and 9%, about $12.6 billion, shifted to AI-native vendors. The report found “limited evidence” of enterprises replacing core systems such as Salesforce’s CRM, Workday or NetSuite. AI is adding to the software bill, not yet replacing it.

What the Menlo report gets right, and what to question

The survey covered nearly 400 US enterprise decision-makers responsible for more than $4 billion in AI spending. Morning Consult fielded it from 8 to 26 September 2026. Market sizes are Menlo estimates built from that survey, public filings and third-party reports, expressed as annualised run rates. That’s a strong dataset for direction and proportion. It isn’t an audited sum of invoices, and it’s US-only.

Three cautions:

  • The baseline was restated. Menlo’s December 2025 report put 2025 enterprise generative AI spending at $37 billion. The new report uses $33 billion for the prior year, after reclassifying data-labelling vendors such as Mercor from deployment to development. On the old base, growth would be about 4.8x.
  • Two datasets are in play. Agent and token findings come from OpenRouter, while budget findings come from the enterprise survey. They shouldn’t be blended.
  • Portfolio relationships run through the market-share findings, as noted above.

None of this makes the report unreliable, and it remains one of the few detailed public estimates of enterprise AI spending. It makes it a well-sourced estimate from an interested party, which is how readers should treat it.

How to budget enterprise AI spending for 2027

The lesson for budget owners is that AI is turning into a consumption line, more like cloud than SaaS. A fixed seat budget can’t predict what agents will cost, because their cost depends on how many tasks they run, how many tokens each task takes and which model does the work.

An illustrative agent budget

Every number here is an assumption, chosen only to show the mechanics. None is a quote from a provider.

Cost lineAssumptionAnnual cost
Employee assistant seats500 seats × $40 a month$240,000
Agent model usage2,000 tasks a day × 1.5M tokens × $1 per million, 250 working days$750,000
Tools and infrastructure20% of model usage (sandboxes, search, vector stores)$150,000
Monitoring and evaluation10% of model usage$75,000
Human reviewNot priced here; often the largest hidden costVaries

The seats are fixed. Everything else moves with volume. If tasks double, or each task takes twice the tokens because agents retry more, model usage rises to $1.5 million. Switch some work to an open-weight model at a fraction of the price and it falls sharply, if quality holds. At Menlo’s $0.70 closed-model average, the same agent line would be $525,000. At a frontier model priced several times higher, it could be millions.

Practical steps follow from that:

  • Budget agents per task, not per user.
  • Track cost per completed task, not per token.
  • Set spending limits per agent.
  • Route routine work to cheaper models.
  • Review forecasts quarterly rather than annually.

The $177 billion headline will be quoted for months. The more useful finding sits underneath it: enterprise AI spending now follows the work AI does, not the number of people who can use it. Tokens will probably keep getting cheaper. Whether bills shrink depends on how many tasks companies hand to agents, how efficiently those agents finish them and which models they run on. Finance teams that still treat AI as a seat count will keep being surprised.

Frequently asked questions

How much is enterprise AI spending in 2026?

Menlo Ventures estimates enterprise AI deployment spending reached $176.8 billion by September 2026, as an annualised run rate. That’s up from a restated $33 billion the year before.

Why has enterprise AI spending increased so quickly?

Existing adopters are using far more AI, largely through agents that consume many tokens per task. Adoption itself rose only from 55% to 65%.

How much enterprise AI spending is driven by agents?

Menlo doesn’t give a dollar figure. On OpenRouter, agents generate about 80% of tokens, but that platform skews towards developers and startups.

Why do AI agents consume more tokens than chatbots?

They work in many steps, resend context each time, read tool outputs, plan, verify and retry. Anthropic measured agents using about four times the tokens of chats.

How much enterprise AI usage comes from open-source models?

About 19% of tokens, according to Menlo, but only 4% of model spending, because their average price is much lower.

Why do frontier AI companies capture most enterprise AI spending?

They hold 69% of deployment spending in Menlo’s estimate. Likely reasons include capability, reliability and integration, though the report doesn’t prove the cause.

What is the difference between AI deployment and development spending?

Deployment spending is money spent using and running AI. Development spending is money spent building models, mainly training compute and data.

How should companies budget for AI agents?

Budget per task, track cost per completed task, set usage limits and review forecasts quarterly, since agent costs vary with volume and model choice.

Are open-weight models cheaper for enterprise use?

Usually per token, yes. Total cost depends on quality, how many retries tasks need, and whether you pay a provider or run your own hardware.

Will enterprise AI spending keep growing?

The report doesn’t forecast 2027. Agent adoption and falling prices push in opposite directions, so the outcome depends on how much work companies hand to agents.


Keep reading

Anthropic IPO valuation

Anthropic IPO: The $895 Billion Question Behind Its Valuation

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …
Claude Opus vs Sonnet

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …
RSA-1024

Did AI Break RSA? What DeepMind Actually Found

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …
Model Distillation

Model Distillation Explained: When AI Learning Becomes Extraction

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …