📰  Tech Blog |     📄  Full Report

1. Model Introduction

Kimi K3 is an open-weight, na­tive mul­ti­modal agen­tic model and our most ca­pa­ble model to date. It is a 2.8T-parameter model built on Kimi Delta Attention (KDA) and Attention Residuals (AttnRes), with na­tive vi­sion ca­pa­bil­i­ties and a 1-million-token con­text win­dow. It is the world’s first open 3T-class model, de­signed for fron­tier in­tel­li­gence across long-hori­zon cod­ing, knowl­edge work, and rea­son­ing.

Key Features

New Architecture: Kimi K3 is built on Kimi Delta Attention (KDA) and Attention Residuals (AttnRes), and scales up MoE spar­sity with a Stable LatentMoE frame­work that ac­ti­vates 16 out of 896 ex­perts — yield­ing an ap­prox­i­mate 2.5× im­prove­ment in over­all scal­ing ef­fi­ciency over Kimi K2.

Long-Horizon Coding: Operating with min­i­mal hu­man over­sight, Kimi K3 sus­tains long en­gi­neer­ing ses­sions, nav­i­gates mas­sive repos­i­to­ries, and or­ches­trates ter­mi­nal tools — from GPU ker­nel op­ti­miza­tion and com­piler de­vel­op­ment to vi­sion-in-the-loop game dev, CAD, and even chip de­sign.

Agentic Knowledge Work: Kimi K3 ad­vances end-to-end knowl­edge work, pro­duc­ing deep re­search with in­ter­ac­tive vi­su­al­iza­tions, wid­gets and dash­boards, and mo­tion de­sign and video edit­ing, pow­ered by its na­tive mul­ti­modal ar­chi­tec­ture.

Native Multimodality & Long Context: Kimi K3 un­der­stands text, im­ages, and video within the same model, and sup­ports a 1-million-token con­text win­dow.

Open Frontier Weights: We re­lease the full Kimi K3 model weights un­der the Kimi K3 License, mak­ing fron­tier in­tel­li­gence openly avail­able for re­search, de­ploy­ment, and fur­ther in­no­va­tion.

2. Model Summary

3. Evaluation Results

All Kimi K3 re­sults are ob­tained with rea­son­ing ef­fort set to ‘max’ and tem­per­a­ture = 1.0. For sin­gle-step tasks, such as GPQA Diamond, HLE-Full, and vi­sion bench­marks with­out tools, we set top-p = 0.95; for agen­tic tasks, we set top-p = 1.0. For HLE-Full, MMMU-Pro, CharXiv (RQ), MathVision, and ZeroBench, each cell re­ports the scores with­out and with tool aug­men­ta­tion (general tools for HLE-Full, Python for the vi­sion bench­marks), in that or­der.

Reasoning & knowl­edge bench­marks CritPt and AA-LCR. Scores are cited from Artificial Analysis as of July 23, 2026.

CritPt and AA-LCR. Scores are cited from Artificial Analysis as of July 23, 2026.

Coding bench­marks DeepSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is taken from the GLM-5.2 re­lease blog; all re­main­ing scores are from the of­fi­cial DeepSWE leader­board, un­der which Kimi K3 at­tains 67.3 with the mini-SWE-agent har­ness. We re­port the DeepSWE v1.1 tasks. Terminal-Bench 2.1. Kimi K3 is eval­u­ated with the Kimi Code har­ness. For all other mod­els, we re­port the best score across har­nesses: GLM-5.2 with Claude Code (GLM-5.2 re­lease blog); Claude Opus 4.8 and Claude Fable 5 with Terminus 2 (Artificial Analysis); GPT-5.5 and GPT-5.6 Sol with Codex (OpenAI). ProgramBench. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog; all other scores are from Vals AI. SWE-Marathon. Kimi K3, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.6 Sol is eval­u­ated with the Codex har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog. Our eval­u­a­tion is based on an H20-calibrated branch of the of­fi­cial tasks as of July 9, 2026, prior to the fi­nal v1.1 re­lease: the Docker im­ages, per­for­mance gates, and ref­er­ence or­a­cles for the GPU tasks have been re­cal­i­brated for H20, while the cor­rect­ness and anti-cheat val­ida­tors re­main un­changed. Additionally, Claude Fable 5 hit fall­backs on 35% of the tasks in our eval­u­a­tion, which may have neg­a­tively im­pacted its mea­sured per­for­mance. FrontierSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness and GPT-5.6 Sol with the Codex har­ness; all other re­sults are from FrontierSWE. Dominance scores are re­com­puted from the raw scores us­ing the of­fi­cial eval­u­a­tion script and are cur­rent as of July 16, 2026. PostTrainBench. Scores for GLM-5.2, GPT-5.5, and Claude Opus 4.8 are adopted from the of­fi­cial PostTrainBench re­sults. Kimi K3, Claude Fable 5, and GPT-5.6 Sol are eval­u­ated with the of­fi­cial Harbor im­ple­men­ta­tion at max­i­mum rea­son­ing ef­fort, av­er­aged over three runs on H20 GPUs (instead of H100 in the of­fi­cial set­ting) — Kimi K3 and Claude Fable 5 with the Claude Code har­ness, and GPT-5.6 Sol with the Codex har­ness. MLS-Bench-Lite. Kimi K3 is eval­u­ated with the Kimi Code har­ness; GLM-5.2 and the Claude mod­els with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness. SciCode. Scores are cited from Artificial Analysis as of July 23, 2026. Kimi Code Bench 2.0 (in-house). Kimi K3 is eval­u­ated with the Kimi Code har­ness (it at­tains 73.7 with the Claude Code har­ness); GLM-5.2, Claude Opus 4.8, and Claude Fable 5 with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness. All mod­els are eval­u­ated at max­i­mum rea­son­ing ef­fort, ex­cept GPT-5.5, which uses the “xhigh” set­ting. As the bench­mark in­cludes cy­ber­se­cu­rity and safety-re­lated tasks, we also dis­close the frac­tion of re­fused or fall­back tasks: Claude Fable 5 hit 13 fall­backs and 1 re­fusal out of 80 tasks; 10 re­fusals out of 80 tasks en­tered GPT-5.6 Sol’s cy­ber guard; GPT-5.5 had 3 re­fusals out of 80 tasks.

DeepSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is taken from the GLM-5.2 re­lease blog; all re­main­ing scores are from the of­fi­cial DeepSWE leader­board, un­der which Kimi K3 at­tains 67.3 with the mini-SWE-agent har­ness. We re­port the DeepSWE v1.1 tasks.

Terminal-Bench 2.1. Kimi K3 is eval­u­ated with the Kimi Code har­ness. For all other mod­els, we re­port the best score across har­nesses: GLM-5.2 with Claude Code (GLM-5.2 re­lease blog); Claude Opus 4.8 and Claude Fable 5 with Terminus 2 (Artificial Analysis); GPT-5.5 and GPT-5.6 Sol with Codex (OpenAI).

ProgramBench. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog; all other scores are from Vals AI.

SWE-Marathon. Kimi K3, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.6 Sol is eval­u­ated with the Codex har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog. Our eval­u­a­tion is based on an H20-calibrated branch of the of­fi­cial tasks as of July 9, 2026, prior to the fi­nal v1.1 re­lease: the Docker im­ages, per­for­mance gates, and ref­er­ence or­a­cles for the GPU tasks have been re­cal­i­brated for H20, while the cor­rect­ness and anti-cheat val­ida­tors re­main un­changed. Additionally, Claude Fable 5 hit fall­backs on 35% of the tasks in our eval­u­a­tion, which may have neg­a­tively im­pacted its mea­sured per­for­mance.

FrontierSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness and GPT-5.6 Sol with the Codex har­ness; all other re­sults are from FrontierSWE. Dominance scores are re­com­puted from the raw scores us­ing the of­fi­cial eval­u­a­tion script and are cur­rent as of July 16, 2026.

PostTrainBench. Scores for GLM-5.2, GPT-5.5, and Claude Opus 4.8 are adopted from the of­fi­cial PostTrainBench re­sults. Kimi K3, Claude Fable 5, and GPT-5.6 Sol are eval­u­ated with the of­fi­cial Harbor im­ple­men­ta­tion at max­i­mum rea­son­ing ef­fort, av­er­aged over three runs on H20 GPUs (instead of H100 in the of­fi­cial set­ting) — Kimi K3 and Claude Fable 5 with the Claude Code har­ness, and GPT-5.6 Sol with the Codex har­ness.

MLS-Bench-Lite. Kimi K3 is eval­u­ated with the Kimi Code har­ness; GLM-5.2 and the Claude mod­els with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness.

SciCode. Scores are cited from Artificial Analysis as of July 23, 2026.

Kimi Code Bench 2.0 (in-house). Kimi K3 is eval­u­ated with the Kimi Code har­ness (it at­tains 73.7 with the Claude Code har­ness); GLM-5.2, Claude Opus 4.8, and Claude Fable 5 with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness. All mod­els are eval­u­ated at max­i­mum rea­son­ing ef­fort, ex­cept GPT-5.5, which uses the “xhigh” set­ting. As the bench­mark in­cludes cy­ber­se­cu­rity and safety-re­lated tasks, we also dis­close the frac­tion of re­fused or fall­back tasks: Claude Fable 5 hit 13 fall­backs and 1 re­fusal out of 80 tasks; 10 re­fusals out of 80 tasks en­tered GPT-5.6 Sol’s cy­ber guard; GPT-5.5 had 3 re­fusals out of 80 tasks.

Agentic bench­marks OfficeQA Pro. Each test case pro­vides the agent with the en­tire PDF cor­pus, with all PDFs ren­dered as im­ages and no ma­chine-read­able text avail­able. OfficeQA Pro and SpreadsheetBench 2. Kimi K3, GLM-5.2, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol are eval­u­ated with the Codex har­ness. MCP-Atlas. All mod­els are eval­u­ated on the 500-task pub­lic sub­set with a 100-turn limit, us­ing Gemini 3.1 Pro as the judge. AutomationBench. All mod­els are eval­u­ated on the 600-task pub­lic sub­set, fol­low­ing the of­fi­cial GitHub setup in all other re­spects. BrowseComp. We adopt a con­text-com­paction strat­egy trig­gered at 300K to­kens. When eval­u­ated with the full 1M-token con­text win­dow and no con­text man­age­ment, Kimi K3 achieves a score of 90.4. The re­sults of Claude Fable 5, Claude Opus 4.8, GPT-5.6 Sol, and GPT-5.5 are cited from Anthropic and OpenAI. GDPval-AA v2, AA-Briefcase, τ³-Bank­ing, Harvey Lab-AA, and APEX-Agents. Scores are cited from Artificial Analysis and the APEX-Agents leader­board as of July 23, 2026. For Harvey Lab-AA, we re­port the cri­te­rion pass rate. CorpFin v2, Finance Agent v2, and Legal Research Bench. Scores are cited from Vals AI. Agents’ Last Exam. Scores are cited from the of­fi­cial leader­board as of July 23, 2026; we re­port the leader­board’s pri­mary pass-rate met­ric. On the leader­board, each model is paired with a spe­cific har­ness: Kimi K3 with Kimi Code; GPT-5.6 Sol and GPT-5.5 with Codex; Claude Fable 5, Claude Opus 4.8, and GLM-5.2 with Claude Code. † The Claude Fable 5 en­try runs at xhigh ef­fort with 40% of tasks an­no­tated as down­graded.

OfficeQA Pro. Each test case pro­vides the agent with the en­tire PDF cor­pus, with all PDFs ren­dered as im­ages and no ma­chine-read­able text avail­able.

OfficeQA Pro and SpreadsheetBench 2. Kimi K3, GLM-5.2, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol are eval­u­ated with the Codex har­ness.

MCP-Atlas. All mod­els are eval­u­ated on the 500-task pub­lic sub­set with a 100-turn limit, us­ing Gemini 3.1 Pro as the judge.

AutomationBench. All mod­els are eval­u­ated on the 600-task pub­lic sub­set, fol­low­ing the of­fi­cial GitHub setup in all other re­spects.

BrowseComp. We adopt a con­text-com­paction strat­egy trig­gered at 300K to­kens. When eval­u­ated with the full 1M-token con­text win­dow and no con­text man­age­ment, Kimi K3 achieves a score of 90.4. The re­sults of Claude Fable 5, Claude Opus 4.8, GPT-5.6 Sol, and GPT-5.5 are cited from Anthropic and OpenAI.

GDPval-AA v2, AA-Briefcase, τ³-Bank­ing, Harvey Lab-AA, and APEX-Agents. Scores are cited from Artificial Analysis and the APEX-Agents leader­board as of July 23, 2026. For Harvey Lab-AA, we re­port the cri­te­rion pass rate.

CorpFin v2, Finance Agent v2, and Legal Research Bench. Scores are cited from Vals AI.

Agents’ Last Exam. Scores are cited from the of­fi­cial leader­board as of July 23, 2026; we re­port the leader­board’s pri­mary pass-rate met­ric. On the leader­board, each model is paired with a spe­cific har­ness: Kimi K3 with Kimi Code; GPT-5.6 Sol and GPT-5.5 with Codex; Claude Fable 5, Claude Opus 4.8, and GLM-5.2 with Claude Code. † The Claude Fable 5 en­try runs at xhigh ef­fort with 40% of tasks an­no­tated as down­graded.

Multimodal bench­marks Except for ZeroBench, which fol­lows the of­fi­cial set­ting and is run five times, all mul­ti­modal scores are av­er­aged over three runs. MMMU-Pro is eval­u­ated fol­low­ing the of­fi­cial pro­to­col, pre­serv­ing the orig­i­nal in­put or­der and prepend­ing im­ages to the text in­put. PerceptionBench is an in-house bench­mark that fo­cuses on atomic vi­sual per­cep­tion ca­pa­bil­i­ties.

Except for ZeroBench, which fol­lows the of­fi­cial set­ting and is run five times, all mul­ti­modal scores are av­er­aged over three runs. MMMU-Pro is eval­u­ated fol­low­ing the of­fi­cial pro­to­col, pre­serv­ing the orig­i­nal in­put or­der and prepend­ing im­ages to the text in­put.

PerceptionBench is an in-house bench­mark that fo­cuses on atomic vi­sual per­cep­tion ca­pa­bil­i­ties.

4. Native MXFP4 Quantization

Kimi K3 ap­plies quan­ti­za­tion-aware train­ing from the SFT stage on­ward, us­ing MXFP4 weights with MXFP8 ac­ti­va­tions for broad hard­ware com­pat­i­bil­ity.

5. Deployment

You can ac­cess Kimi K3′s API on https://​plat­form.kimi.ai by se­lect­ing kimi-k3, and we pro­vide OpenAI/Anthropic-compatible API for you. Currently, Kimi K3 is rec­om­mended to run on the fol­low­ing in­fer­ence en­gines:

You can ac­cess Kimi K3′s API on https://​plat­form.kimi.ai by se­lect­ing kimi-k3, and we pro­vide OpenAI/Anthropic-compatible API for you. Currently, Kimi K3 is rec­om­mended to run on the fol­low­ing in­fer­ence en­gines:

vLLM — see recipes

SGLang — see cook­book

TokenSpeed — see recipes

6. Model Usage

Kimi K3 al­ways has think­ing en­abled, and will re­turn rea­son­ing_­con­tent. Thinking ef­fort is con­fig­ured with the top-level rea­son­ing_­ef­fort re­quest field, which sup­ports “low”, “high”, and “max” (default “max”).

Kimi K3 was trained in the pre­served think­ing his­tory mode. For multi-turn con­ver­sa­tions and tool calls, Kimi K3 re­quires the com­plete as­sis­tant mes­sage re­turned by the API to be passed back to mes­sages as-is — in­clud­ing rea­son­ing_­con­tent and tool_­calls, not just con­tent:

im­port ope­nai

def chat_with­_p­re­served_­think­ing(client: ope­nai.Ope­nAI, mod­el_­name: str): mes­sages = [ { “role”: “user”, “content”: “Tell me three ran­dom num­bers.” }, { “role”: “assistant”, “reasoning_content”: “I’ll start by list­ing five num­bers: 473, 921, 235, 215, 222, and I’ll tell you the first three.”, “content”: “473, 921, 235″ }, { “role”: “user”, “content”: “What are the other two num­bers you have in mind?” } ]

re­sponse = client.chat.com­ple­tions.cre­ate( model=mod­el_­name, mes­sages=mes­sages, stream=False, max_­to­kens=4096, rea­son­ing_­ef­fort=“max”, ) # the as­sis­tant should men­tion 215 and 222 that ap­pear in the prior rea­son­ing con­tent print(f”re­sponse: {response.choices[0].message.reasoning}“) re­turn re­sponse.choices[0].mes­sage.con­tent

For full guides and ex­am­ples (vision in­put, struc­tured out­put, par­tial mode, tool choice, dy­namic tool load­ing, con­text caching), see the Kimi K3 Quickstart and Thinking Effort.

Coding Agent Framework

Kimi K3 works best with Kimi Code CLI as its agent frame­work. We warmly in­vite you to give it a try — run Kimi Code in your ter­mi­nal and se­lect Kimi K3 us­ing the /model com­mand. We hope you en­joy build­ing with Kimi K3, and we would love to hear your feed­back!

7. License

Both the code repos­i­tory and the model weights are re­leased un­der the Kimi K3 License.

8. Contact Us

If you have any ques­tions, please reach out at sup­port@moon­shot.ai.

Safetensors

Model tree for moon­shotai/​Kimi-K3

Spaces us­ing moon­shotai/​Kimi-K3 5

Collection in­clud­ing moon­shotai/​Kimi-K3

🦔AI com­pa­nies are bulk-buy­ing rare books, scan­ning them through high-speed ma­chines that cut the spines off, and shred­ding the orig­i­nals. A ser­vice called ISBNdb fa­cil­i­tates or­ders of up to a mil­lion books and keeps buy­ers anony­mous. Pre-2022 books are pre­mium be­cause they’re free of AI-generated text. A fed­eral judge ruled the prac­tice is fair use be­cause elim­i­nat­ing the orig­i­nal means only one copy ex­ists at a time. Anthropic hired the for­mer head of Google Books part­ner­ships to ob­tain “all the books in the world.”

My Take This got to me. A book­seller told 404 Media that rare books with al­most no sur­viv­ing copies are be­ing fed into this pipeline. Books that sur­vived wars, fires, and cen­turies of han­dling are be­ing shred­ded so an AI can learn to write a bet­ter mar­ket­ing email. ISBNdb’s web­site lit­er­ally says “‘AI com­pany de­stroys two mil­lion books’ is not a head­line that gen­er­ates sym­pa­thy,” and they still built an en­tire busi­ness around mak­ing it hap­pen qui­etly. They of­fer NDAs as a fea­ture. They coach clients to call it “digital preser­va­tion.”

I’ve cov­ered AI com­pa­nies scrap­ing the in­ter­net, tor­rent­ing li­braries, and steal­ing mu­sic. This is worse be­cause it’s ir­re­versible. You can re-up­load a web­site. You can reprint a best­seller. You can’t re­place the last three copies of an 18th-century botan­i­cal text once some­one shreds them for train­ing data. And the judge said it’s le­gal. So it’s go­ing to ac­cel­er­ate. “We shred rare books and of­fer NDAs so no­body finds out” is a le­git­i­mate busi­ness model in 2026. What a time­line.

Hedgie🤗

Jul 27, 2026 · 12:18 AM UTC

1,498

11,594

21,626

1,399,725

A post by Dario Amodei, Anthropic CEO

Over the last few days there has been a lot of dis­cus­sion about open-weights mod­els, es­pe­cially those from China. Reports sug­gest that some US of­fi­cials are con­sid­er­ing ban­ning the use of Chinese open-weights mod­els by US com­pa­nies. In re­sponse, many tech com­pa­nies have signed a let­ter sup­port­ing open-weights mod­els, and some peo­ple have even ac­cused Anthropic of want­ing to ban open-weights mod­els as a means of pro­tect­ing our busi­ness. Anyone who has read my past writ­ing should know that I don’t re­gard such bans as a use­ful mea­sure, but let me state it clearly so that there is no doubt: Anthropic has never ad­vo­cated for a ban on open-weights mod­els.

Open-weights mod­els that don’t have dan­ger­ous ca­pa­bil­i­ties are a pub­lic good: they don’t cost any­thing be­sides the com­pute needed to run them, and they pro­vide value to busi­nesses, de­vel­op­ers, and re­searchers.

Protectionist bans would not ad­dress my most se­ri­ous na­tional se­cu­rity con­cerns. Specifically, I am wor­ried about two night­mare sce­nar­ios. I laid these out in my es­say The Adolescence of Technology six months ago1, and have held these po­si­tions con­sis­tently for many years:

My pri­mary con­cern is the risk that au­thor­i­tar­ian gov­ern­ments—not solely the Chinese Communist Party (CCP), al­though the CCP is clearly the most ca­pa­ble threat—build AI mod­els that are more pow­er­ful than those built by the US, and use them to achieve per­ma­nent mil­i­tary su­pe­ri­or­ity or per­pe­trate in­cred­i­bly deep re­pres­sion of their own peo­ple. This con­cern is widely shared within the US gov­ern­ment: Vice President Vance warned in Paris last year that “authoritarian regimes have stolen and used AI to strengthen their mil­i­tary, in­tel­li­gence, and sur­veil­lance ca­pa­bil­i­ties,” and the Intelligence Community’s 2026 Annual Threat Assessment found that “other global pow­ers’ ro­bust progress in AI is chal­leng­ing US eco­nomic com­pet­i­tive­ness and na­tional se­cu­rity ad­van­tages.” It is ir­rel­e­vant whether these mod­els are re­leased with open weights, and cer­tainly ir­rel­e­vant whether they are used by US busi­nesses. In fact, the most dan­ger­ous model may be one that is trained in se­cret and handed only to the People’s Liberation Army for use in drones and the Ministry of State Security for sur­veil­lance and re­pres­sion.

My sec­ondary con­cern is the risk that pow­er­ful AI mod­els may be mis­used to carry out cy­ber­at­tacks or bi­o­log­i­cal at­tacks, and may have se­ri­ous align­ment prob­lems. Open-weights mod­els—it does not mat­ter whether they come from China or any­where else—do po­ten­tially pre­sent a higher risk than closed mod­els, be­cause it is very dif­fi­cult to ap­ply guardrails to them or mon­i­tor their us­age, and once weights are re­leased they can­not be with­drawn2. But ban­ning the use of these mod­els by US busi­nesses does noth­ing to ad­dress this risk, be­cause bad ac­tors are un­likely to be le­git­i­mate US busi­nesses. It would pro­tect US AI com­pa­nies from com­pe­ti­tion, but that has never been my goal.

To ad­dress these con­cerns, I do sup­port the fol­low­ing three mea­sures, which I and Anthropic have con­sis­tently ad­vo­cated for:

We should not sell pow­er­ful chips or chip­mak­ing equip­ment to China, and we should crack down on the ram­pant smug­gling3 and workarounds used to ob­tain ac­cess to such chips. China has lim­ited do­mes­tic pro­duc­tion ca­pac­ity, and there­fore, due to the scal­ing laws, can­not build more pow­er­ful mod­els than the US with­out US chips. This is the most ef­fi­cient and di­rect way to block threat #1, and by ham­per­ing the train­ing of mod­els that are out of reach of US law, it also in­di­rectly helps with threat #2.

We should crack down on in­dus­trial-scale dis­til­la­tion op­er­a­tions. Distillation is a much more com­pute-ef­fi­cient process than train­ing mod­els from scratch. It al­lows China to build much bet­ter mod­els than its num­ber of chips would or­di­nar­ily en­able, and thus par­tially evade chip bans. Distillation does not al­low the CCP to ob­tain equiv­a­lent or su­pe­rior AI ca­pa­bil­i­ties to the US, but it can bring the Chinese fron­tier to within a few months of the US fron­tier. It is true that many of the com­pa­nies car­ry­ing out these op­er­a­tions re­lease open-weights mod­els—but the open weights are far less rel­e­vant than the fact that the op­er­a­tions are backed by an au­thor­i­tar­ian state seek­ing to over­take the US at the fron­tier. We should have pol­icy in­ter­ven­tions to de­ter this be­hav­ior. A blan­ket ban on open-weights mod­els is nei­ther the cor­rect rem­edy nor some­thing we have called for4.

All suf­fi­ciently ca­pa­ble mod­els, open and closed, should go through manda­tory safety test­ing. The best way to ad­dress threat #2 is to just di­rectly test mod­els for cy­ber, bi­o­log­i­cal, and align­ment risks be­fore re­lease. I think this idea is ac­tu­ally close to a con­sen­sus: I have been heart­ened both that the Trump ad­min­is­tra­tion has moved in this di­rec­tion in re­cent months, and by re­cent in­dus­try pro­pos­als that would ap­ply such test­ing to the most ca­pa­ble mod­els re­gard­less of their coun­try of ori­gin or whether they are open or closed (while ex­empt­ing less ca­pa­ble mod­els, such as those from star­tups and acad­e­mia, en­tirely). Whether open mod­els do or don’t pose an in­creased risk, and whether that risk can be mit­i­gated, is some­thing that should emerge from test­ing, rather than be de­cided in ad­vance—and there may be promis­ing meth­ods for im­prov­ing the safety of open-weights mod­els, in­clud­ing re­cent re­search from Anthropic on mod­u­lar train­ing strate­gies. Note that to be ef­fec­tive, test­ing would need to be global, which means even the CCP would need to be on board. I think this may ac­tu­ally be pos­si­ble: as I wrote in The Adolescence of Technology, lim­ited co­op­er­a­tion around pre­vent­ing AI bi­o­log­i­cal weapons may be pos­si­ble be­cause it is in China’s in­ter­est too.

This brings me to the open let­ter. I agree with much of it: open weights ex­pand ac­cess to the AI econ­omy, they strengthen com­pe­ti­tion at least for some use cases, and they give cus­tomers greater con­trol. Concerns about dis­til­la­tion should be ad­dressed through tar­geted le­gal and com­mer­cial frame­works—the same mea­sure I de­scribed above. But I don’t agree with the let­ter’s as­ser­tions that open-weights mod­els nec­es­sar­ily make it eas­ier to de­velop safe­guards or that broad ac­cess to ca­pa­bil­i­ties nec­es­sar­ily helps de­fend­ers more than at­tack­ers. It seems at least as likely to me that the op­po­site will be true. For ex­am­ple, I worry that bi­ol­ogy will have a strong at­tacker-de­fender asym­me­try, where suf­fi­ciently ca­pa­ble mod­els may be able to quickly weaponize pan­demic-level viruses with widely avail­able ma­te­ri­als, whereas de­fense against these agents is a multi-year op­er­a­tional task in the best case (as we saw with Operation Warp Speed)5. Questions like this should be em­pir­i­cally an­swered by rig­or­ous pre-re­lease test­ing, not as­sumed in ad­vance.

To sum­ma­rize my and Anthropic’s po­si­tion, we have not and are not ad­vo­cat­ing for a ban on open-weights mod­els as a cat­e­gory. We should in­stead fo­cus on keep­ing pow­er­ful chips out of au­thor­i­tar­ian hands, stop­ping in­dus­trial-scale dis­til­la­tion, and re­quir­ing safety test­ing of all suf­fi­ciently ca­pa­ble mod­els, open and closed.

Related con­tent

Cognizant and Anthropic ex­pand their part­ner­ship to bring Claude to en­ter­prise clients

Read more

Introducing Claude Opus 5

Opus 5 is a step change im­prove­ment for the Opus tier pow­er­ing long-run­ning agents while de­liv­er­ing im­prove­ments in cod­ing and pro­fes­sional work.

Read more

A re­search agenda for the Economic Futures Research Fund

We’re shar­ing the re­search agenda for the Anthropic Economic Futures Research Fund.

Read more

I think it’s im­por­tant to be very Canny when some­one makes a claim that sup­ports a com­pa­ny’s large val­u­a­tion.

The Bun rewrite seems well po­si­tioned as proof-pos­i­tive that AI and specif­i­cally Anthropic’s AI can do the work of open-source main­tain­ers, for some money, but faster.

On the 8th of July 2026 Jarred Summner of Bun fame posted about “Rewriting Bun in Rust”. At the time, I felt pretty Canny, hav­ing al­ready read about Anthropic’s C com­piler and Cursor’s FastRender web browser. It seems like there is a lot of val­u­a­tion money rid­ing on the cod­ing ca­pa­bil­i­ties of AI, and a lot of mar­ket­ing about those ca­pa­bil­i­ties.

It’s not a huge stretch to link the ac­qui­si­tion of Bun by Anthropic with the choice to rewrite Bun with an Anthropic tool. In his ar­ti­cle Jarred claims that over 11 days (between 3rd and 14th May 2026) and at a cost of $165,000 for Anthropic API calls the rewrite was done and then merged to main. This rep­re­sents a cost of $15,000 dol­lars a day, a cost well out­side the means of many open source main­tain­ers. This num­ber does­n’t seem to in­clude the leviathan whirring of the CI/CD in the org’s Buildkite clus­ter, which ap­pears to have been con­stantly whirring ever since the “rewrite” was “completed”.

Why do I put those two words in scare quotes?

Well, on the 9th of July a peer of mine in a group chat said some­thing un­sur­pris­ing given our cur­rent en­vi­ron­ment - breath­lessly pro­claim­ing that the era of AI had emerged, and its her­ald was the “Rewriting Bun in Rust” blog post. So, I de­cided to look into this. Since the 9th I’ve been hav­ing a closer look at the claims and the code, and to­day I cloned the Bun repo:

Receiving ob­jects: 100% (1200304/1200304), 1.23 GiB | 11.97 MiB/s, done.

As of to­day, the 27th of July 2026, a six week pe­riod af­ter the rewrite was merged to main, there’s still no re­lease tag. It’s now been 11 weeks since the last Bun re­lease tag:

2026 – 05-12 15:12:49 – 0700 (tag: bun-v1.3.14)

The last time there was­n’t a Bun re­lease in a month was be­tween the 26th of October 2022 and the 7th of December 2022 when there was a gap of six weeks and November was skipped, be­tween v0.2.2 and v0.3.0:

2022 – 12-07 00:37:40 – 0800 (tag: bun-v0.3.0) 2022 – 10-26 21:06:02 – 0700 (tag: bun-v0.2.2)

On the 9th of July, the num­ber of open pull re­quests from robobun (a proxy for PRs made by claude code) was 1277. As of this mo­ment, on the 27th of July that num­ber is 2475 open PRs. I don’t claim to know for sure but as far as I can see the process of merg­ing to main with Buildkite checks com­pleted seems to take 40-ish min­utes (sometimes it looks like it takes up to an hour and a half). At this rate if we want to merge all the open Claude PRs it’ll only take run­ning the pipeline for 86 days, con­tin­u­ously.

Generously, some of these PRs don’t deal with Rust code. Further in­ves­ti­ga­tion was war­ranted. I ini­tially clicked through some of the PRs and found some ex­tremely re­viewed ones.

At this point I be­gan to sus­pect that much of the cost of the rewrite was off the books. While $15k a day in to­kens widened my eyes a lit­tle (and maybe I’m naive, maybe that’s low), I had­n’t seen the num­bers for the CI/CD costs of Buildkite, and as you might have no­ticed from above, some PRs were writ­ten by Anthropic em­ploy­ees. When I did analy­sis of the data it be­came clear to me that the pro­ject was tick­ing along with more Claude cred­its and more Anthropic em­ployee in­volve­ment:

One of the as­sump­tions I’ve made here is that Jarred Summner’s com­mits dur­ing the rewrite were us­ing Claude.

It’s pretty clear that there was a big spike in Claude us­age when the rewrite be­gan. It seems like, now, Anthropic em­ployee and Robobun in­volve­ment in Rust is ramp­ing up:

It’s nice to see that the Anthropic em­ploy­ees in­volved seemed to have a good work-life bal­ance, tak­ing breaks on the week­end. But, it looks like that pe­riod is over. It seems like we’re ramp­ing up to some­thing, and there’s still no re­lease tag.

What’s pretty ob­vi­ous to me is that we can’t take it at face value that the rewrite is “done” or that it was “done” for $165k USD. The Bun team never made that claim, but I’ve seen and heard those breath­less claims that the rewrite is proof of some­thing, and I do still think we need to be Canny about claims that sup­port a large val­u­a­tion. Anthropic is dog­food­ing this, the ma­chine is still tick­ing along, and Anthropic em­ploy­ees are di­rectly in­volved. If we imag­ine that the rewrite is still cost­ing $10k a day, we’re ap­proach­ing $800k in money spent on this rewrite.

—

I’m not a prim­i­tivist when it comes to AI. Work I’ve done on ML and AI has been some of the work I’ve been most proud of. This cur­rent hype cy­cle is, how­ever, the worst I’ve ever seen the hype get. Back in 2015 I had to plead with man­age­ment, try­ing to get them to un­der­stand that a black-box bunch of lin­ear al­ge­bra that was bet­ter than hu­mans at a quan­ti­ta­tive task was, just, bet­ter. Now it seems like the world has com­pletely re­versed, and man­age­ment is so forth­right in their be­lief that AI is good, that they want it rubbed on every­thing. And those val­u­a­tions are some­times con­tin­gent on AI eat­ing every­thing:

In my tini­est mouse voice ever I want to ask prob­a­bly the most rel­e­vant ques­tion one can ask about a Business Thing: Was it worth the money and are the com­pa­nies worth the val­u­a­tion?

Are we done yet?

P.S. Anthropic’s C com­piler and Cursor’s FastRender web browser haven’t had any com­mits for months.

P.P.S. I’m look­ing for a job.

AI CODE CREATIONGitHub CopilotWrite bet­ter code with AIGitHub Copilot ap­pDi­rect agents from is­sue to mergeMCP RegistryIntegrate ex­ter­nal tools­DE­VEL­OPER WORKFLOWSActionsAutomate any work­flow­Code­spacesIn­stant dev en­vi­ron­mentsIs­sue­s­Plan and track work­Code ReviewManage code changesCode QualityEnforce qual­ity at mergeAP­PLI­CA­TION SECURITYGitHub Advanced SecurityFind and fix vul­ner­a­bil­i­ti­esCode se­cu­ri­ty­Se­cure your code as you build­Se­cret pro­tec­tion­Stop leaks be­fore they star­t­EX­PLOREWhy GitHubDocumentationBlogChangelogMarketplaceView all fea­tures

AI CODE CREATIONGitHub CopilotWrite bet­ter code with AIGitHub Copilot ap­pDi­rect agents from is­sue to mergeMCP RegistryIntegrate ex­ter­nal tools

AI CODE CREATION

GitHub CopilotWrite bet­ter code with AI

GitHub CopilotWrite bet­ter code with AI

GitHub Copilot ap­pDi­rect agents from is­sue to merge

GitHub Copilot ap­pDi­rect agents from is­sue to merge

MCP RegistryIntegrate ex­ter­nal tools

MCP RegistryIntegrate ex­ter­nal tools

DEVELOPER WORKFLOWSActionsAutomate any work­flow­Code­spacesIn­stant dev en­vi­ron­mentsIs­sue­s­Plan and track work­Code ReviewManage code changesCode QualityEnforce qual­ity at merge

DEVELOPER WORKFLOWS

ActionsAutomate any work­flow

ActionsAutomate any work­flow

CodespacesInstant dev en­vi­ron­ments

CodespacesInstant dev en­vi­ron­ments

IssuesPlan and track work

IssuesPlan and track work

Code ReviewManage code changes

Code ReviewManage code changes

Code QualityEnforce qual­ity at merge

Code QualityEnforce qual­ity at merge

APPLICATION SECURITYGitHub Advanced SecurityFind and fix vul­ner­a­bil­i­ti­esCode se­cu­ri­ty­Se­cure your code as you build­Se­cret pro­tec­tion­Stop leaks be­fore they start

APPLICATION SECURITY

GitHub Advanced SecurityFind and fix vul­ner­a­bil­i­ties

GitHub Advanced SecurityFind and fix vul­ner­a­bil­i­ties

Code se­cu­ri­ty­Se­cure your code as you build

Code se­cu­ri­ty­Se­cure your code as you build

Secret pro­tec­tion­Stop leaks be­fore they start

Secret pro­tec­tion­Stop leaks be­fore they start

EXPLOREWhy GitHubDocumentationBlogChangelogMarketplace

EXPLORE

Why GitHub

Documentation

Blog

Changelog

Marketplace

View all fea­tures

BY COMPANY SIZEEnterprisesSmall and medium teamsStar­tup­sNon­prof­itsBY USE CASEApp ModernizationDevSecOpsDevOpsCI/CDView all use cas­esBY INDUSTRYHealthcareFinancial ser­vices­Man­u­fac­tur­ing­Gov­ern­mentView all in­dus­triesView all so­lu­tions

BY COMPANY SIZEEnterprisesSmall and medium teamsStar­tup­sNon­prof­its

BY COMPANY SIZE

Enterprises

Small and medium teams

Startups

Nonprofits

BY USE CASEApp ModernizationDevSecOpsDevOpsCI/CDView all use cases

BY USE CASE

App Modernization

DevSecOps

DevOps

CI/CD

View all use cases

BY INDUSTRYHealthcareFinancial ser­vices­Man­u­fac­tur­ing­Gov­ern­mentView all in­dus­tries

BY INDUSTRY

Healthcare

Financial ser­vices

Manufacturing

Government

View all in­dus­tries

View all so­lu­tions

EXPLORE BY TOPICAISoftware DevelopmentDevOpsSecurityView all top­ic­sEX­PLORE BY TYPECustomer sto­rie­sEv­ents & we­bi­na­rsE­books & re­ports­Busi­ness in­sights­GitHub SkillsSUPPORT & SERVICESDocumentationCustomer sup­port­Com­mu­nity fo­rumTrust cen­ter­Part­nersView all re­sources

EXPLORE BY TOPICAISoftware DevelopmentDevOpsSecurityView all top­ics

EXPLORE BY TOPIC

AI

Software Development

DevOps

Security

View all top­ics

EXPLORE BY TYPECustomer sto­rie­sEv­ents & we­bi­na­rsE­books & re­ports­Busi­ness in­sights­GitHub Skills

EXPLORE BY TYPE

Customer sto­ries

Events & we­bi­nars

Ebooks & re­ports

Business in­sights

GitHub Skills

SUPPORT & SERVICESDocumentationCustomer sup­port­Com­mu­nity fo­rumTrust cen­ter­Part­ners

SUPPORT & SERVICES

Documentation

Customer sup­port

Community fo­rum

Trust cen­ter

Partners

View all re­sources

COMMUNITYGitHub SponsorsFund open source de­vel­op­er­sPRO­GRAMSSe­cu­rity LabMaintainer CommunityAcceleratorGitHub StarsArchive ProgramREPOSITORIESTopicsTrendingCollections

COMMUNITYGitHub SponsorsFund open source de­vel­op­ers

COMMUNITY

GitHub SponsorsFund open source de­vel­op­ers

GitHub SponsorsFund open source de­vel­op­ers

PROGRAMSSecurity LabMaintainer CommunityAcceleratorGitHub StarsArchive Program

PROGRAMS

Security Lab

Maintainer Community

Accelerator

GitHub Stars

Archive Program

REPOSITORIESTopicsTrendingCollections

REPOSITORIES

Topics

Trending

Collections

ENTERPRISE SOLUTIONSEnterprise plat­for­mAI-pow­ered de­vel­oper plat­for­mAVAIL­ABLE ADD-ONSGitHub Advanced SecurityEnterprise-grade se­cu­rity fea­turesCopi­lot for BusinessEnterprise-grade AI fea­ture­sPremium SupportEnterprise-grade 24/7 sup­port

Decathlon did­n’t just add a new pay­ment but­ton to its German check­out page. It handed European banks their first big-box sport­ing goods test case at a mo­ment when com­pe­ti­tion in dig­i­tal pay­ments is in­ten­si­fy­ing and the push for EU-made pay­ment in­fra­struc­ture is grow­ing.

Decathlon switched on Wero on de­cathlon.de on July 20, mak­ing Germany the first mar­ket in the French group’s in­ter­na­tional foot­print to carry the European pay­ment scheme.

Wero is the re­tail pay­ment prod­uct of the European Payments Initiative (EPI), a con­sor­tium of banks and pay­ment providers backed by 18 share­holder in­sti­tu­tions and more than 50 mem­bers across the re­gion. It routes pay­ments di­rectly be­tween bank ac­counts in real time, au­tho­rized in the cus­tomer’s bank­ing app via fin­ger­print or face recog­ni­tion, so the mer­chant never re­ceives a card num­ber.

Archive re­port­ing shows the scale Wero is still build­ing to­ward: 43 mil­lion ac­tive users across the re­gion in August 2025, 46 mil­lion by November 2025 along­side the re­tail launch, and around 56 mil­lion by the time of the Decathlon roll­out in July 2026, with German reg­is­tra­tions ris­ing from 1.3 mil­lion to 1.8 mil­lion over the same pe­riod.

Decathlon joins a mer­chant ros­ter that al­ready in­cludes Eventim Live, with Lidl, Rossmann and Hornbach ex­pected to fol­low.

The in­sider why

For Decathlon, the in­cen­tive is not just op­tics. Patrick Müller, chief dig­i­tal and chief mar­ket­ing of­fi­cer at Decathlon Germany, tied the launch to the re­tail­er’s mem­ber­ship pro­gram, say­ing the con­nec­tion de­liv­ers “a gen­uine added value” on every pur­chase. That frames Wero as a loy­alty and re­ten­tion tool, not only a check­out op­tion. Industry es­ti­mates com­monly place card net­work pro­cess­ing costs at around 1 to 2 per­cent of trans­ac­tion value in fees to Visa and Mastercard. An ac­count to ac­count rail that by­passes that layer can be a di­rect mar­gin lever for a re­tailer op­er­at­ing at scale on thin sport­ing goods mar­gins.

The roll­out plan ex­tends be­yond the web­site.

Decathlon says it is prepar­ing the tech­ni­cal in­te­gra­tion needed to bring Wero to its roughly 110 phys­i­cal stores in Germany, with the goal of a con­sis­tent pay­ment ex­pe­ri­ence across on­line and of­fline chan­nels. A joint ac­ti­va­tion cam­paign with EPI is sched­uled for October: a six week pro­mo­tion of­fer­ing a €10 voucher to cus­tomers who pay with Wero on de­cathlon.de, funded en­tirely by EPI rather than Decathlon.

The chal­lenge and the promise

EPI’s will­ing­ness to fund cus­tomer in­cen­tives points to the net­work’s core prob­lem. Payment schemes live or die on how many mer­chants and con­sumers show up at the same time, and Wero still lacks in store point of sale func­tion­al­ity. That ca­pa­bil­ity is not ex­pected un­til 2026 and 2027. Joachim Schmalzl, EPI’s su­per­vi­sory board chair­man, has ac­knowl­edged the ini­tia­tive still faces real hur­dles even as he called the ecom­merce launch a mile­stone to­ward “a sov­er­eign European pay­ment sys­tem.”

Decathlon be­ing among the first to im­ple­ment the sys­tem can help test Wero’s promise: lower pro­cess­ing costs, tighter loy­alty in­te­gra­tion and one less trans­ac­tion fee flow­ing to a US based net­work, pro­vided Wero can close the gap be­tween its am­bi­tions and its still lim­ited in store reach.

from the pulling-up-the-lad­der dept

Back in December we called out Google for fil­ing a DMCA 1201 law­suit over com­pa­nies scrap­ing Google’s re­sults. Almost every­thing about the law­suit seemed prob­lem­atic, not the least of which is that Google’s en­tire busi­ness was built on scrap­ing the web. To sue an­other com­pany for scrap­ing Google just felt… ob­nox­ious. And now a judge has dis­missed the law­suit, though leav­ing it open for Google to re­file.

Some back­ground: now that we’re in the age of AI, ac­cess to all kinds of data has be­come more pre­cious, which means we’re see­ing more and more at­tempts to put a toll booth on parts of the open web, pri­mar­ily aimed at AI com­pa­nies. But the rest of us get locked out along the way. SerpAPI is one of the play­ers in the space which (as its name im­plies) ba­si­cally tries to cre­ate an unau­tho­rized API for search en­gine re­sult pages.

Last fall, Reddit sued SerpAPI and some oth­ers (including search AI com­pany Perplexity), claim­ing that be­cause SerpAPI was al­low­ing oth­ers (like Perplexity) to ac­cess Reddit con­tent via its scrape of Google, it was vi­o­lat­ing the DMCA’s anti-cir­cum­ven­tion (DMCA 1201) clause. We found the whole thing to be an at­tack on the prin­ci­ples of the open web. It re­ally seemed weird. Reddit had no copy­right in­ter­est in its users’ posts (the users hold the copy­right) and SerpAPI was scrap­ing Google, not Reddit. Reddit has an API deal with Google, but none of the par­ties be­ing sued were par­ties to that deal. The whole thing was just “we don’t like that this is hap­pen­ing, so we’re su­ing.”

Google’s case came a few months later and was quite sim­i­lar, fo­cused on SerpAPI. And while at least in this case (unlike Reddit) they could point out that SerpAPI was scrap­ing their own site, it still makes no sense to claim that scrap­ing an open web­site can be a 1201 anti-cir­cum­ven­tion vi­o­la­tion, no mat­ter what “technological pro­tec­tion mea­sures” you throw up to try to block scrap­ing. The Reddit case con­tin­ues to move for­ward with the de­fen­dants fil­ing mo­tions to dis­miss, but the Google case has lapped them a bit, with the judge al­ready dis­miss­ing the com­plaint, and point­ing out (correctly!) that Google has no le­git­i­mate copy­right claim to make here.

While SerpAPI tried a va­ri­ety of dif­fer­ent ways to kill the law­suit, what seemed to stick is that Google was clearly stretch­ing the way the DMCA 1201 is sup­posed to work. Remember, 1201 is the “anti-circumvention” part of the DMCA, and was ini­tially writ­ten to pro­tect DRM so that if peo­ple broke DRM (or even talked about how to break DRM) they could still be held li­able for copy­right in­fringe­ment just for the act of cir­cum­vent­ing the “technological pro­tec­tion mea­sure.” This very broad and poorly worded law has cre­ated huge messes in its wake, in­clud­ing bla­tant abuses like com­pa­nies ar­gu­ing that you can’t use third-party printer ink or third-party garage door open­ers be­cause of flimsy “technological pro­tec­tion mea­sures” put into those de­vices, even though the un­der­ly­ing cir­cum­ven­tion had noth­ing to do with copy­right.

The court also looks at one of those ear­lier cases (regarding Lexmark’s print­ers), but con­cludes it does­n’t ap­ply here — long story, not worth the de­tail, ex­cept to note that the prece­dent that mat­tered against Lexmark came from trade­mark law, not the DMCA, even though Lexmark had also tried (and failed) to use Section 1201 it­self.

However, SerpAPI (rightly) also pointed out that Google is over­claim­ing what “SearchGuard” — the “technological pro­tec­tion mea­sure” — ac­tu­ally pro­tects here. As the court ex­plains it, SearchGuard is ba­si­cally a kind of CAPTCHA:

SearchGuard works by send­ing a JavaScript “challenge” to search queries that Google re­ceives from un­rec­og­nized sources to con­firm that they come from real users as op­posed to au­to­mated soft­ware. Id. ¶ 29. Google’s com­puter sys­tem trans­mits JavaScript code that calls upon the user’s browser to send Google a “solve” for the chal­lenge, i.e., to send Google spe­cific in­for­ma­tion re­gard­ing the browser and user gen­er­at­ing the re­quest. Id. ¶ 29. For hu­man users, the “solve” is rel­a­tively straight­for­ward; their browsers run the JavaScript code and send back the re­quired in­for­ma­tion seam­lessly, with­out dis­rupt­ing the user ex­pe­ri­ence. Id. ¶ 29. However, au­to­mated sys­tems that sub­mit au­to­mated queries at a mas­sive scale typ­i­cally can­not solve the SearchGuard chal­lenge. Id. As a re­sult, SearchGuard de­nies them ac­cess to Google’s Search re­sults.

SearchGuard works by send­ing a JavaScript “challenge” to search queries that Google re­ceives from un­rec­og­nized sources to con­firm that they come from real users as op­posed to au­to­mated soft­ware. Id. ¶ 29. Google’s com­puter sys­tem trans­mits JavaScript code that calls upon the user’s browser to send Google a “solve” for the chal­lenge, i.e., to send Google spe­cific in­for­ma­tion re­gard­ing the browser and user gen­er­at­ing the re­quest. Id. ¶ 29. For hu­man users, the “solve” is rel­a­tively straight­for­ward; their browsers run the JavaScript code and send back the re­quired in­for­ma­tion seam­lessly, with­out dis­rupt­ing the user ex­pe­ri­ence. Id. ¶ 29. However, au­to­mated sys­tems that sub­mit au­to­mated queries at a mas­sive scale typ­i­cally can­not solve the SearchGuard chal­lenge. Id. As a re­sult, SearchGuard de­nies them ac­cess to Google’s Search re­sults.

But, as SerpAPI high­lighted, SearchGuard has lit­tle to do with copy­right. And that, at least, gets the court’s at­ten­tion:

SerpApi con­tends that Google’s claims un­der the DMCA are sub­ject to dis­missal be­cause SearchGuard is de­signed and func­tions to con­trol ac­cess to and pre­vent the scrap­ing of Google Search re­sults re­gard­less of whether they con­tain a copy­righted com­po­nent, and be­cause SearchGuard is not rea­son­ably tai­lored to con­trol ac­cess only with re­spect to any copy­righted com­po­nent that may be in­cluded in Google Search re­sults. The Court agrees with SerpApi in part. To the ex­tent that Google Search re­sults do not con­tain any copy­righted con­tent, SearchGuard can­not be said to ef­fec­tively con­trol ac­cess to a work pro­tected un­der the Copyright Act. Here, Google al­leges that SearchGuard con­trols ac­cess to Google Search re­sults, which are com­pi­la­tions of pub­licly-avail­able in­for­ma­tion that Google ob­tains from the in­ter­net and or­ga­nizes for pre­sen­ta­tion to users on google.com based on rel­e­vance. See Compl. ¶¶ 13, 14, 27. SearchGuard con­trols ac­cess to Google Search re­sults be­cause its “purpose” is “to pre­vent unau­tho­rized third par­ties from au­to­mat­i­cally ac­cess­ing Google’s Search re­sults” to scrape them, as such scrap­ing ac­tiv­i­ties im­pose a “deadweight loss” on Google. See id. ¶¶ 24, 26 – 27, 29. However, Google does not al­lege that google.com or the Google Search re­sults dis­played therein are pro­tected un­der the Copyright Act. Importantly, Google al­leges that Google Search re­sults are “often” ac­com­pa­nied by a “Knowledge Panel” that may con­tain some copy­righted con­tent that Google li­censes from third par­ties, such as copy­righted im­ages. Google does not al­lege that the “Knowledge Panel” is al­ways in­cluded in Google Search re­sults, or that the Knowledge Panel, if in­cluded in the Search re­sults, al­ways con­tains copy­righted con­tent. See id. ¶¶ 14 – 16. Accordingly, Google’s al­le­ga­tions in­di­cate a mix of con­tent, some with copy­righted ma­te­r­ial and oth­ers with­out.

SerpApi con­tends that Google’s claims un­der the DMCA are sub­ject to dis­missal be­cause SearchGuard is de­signed and func­tions to con­trol ac­cess to and pre­vent the scrap­ing of Google Search re­sults re­gard­less of whether they con­tain a copy­righted com­po­nent, and be­cause SearchGuard is not rea­son­ably tai­lored to con­trol ac­cess only with re­spect to any copy­righted com­po­nent that may be in­cluded in Google Search re­sults.

The Court agrees with SerpApi in part. To the ex­tent that Google Search re­sults do not con­tain any copy­righted con­tent, SearchGuard can­not be said to ef­fec­tively con­trol ac­cess to a work pro­tected un­der the Copyright Act. Here, Google al­leges that SearchGuard con­trols ac­cess to Google Search re­sults, which are com­pi­la­tions of pub­licly-avail­able in­for­ma­tion that Google ob­tains from the in­ter­net and or­ga­nizes for pre­sen­ta­tion to users on google.com based on rel­e­vance. See Compl. ¶¶ 13, 14, 27. SearchGuard con­trols ac­cess to Google Search re­sults be­cause its “purpose” is “to pre­vent unau­tho­rized third par­ties from au­to­mat­i­cally ac­cess­ing Google’s Search re­sults” to scrape them, as such scrap­ing ac­tiv­i­ties im­pose a “deadweight loss” on Google. See id. ¶¶ 24, 26 – 27, 29. However, Google does not al­lege that google.com or the Google Search re­sults dis­played therein are pro­tected un­der the Copyright Act. Importantly, Google al­leges that Google Search re­sults are “often” ac­com­pa­nied by a “Knowledge Panel” that may con­tain some copy­righted con­tent that Google li­censes from third par­ties, such as copy­righted im­ages. Google does not al­lege that the “Knowledge Panel” is al­ways in­cluded in Google Search re­sults, or that the Knowledge Panel, if in­cluded in the Search re­sults, al­ways con­tains copy­righted con­tent. See id. ¶¶ 14 – 16. Accordingly, Google’s al­le­ga­tions in­di­cate a mix of con­tent, some with copy­righted ma­te­r­ial and oth­ers with­out.

And that cuts against Google’s ar­gu­ment here:

Thus, be­cause the DMCA does not ap­ply where the work con­trolled by a tech­no­log­i­cal mea­sure is not pro­tected un­der the Copyright Act, Google’s claims un­der 17 U.S.C. § 1201(a)(1)(A) and 17 U.S.C. § 1201(a)(2) are sub­ject to dis­missal as a mat­ter of law to the ex­tent that they are premised on in­stances where SearchGuard con­trols ac­cess to Google Search re­sults that do not con­tain any copy­righted con­tent.

Thus, be­cause the DMCA does not ap­ply where the work con­trolled by a tech­no­log­i­cal mea­sure is not pro­tected un­der the Copyright Act, Google’s claims un­der 17 U.S.C. § 1201(a)(1)(A) and 17 U.S.C. § 1201(a)(2) are sub­ject to dis­missal as a mat­ter of law to the ex­tent that they are premised on in­stances where SearchGuard con­trols ac­cess to Google Search re­sults that do not con­tain any copy­righted con­tent.

Even more damn­ing for Google is that when it’s us­ing SearchGuard, that has lit­er­ally noth­ing to do with “effectively con­trol­ling ac­cess to a [copyright-protected] work.” And that’s the en­tire point of 1201.

SerpApi ar­gues that Google’s claims un­der the DMCA fail be­cause it does not al­lege that it im­ple­mented SearchGuard to pro­tect a copy­righted work with the “authority of the copy­right owner” as re­quired un­der 17 U.S.C. § 1201(a)(3)(B)…. The Court agrees. The plain lan­guage of 17 U.S.C. § 1201(a)(3)(B) makes clear that, for a tech­no­log­i­cal mea­sure to “effectively con­trol[] ac­cess to a work” it must, among other things, “require[] the ap­pli­ca­tion of in­for­ma­tion, or a process or a treat­ment, with the au­thor­ity of the copy­right owner, to gain ac­cess to the work.” See 17 U.S.C. § 1201(a)(3)(B). The Ninth Circuit has in­ter­preted the “with the au­thor­ity of the copy­right owner” el­e­ment as re­quir­ing a plain­tiff to al­lege and later prove that the tech­no­log­i­cal mea­sure in ques­tion was im­ple­mented and func­tioned with the au­thor­ity of the copy­right owner.

SerpApi ar­gues that Google’s claims un­der the DMCA fail be­cause it does not al­lege that it im­ple­mented SearchGuard to pro­tect a copy­righted work with the “authority of the copy­right owner” as re­quired un­der 17 U.S.C. § 1201(a)(3)(B)….

The Court agrees. The plain lan­guage of 17 U.S.C. § 1201(a)(3)(B) makes clear that, for a tech­no­log­i­cal mea­sure to “effectively con­trol[] ac­cess to a work” it must, among other things, “require[] the ap­pli­ca­tion of in­for­ma­tion, or a process or a treat­ment, with the au­thor­ity of the copy­right owner, to gain ac­cess to the work.” See 17 U.S.C. § 1201(a)(3)(B). The Ninth Circuit has in­ter­preted the “with the au­thor­ity of the copy­right owner” el­e­ment as re­quir­ing a plain­tiff to al­lege and later prove that the tech­no­log­i­cal mea­sure in ques­tion was im­ple­mented and func­tioned with the au­thor­ity of the copy­right owner.

Google tried to ar­gue that it some­how has the sup­port of copy­right hold­ers to pro­tect their work with SearchGuard, but the court is not im­pressed.

Google’s ar­gu­ments do not com­pel a dif­fer­ent con­clu­sion. It con­tends that it is not re­quired to al­lege facts in­di­cat­ing that it had the au­thor­ity of the copy­right own­ers to im­ple­ment SearchGuard be­cause the phrase “with the au­thor­ity of the copy­right owner” de­fines who may cir­cum­vent a tech­no­log­i­cal mea­sure to gain ac­cess to pro­tected work and does not de­fine who may de­ploy a tech­no­log­i­cal mea­sure to con­trol ac­cess to a pro­tected work…. This ar­gu­ment is un­avail­ing. Google’s au­thor­i­ties in­ter­pret a dif­fer­ent pro­vi­sion of the DMCA, namely 17 U.S.C. § 1201(a)(3)(A), which de­fines what it means to “circumvent a tech­no­log­i­cal mea­sure.” See Disney Enters., Inc. v. VidAngel, Inc., 869 F.3d 848, 863 (9th Cir. 2017) (“Section 1201(a)(3)(A) ex­empts from cir­cum­ven­tion li­a­bil­ity only those whom a copy­right owner au­tho­rizes to cir­cum­vent an ac­cess con­trol mea­sure, not those whom a copy­right owner au­tho­rizes to ac­cess the work.”) (citation and in­ter­nal quo­ta­tion marks omit­ted); Universal City Studios, Inc. v. Corley, 273 F.3d 429, 444 (2d Cir. 2001) (“[S]ubsection 1201(a)(3)(A) frees an in­di­vid­ual to traf­fic in en­cryp­tion tech­nol­ogy de­signed or mar­keted to cir­cum­vent an en­cryp­tion mea­sure if the owner of the ma­te­r­ial pro­tected by the en­cryp­tion mea­sure au­tho­rizes that cir­cum­ven­tion.”). These au­thor­i­ties do not ad­dress the is­sue here, which is whether a tech­no­log­i­cal mea­sure must func­tion “with the au­thor­ity of the copy­right owner” in or­der to “effectively con­trol[] ac­cess to a work” un­der 17 U.S.C. § 1201(a)(3)(B).

Google’s ar­gu­ments do not com­pel a dif­fer­ent con­clu­sion. It con­tends that it is not re­quired to al­lege facts in­di­cat­ing that it had the au­thor­ity of the copy­right own­ers to im­ple­ment SearchGuard be­cause the phrase “with the au­thor­ity of the copy­right owner” de­fines who may cir­cum­vent a tech­no­log­i­cal mea­sure to gain ac­cess to pro­tected work and does not de­fine who may de­ploy a tech­no­log­i­cal mea­sure to con­trol ac­cess to a pro­tected work…. This ar­gu­ment is un­avail­ing. Google’s au­thor­i­ties in­ter­pret a dif­fer­ent pro­vi­sion of the DMCA, namely 17 U.S.C. § 1201(a)(3)(A), which de­fines what it means to “circumvent a tech­no­log­i­cal mea­sure.” See Disney Enters., Inc. v. VidAngel, Inc., 869 F.3d 848, 863 (9th Cir. 2017) (“Section 1201(a)(3)(A) ex­empts from cir­cum­ven­tion li­a­bil­ity only those whom a copy­right owner au­tho­rizes to cir­cum­vent an ac­cess con­trol mea­sure, not those whom a copy­right owner au­tho­rizes to ac­cess the work.”) (citation and in­ter­nal quo­ta­tion marks omit­ted); Universal City Studios, Inc. v. Corley, 273 F.3d 429, 444 (2d Cir. 2001) (“[S]ubsection 1201(a)(3)(A) frees an in­di­vid­ual to traf­fic in en­cryp­tion tech­nol­ogy de­signed or mar­keted to cir­cum­vent an en­cryp­tion mea­sure if the owner of the ma­te­r­ial pro­tected by the en­cryp­tion mea­sure au­tho­rizes that cir­cum­ven­tion.”). These au­thor­i­ties do not ad­dress the is­sue here, which is whether a tech­no­log­i­cal mea­sure must func­tion “with the au­thor­ity of the copy­right owner” in or­der to “effectively con­trol[] ac­cess to a work” un­der 17 U.S.C. § 1201(a)(3)(B).

Some of SerpAPI’s other ar­gu­ments fail, but for now all the DMCA claims are dis­missed, though Google can (and al­most cer­tainly will) re­file re­gard­ing some more nar­row claims. Specifically, Google can­not file claims re­gard­ing search re­sults for which it does not hold the copy­right, but could file more nar­row claims re­gard­ing con­tent where it does (such as the Knowledge Panel). That’s much more lim­ited, and about the only rea­son to keep the case go­ing is to be a nui­sance to SerpAPI.

That might be worth it to Google, which re­ally seems to dis­like SerpAPI be­ing out there and scrap­ing their re­sults. But it would be a much nar­rower case, and (in the­ory) SerpAPI could sim­ply change its scrap­ing to avoid Google-produced con­tent. Either way, all of this re­mains quite silly. Google’s en­tire busi­ness was built on scrap­ing the web. Suing some­one else for scrap­ing Google sure feels like pulling up the open in­ter­net lad­der up af­ter them­selves.

SerpAPI’s com­ments on the dis­missal make this point ex­plic­itly:

We’re pleased that the court re­jected Google’s at­tempts to ex­pand the DMCA to as­sert con­trol over ac­cess to pub­lic pages. The in­ter­net’s found­ing prin­ci­ple — open ac­cess to us­able in­for­ma­tion — is es­sen­tial to dri­ving in­no­va­tion and en­sur­ing every­one ben­e­fits from the promise of data. SerpApi will con­tinue sup­port­ing de­vel­op­ers, AI com­pa­nies, re­searchers, and busi­nesses that rely on ac­cess to pub­lic search in­for­ma­tion.

We’re pleased that the court re­jected Google’s at­tempts to ex­pand the DMCA to as­sert con­trol over ac­cess to pub­lic pages. The in­ter­net’s found­ing prin­ci­ple — open ac­cess to us­able in­for­ma­tion — is es­sen­tial to dri­ving in­no­va­tion and en­sur­ing every­one ben­e­fits from the promise of data. SerpApi will con­tinue sup­port­ing de­vel­op­ers, AI com­pa­nies, re­searchers, and busi­nesses that rely on ac­cess to pub­lic search in­for­ma­tion.

One would hope that this ini­tial dis­missal from the court gets the com­pany to re­think this anti-open-in­ter­net strat­egy, but some­how I fear the old adage of “young com­pa­nies in­no­vate, old com­pa­nies lit­i­gate” is start­ing to seep into Google.

Filed Under: copy­right, dmca, dmca 1201, scrap­ing, search re­sults

Companies: google, red­dit, ser­papi

Many peo­ple be­gin to no­tice the ar­rival of spring with the large, beau­ti­ful blooms of the mag­no­lia flower. Magnolia trees can be found in many parts of the world, and their beau­ti­ful forms have sym­bolic, med­i­c­i­nal, and vi­sual mean­ing across cul­tures—and have for cen­turies. If you’re ever near a mag­no­lia tree, though, look closely: you’ll no­tice that bee­tles, in­stead of bees, will be mov­ing amongst the flow­ers.

So, why bee­tles over bees? The an­swer is sim­pler than you might think. Magnolias are so an­cient that they were around long be­fore bees came into ex­is­tence. They’ve been around for over 100 mil­lion years, in fact, and bee­tles have ex­isted for even longer , ap­prox­i­mately 300 mil­lion years.

Named af­ter the French botanist Pierre Magnol, mag­no­lias be­long to one of the old­est lin­eages of flow­ers on Earth. (Dinosaurs still walked the Earth at this time, to put it into per­spec­tive!) Given this an­cient set­ting, the pol­li­na­tors we’re most fa­mil­iar with, but­ter­flies and bees, had not yet evolved. Beetles were the pri­mary in­sect pol­li­na­tors for the time, and so they be­came the de facto agents for the mag­no­li­a’s sur­vival.

This part­ner­ship be­tween the flower and the bee­tle re­veals it­self in the mag­no­li­a’s look and scent. The flow­ers are large and shaped like a bowl, which is ideal for bee­tles to climb into. Their petals also boast more muted col­ors, as their part­ner pol­li­na­tors nav­i­gate bet­ter through scent than sight. Which leads to the next, and per­haps most iconic, trait of the mag­no­lia flower: its in­tox­i­cat­ing scent that at­tracts bee­tles to it, meant to mimic the smell of fer­ment­ing or ripen­ing fruit.

Another as­pect of the mag­no­lia that shows its ad­vanced evo­lu­tion is the stur­di­ness of the petals. Where many flow­ers usu­ally have rep­u­ta­tions for be­ing del­i­cate, the mag­no­lia has de­vel­oped thick, leath­ery petals. This is to with­stand the beetle’s move­ment within its cen­ter, which can be clumsy and at times, rough.

As far as pol­li­na­tors go, the bee­tle is­n’t the most so­phis­ti­cated. They can’t hover to col­lect nec­tar (or col­lect nec­tar at all) or per­form more ad­vanced pol­li­nat­ing be­hav­iors. The way they pol­li­nate is more of a happy ac­ci­dent. In their search for food, bee­tles will plow through petals of flow­ers, of­ten leav­ing a mess be­hind. But in this process, they also get coated in pollen, which they carry on to the next flower, and the one af­ter that, as they con­tinue their search.

The beetle’s method of pol­li­nat­ing, though not as so­phis­ti­cated as that of bees or but­ter­flies, has stood the test of time, at least for our dear mag­no­lias. The an­cient flow­er’s part­ner­ship with bee­tles is a tes­ta­ment to both of these agents’ an­cient ori­gins and re­silience. With sturdy petals and a rich scent, the mag­no­lia con­tin­ues to thrive to­day, just as it did mil­lions of years ago: through sim­ple, time-tested evo­lu­tion.

Magnolias, the beau­ti­ful pink and white flow­ers that bloom in early spring, have been around since di­nosaurs roamed the Earth.

They’re so old, in fact, that they rely on bee­tles in­stead of bees to pol­li­nate them.

Beetles, who have been around for even longer than mag­no­lias, pre­date bees by hun­dreds of mil­lions of years.

The arrange­ment, makeup, and scent of mag­no­lia flow­ers re­flect their unique and an­cient part­ner­ship with bee­tles.

Sources: Magnolias are so an­cient they’re pol­li­nated by bee­tles — be­cause bees did­n’t ex­ist yet; The Botany of Magnolias

Related Articles:

3-Year-Old Finds 3,800-Year-Old Scarab Amulet While on Family Hike

Dazzling Golden Tortoise Beetles Look Like Tiny Jewels Scurrying Across Leaves

Rare Sapphire Tower Plant Blooms for First and Last Time After 20 Years

Fossilized Flowers From Greenland Reveal It Was a Green Tundra Less Than 1 Million Years Ago

For help please visit help.ft.com. We apol­o­gise for any in­con­ve­nience.

The fol­low­ing in­for­ma­tion can help our sup­port team to re­solve this is­sue.

Memory prices have dou­bled, Macs and iPads have gone up, and iPhones are ex­pected to fol­low. Ed Zitron — who writes the Where’s Your Ed At newslet­ter, hosts the Better Offline pod­cast, and has been de­scribed by Politico as the AI boom’s most “acerbic gad­fly” — has spent years ar­gu­ing the build­out dri­ving those costs will never pay for it­self.

We asked him what hap­pens to Apple if he’s right.

You’ve been call­ing AI a bub­ble since be­fore it was fash­ion­able. For MacRumors read­ers who mostly know it as ChatGPT or Apple Intelligence on their iPhone, what, in plain terms, is ac­tu­ally bro­ken about the eco­nom­ics of the LLM in­dus­try?

At their very core, Large Language Models’ costs run con­trary to ba­si­cally every model of sell­ing soft­ware.

Consumers and en­ter­prises alike have been trained to pay a monthly fee for a ser­vice, and while these ser­vices might have lim­its or stric­tures, ba­si­cally no­body buy­ing soft­ware ex­pects to have a me­tered ser­vice, let alone one that’s both me­tered and with hard to mea­sure costs.

LLMs burn to­kens at a per-mil­lion rate re­gard­less of whether or not you get the re­sponse you want, or whether it does what you ask it to do. If you ask a cod­ing agent to do some sort of soft­ware task and it goes off and spins its wheels in a loop, you’re pay­ing for the to­kens re­gard­less.

AI com­pa­nies knew that con­sumers would never pay the ac­tual cost of their AI ser­vices, so they have, for the most part, sold them monthly sub­scrip­tions with vague rate lim­its that al­low them to burn way more in to­kens than the cost of their sub­scrip­tion. SemiAnalysis found that you can burn hun­dreds of dol­lars on a $20-a-month sub­scrip­tion and thou­sands of dol­lars on a $200-a-month sub­scrip­tion, and while AI boost­ers will claim that these com­pa­nies have “70% gross mar­gins on to­kens,” there is lit­tle proof that this is the case, and my own re­port­ing shows that OpenAI lost $20.9 bil­lion on $13.07 bil­lion in rev­enue in 2025.

Image credit: SemiAnalysis

This means the very ba­sic eco­nom­ics are bro­ken. If Anthropic and OpenAI be­lieved cus­tomers would ac­tu­ally pay the real cost of AI to­kens, they would­n’t have to give away 20 to 40 times the amount of to­kens to sub­scribers.

Meanwhile, back in March of this year, both moved their en­ter­prise cus­tomers over to to­ken-based billing. Within a few weeks, it came out that Uber had spent its en­tire an­nual to­ken bud­get in the space of a quar­ter, and its COO said that it was get­ting “harder to jus­tify” the cost of AI be­cause it was hard to track the cost of AI to any ac­tual use­ful fea­tures ship­ping. Sam Altman would even­tu­ally say it was a “huge is­sue” but de­clined to say how it might be fixed.

This is a prob­lem across ba­si­cally every sin­gle AI-powered startup, which has to pay the per-mil­lion to­ken rate. Perplexity, Cursor, GitHub Copilot (which moved to to­ken-based billing in June) — every sin­gle AI startup is un­prof­itable be­cause their users don’t want to pay the ac­tual cost of AI.

Another is­sue is that AI ser­vices are just not that use­ful or dif­fer­en­ti­ated. While peo­ple get some sort of ben­e­fit out of AI-generated code, these tools ac­tu­ally end up mak­ing them slower, and are fill­ing code­bases full of slop. Otherwise, an LLM is an LLM is an LLM — it can gen­er­ate, it can sum­ma­rize, it can search, and that’s about it, which means that every AI ser­vice is ef­fec­tively the same. That’s why 89% of all AI rev­enues are Anthropic and OpenAI, and why every AI startup talks in terms of “annualized rev­enue” (monthx12) — be­cause ac­tual rev­enues are very de­press­ing. Even then, most are barely at $100 mil­lion an­nu­al­ized.

Then there are the data cen­ters. An AI data cen­ter is very, very ex­pen­sive to build, takes 18 to 36 months, and costs bil­lions of dol­lars, which means ef­fec­tively any­one build­ing one will be rais­ing debt and only get paid once a cus­tomer moves in… ex­cept there aren’t re­ally any cus­tomers for AI data cen­ters out­side of Anthropic and OpenAI, both of whom are so un­prof­itable that they’ve had to raise hun­dreds of bil­lions of dol­lars even when Microsoft, Google and Amazon built all their in­fra­struc­ture.

The only rea­son every­body is­n’t freak­ing out about this is be­cause AI-related stocks have done well, even though none of the hy­per­scalers ac­tu­ally share their AI rev­enues.

You’ve ar­gued that AI’s de­mand story is es­sen­tially a mi­rage — that most of the data cen­ter ca­pac­ity is be­ing ab­sorbed by OpenAI and Anthropic them­selves, which is mask­ing the ab­sence of real en­ter­prise de­mand. If that’s right, who do you think will ac­tu­ally bear the cost when the whole thing un­rav­els?

Honestly, it’s go­ing to be a lot of pri­vate credit funds, be­cause they’re the ones fund­ing the data cen­ters, and they’re funded by pen­sion funds like the SF teach­ers fund or CalPERS, which makes me re­ally, re­ally wor­ried about the sys­temic con­ta­gion.

People will ar­gue that this means there’s go­ing to be a bailout, but this is­n’t re­ally a bailoutable thing. These data cen­ters are funded by pro­ject fi­nanc­ing, which means that the money is ba­si­cally gone and the only way to “make them whole” would be to ei­ther buy out the debt or feed them rev­enues. While you could the­o­ret­i­cally bail out these spe­cial pur­pose ve­hi­cles (SPVs), do­ing so would be to the tune of hun­dreds of bil­lions of dol­lars and be po­lit­i­cal can­cer.

I also fun­da­men­tally be­lieve that Oracle gets killed by OpenAI. Its rev­enues have been stag­nat­ing for 20 years, and the only way it’s kept its head above wa­ter is $85bn+ in ac­qui­si­tions, and even then, that’s just kept things flat. Its bets on AI data cen­ters — $340bn+ with hun­dreds of bil­lions in debt — re­quire OpenAI to be­come the largest, most-prof­itable com­pany in the world by 2030, or Oracle runs out of money. Good luck on that one Larry.

The ac­tual con­ta­gion from the col­lapse will be wide­spread. The TWSE is heav­ily re­liant on Taiwanese ODMs like Quanta and Hon Hai (Foxconn) who have seen their rev­enues boosted by sell­ing AI servers. While I don’t think it kills these com­pa­nies (especially as Hon Hai makes so much from Apple), it will cut their stock price, which will in turn cut the liveli­hoods of those in­vest­ing. The same goes for Korean in­vestors on the KOSPI, and even­tu­ally American in­vestors in the var­i­ous hy­per­scalers and semi­con­duc­tor com­pa­nies that are run­ning en­tirely be­cause of the AI bub­ble.

It all re­ally sucks.

One of OpenAI’s “Stargate” data cen­ters (image credit: OpenAI)

Hyperscalers build­ing out data cen­ters have hoovered up so much of the world’s mem­ory sup­ply that DRAM prices have roughly dou­bled this year. Tim Cook has called Apple’s re­cent price in­creases “unavoidable” — Macs and iPads are al­ready up, and iPhone mod­els are ex­pected to fol­low soon. It seems the clear­est sign yet that the bub­ble’s costs are be­ing passed onto or­di­nary con­sumers. If the build­out is as spec­u­la­tive as you say, are peo­ple ba­si­cally pay­ing more for hard­ware to sub­sidise data cen­ters that may never turn a profit?

I don’t think any of them turn a profit, no.

Hyperscalers have spent over $1 tril­lion in capex since 2022. If we as­sume that even half of that is AI data cen­ters, they need to make over $1.5 tril­lion in brand spank­ing new profit, not rev­enue, but ac­tual profit, to jus­tify any of these ex­pen­di­tures.

And yes, we are all pay­ing more for stuff for ef­fec­tively no rea­son other than that every­body in big tech has gone in­sane and wants to build as many data cen­ters as pos­si­ble. I wrote about this in the Hater’s Guide To The Memory Crisis.

The hy­per­scalers are col­lec­tively spend­ing north of $650 bil­lion on AI in­fra­struc­ture this year, whereas Apple is spend­ing about $14 bil­lion. It’s as if Cupertino is treat­ing AI as a com­mod­ity by pay­ing Google around a bil­lion a year for Gemini to run Siri and do­ing what it can on-de­vice. The com­pany was pre­vi­ously said to be dan­ger­ously be­hind on AI. That no longer seems to be the case, but at the same time, is it re­ally more savvy to be rent­ing a de­pen­dency on the very com­pa­nies you say can’t sur­vive?

So, I think Apple Intelligence was both the worst and best thing to hap­pen to Apple as far as the AI bub­ble goes.

It was a mass-rad­i­cal­iza­tion of its users against AI — an at­tempt to cram a barely-func­tional se­ries of add-ons that no­body asked for in the most-ob­tru­sive way pos­si­ble, with sum­maries that were al­most im­me­di­ately turned into memes and a new Siri that was, some­how, even worse than the old Siri.

And I think that told Apple to pump the brakes. It’s barely spent any­thing on capex. It’s barely done any­thing with AI. Despite head­line af­ter head­line claim­ing it’s “falling be­hind,” no­body can re­ally ex­plain what it is it’s falling be­hind on or why it mat­ters. People hate Apple Intelligence, and I think Apple knows that, and so they’re go­ing to jin­gle the keys for the mar­kets by putting “AI” on stuff with­out ever re­ally putting their back into it.

If the bub­ble de­flates the way you ex­pect (write-downs, too much com­pute sup­ply, pos­si­bly OpenAI cra­ter­ing), can you walk us through what that would ac­tu­ally look like for Apple? Does any­thing break for iPhone users, or does Apple mostly watch it hap­pen from the side­lines? Could it even ben­e­fit Apple?

I think things would look much the same for Apple. I think they will sit on the side­lines and watch every­thing burn. I could see them do­ing some choice ac­qui­si­tions as things be­gin to col­lapse, but I could also see them do noth­ing.

I think Apple is in a very weird place at the mo­ment. The Vision Pro was a dud, but it was also the most in­ter­est­ing and fu­ture-for­ward thing I’ve seen any­one put out in a while. If they were smart, they’d tread wa­ter and sink as much money into mak­ing that as small as hu­manely pos­si­ble — no mat­ter how long it takes — be­cause the en­tire AI bub­ble is a re­sult of every­body run­ning out of hy­per­growth ideas, mostly be­cause we’re flat out of new in­ter­faces.

I want to be clear that what they want to do with the Vision Pro re­quires it to ba­si­cally be weight­less and in­vis­i­ble and never need ad­just­ments. When it works, it’s gen­uinely awe­some. But that’s a load-bear­ing when. One slight move­ment means the whole thing goes out of fo­cus. I can’t even use mine any­more be­cause it needs an up­date that re­quires you to wear the thing the whole time. So much promise, re­leased too early, shoved out the door by a CEO on his way out.