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

🦔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

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.

Please en­able JS and dis­able any ad blocker

A Netflix ex­ec­u­tive was fired from his $1.1 mil­lion a year job af­ter re­veal­ing dur­ing a “trust ex­er­cise” at a work re­treat that he had taken med­ically pre­scribed ke­t­a­mine, a law­suit has claimed.

Kevin Baillie, who was vice pres­i­dent and head of cre­ative at Eyeline Studios, is su­ing the com­pany af­ter it launched an in­ves­ti­ga­tion into his com­ments that ul­ti­mately ended in his fir­ing, the pa­pers say.

Baillie, who’s been on the vi­sual ef­fects team for “Pirates of the Caribbean” and the Harry Potter fran­chise, says he took the drug un­der med­ical su­per­vi­sion in October and November of 2022 at a Santa Barbara clinic.

He sought the treat­ment for clin­i­cal de­pres­sion af­ter the death of his mother, ac­cord­ing to the suit.

During what’s called a “Vulnerability-Trust ex­er­cise” at a January 2026 re­treat at the ex­clu­sive Sendero Ranch, a Northern California prop­erty owned by Netflix, Baillie shared with his col­leagues that he had un­der­gone the treat­ment, the suit says.

Baillie claims he ex­plained the rea­son why he had taken the drug but was in­ves­ti­gated by Netflix. On March 18, 2026 a com­pany in­ves­ti­ga­tor brought the in­ci­dent up, “in a man­ner sug­gest­ing sus­pi­cion of recre­ational drug use,” the suit reads.

The ex­ec­u­tive was fired in April with the com­pa­ny’s at­tor­ney con­firm­ing “the ke­t­a­mine ther­apy is­sue has fac­tored into the ter­mi­na­tion,” the pa­pers say, and go on to sug­gest Baille was de­nied up to a year of sev­er­ance pay.

Baillie says in the law­suit the “scope” of the in­ves­ti­ga­tion re­lated to al­leged pro­fan­ity and drink­ing. He had been warned dur­ing his per­for­mance re­view that he should “drop one or two less f-bombs but don’t stop en­tirely.”

It goes on to say that at the same re­treat Baillie drank a Guinness stand­ing on his head, af­ter shar­ing that he had learned the trick from his for­mer fa­ther in law dur­ing a con­ver­sa­tion in­spired by the trust ses­sion.

“His col­league im­me­di­ately asked for a demon­stra­tion, rather than with­hold the open­ness that the ses­sion had en­cour­aged, he per­formed the trick,” the pa­pers say.

Sign up for the California Morning Report newslet­ter

California’s top news, sports and en­ter­tain­ment de­liv­ered to your in­box every day.

Thanks for sign­ing up!

Baille also paints a pic­ture of an al­legedly al­co­hol-fu­eled com­pany en­vi­ron­ment en­cour­aged by the Eyeline Studios CEO Jeff Shapiro.

The law­suit al­leged “alcohol con­sump­tion was com­pany-spon­sored, lead­er­ship-mod­eled and con­doned”, with mul­ti­ple ex­am­ples of how Shapiro “set the cul­tural tone con­cern­ing al­co­hol at the ex­ec­u­tive level”.

The doc­u­ments claimed Shapiro on one oc­ca­sion pur­chased beer at a cor­ner store and brought it to a com­pany car ride to the Visual Effects Society Awards for staff to share.

Baillie claims he also wit­nessed the CEO con­sume al­co­hol with Netflix and Eyeline em­ploy­ees at his own wel­come din­ner in September 2024, the Netflix Annual Business Review events in March 2025 and even a Lakers game at­tended by Netflix ex­ecs in­clud­ing Shapiro’s di­rect su­per­vi­sor in February 2026.

All up, Baillie’s at­tor­neys pro­vided over half a dozen ex­am­ples of the CEO be­ing pre­sent at a work event with a drink in his hand, ac­cord­ing to court pa­pers.

Download The California Post App, fol­low us on so­cial, and sub­scribe to our newslet­ters

California Post News: Facebook, Instagram, TikTok, X, YouTube, WhatsApp, LinkedInCalifornia Post Sports Facebook, Instagram, TikTok, YouTube, XCalifornia Post Opinion California Post Newsletters: Sign up here!Cal­i­for­nia Post App: Download here!Home de­liv­ery: Sign up here!Page Six Hollywood: Sign up here!

In ad­di­tion to host­ing mul­ti­ple par­ties, Shapiro also had a per­sonal bar in his of­fice “from which he served al­co­hol (to Baille) in­clud­ing af­ter a suc­cess­ful meet­ing with Netflix’s CEO Ted Sarandos,” ac­cord­ing to the pa­pers.

Baillie is ask­ing for a jury trial, com­pen­satory dam­ages, lost wages, dam­ages for emo­tional dis­tress, and puni­tive dam­ages.

Netflix and Eyeline were con­tacted for com­ment.

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

One miss­ing un­der­score in a Skyrim-themed user­name put an in­no­cent Nova Scotia man in prison for 18 months.

A 2018 child-lur­ing in­ves­ti­ga­tion, which be­gan in Madison, Wisconsin, and even­tu­ally ex­tended to Halifax, Canada, was based on a false premise.

Police were look­ing for a man us­ing the Kik mes­sag­ing ser­vice un­der the name “fus__ro_dah” (two un­der­scores af­ter “fus”), but they ac­ci­den­tally re­quested records for the user­name “fus_ro_dah” (one un­der­score af­ter “fus”). This one-char­ac­ter dif­fer­ence led them not to the per­pe­tra­tor but to a Canadian man named Brandon Klayme.

(Ars read­ers may rec­og­nize “fus ro dah” as the Unrelenting Force “dragon shout” from The Elder Scrolls V: Skyrim.)

Despite find­ing no ev­i­dence of the crime on his dig­i­tal de­vices, Canadian po­lice ar­rested Klayme in 2020 on child sex abuse charges. He was con­victed af­ter a trial in 2023 and sen­tenced in 2024 to 18 months in prison. He served the full term.

Even af­ter re­lease, Klayme con­tin­ued to fight his con­vic­tion. In the process of prepar­ing his ap­peal, the user­name mis­take that led to all these years of dis­rup­tion was fi­nally dis­cov­ered. On Thursday, the Nova Scotia Court of Appeal over­turned Klayme’s con­vic­tion, writ­ing: “Mr. Klayme is fac­tu­ally in­no­cent of the of­fences. He should never have been charged, let alone con­victed.”

One un­der­score

The case be­gan in 2018. From August through December of that year, a 12-year-old Wisconsin girl com­mu­ni­cated with an adult male through the Kik mes­sag­ing ser­vice. During a check of the girl’s phone, her mother found an “inappropriate” photo of the male and called lo­cal po­lice.

The Dane County Sheriff’s Department re­sponded. A deputy took the phone, and the de­part­ment ran a foren­sic search on it. The re­port iden­ti­fied 125 Kik mes­sages be­tween the girl and an adult with the user­name “fus__ro_dah” (two un­der­scores af­ter “fus”).

To iden­tify this per­son, the cops con­tacted Kik, but their sub­poena ac­ci­den­tally re­quested in­for­ma­tion about the Kik user “fus_ro_dah” (one un­der­score af­ter “fus”). Kik pro­vided Klayme’s email ad­dress in re­sponse.

Google records showed that this email ad­dress was used to ac­cess Google ser­vices from an IP ad­dress in Canada, so the Dane County in­ves­ti­ga­tors turned the case over to Halifax Regional Police. Halifax po­lice took the IP ad­dress they had been given to lo­cal Internet provider Bell Aliant. Bell con­nected the IP ad­dress to the phys­i­cal ad­dress of their sub­scriber, Brandon Klayme.

Benchmarking Opus 5 on SlopCodeBench

we got bet­ter bench­marks

I’ve writ­ten be­fore some­thing along the lines of:

THERE ARE NO GOOD BENCHMARKS for a mod­el’s abil­ity to main­tain code­base qual­ity

THERE ARE NO GOOD BENCHMARKS for a mod­el’s abil­ity to main­tain code­base qual­ity

That was­n’t en­tirely true. I love noth­ing more than bury­ing a good lede.

Last Friday I dug into SlopCodeBench, a new-ish (March 2026) long-hori­zon cod­ing bench­mark from @GOrlanski’s lab at UW Madison. It ad­dresses the thing that both­ers me most about cod­ing bench­marks - that even “larger” more com­plex bench­marks still di­vulge the whole prob­lem up front:

In con­trast, each chal­lenge in SlopCodeBench has mul­ti­ple “checkpoints” - the model does­n’t know the whole prob­lem up front, it has to evolve the code­base over time as new re­quire­ments are di­vulged.

It’s a good pa­per. It’s not that long. You should read it.

What’s cool about this bench­mark is that it is un­sat­u­rated - at the time of run­ning, the best mod­els avail­able, GPT-5.4 and Opus 4.6, got 11% and 17% strict pass rates, re­spec­tively.

bench­ing opus 5 on slop­codebench

On Friday I ran three claude mod­els (Opus 4.8, Sonnet 5, and Opus 5) through a sub­set of SlopCodeBench and watched it live for six hours. Opus 5 wins tech­ni­cally but none of them did a very good job IMO. Will post more re­sults soon with Fable and 5.6 Sol in the mix.

The big head­line is that Opus 5 got a 24% on the small sub­set of the bench­mark that I ran - not much higher than Opus 4.6′s 17% strict pass rate in the orig­i­nal pa­per. All of the tested mod­els showed a pretty sig­nif­i­cant in­crease in ver­bosity, com­plex­ity, and a bunch of other code smell met­rics over the course of each chal­lenge, with Opus 5 writ­ing five times the num­ber of func­tions/​callables than Opus 4.8 over the course of the same set of chal­lenges.

My per­sonal read of this 23% pass rate is that SlopCodeBench fi­nally gives some sig­nal for a thing I’ve only ever been able to ar­gue from vibes - that for real-shaped soft­ware en­gi­neer­ing work, build­ing one is­sue at a time, to­day’s mod­els can’t be re­lied on to run lights-off with­out steer­ing.

the bench­mark sub­set

i had claude pick out 3 prob­lems from the repo, 17 check­points to­tal, a mix of easy/​medium/​hard la­beled prob­lems:

cir­cuit_e­val — easy (8 check­points)

data­base_mi­gra­tion — medium (5 check­points)

dy­nam­ic_­con­fig_ser­vice_api — hard (4 check­points)

There’s an ap­pen­dix at the end with all 17 check­points ex­plained in de­tail but I won’t put that all here.

and then I ran them across all three mod­els, in par­al­lel, with a fresh con­text win­dow per check­point. All mod­els got the same prompts and ran in the claude code har­ness.

the met­ric I de­cided I care about is the strict pass: every­thing new is green in­clud­ing every re­gres­sion test that was in­her­ited from pre­vi­ous check­points.

A model fails a check­point if the so­lu­tion has a de­fect - de­fects are de­tected by tak­ing the mod­els out­put, a CLI to run or in some cases e.g. an api server to poke at, and run­ning a set of held-out black-box tests against the pro­duced en­try­point.

Model writes code for ck1

Eval har­ness runs black-box tests against ck1

Model writes code for ck2

Eval runs black-box tests for ck1 and ck2

etc

Again, the strict pass cri­te­ria means that if a model bun­gles some­thing in check­point 4, it can’t pass the fol­low­ing check­points be­cause that fail­ing part of the code car­ries for­ward (unless the model in­dav­er­tently fixes an eval case in check­point 6 that was bro­ken in check­point 4, but we did­n’t see this hap­pen in prac­tice).

For all 9 test runs, none of the mod­els made it to the end of any chal­lenge with every­thing pass­ing, even on the prob­lem marked as “easy” dif­fi­culty.

while it ran

son­net’s first check­point was more ex­pen­sive but by the end of prob­lem 1, son­net be­came the cheap­est of the three. (it seems like once the ba­sics were built and the work turned into main­te­nance, then the cost sav­ings started to take over)

For the first chal­lenge, last gen­er­a­tion’s mod­els ac­cu­mu­lated de­fects steadily, Opus 5 a de­fect each on check­points 4 and 5.

for the first two hours opus 5 was the only model with any strict passes at all — three in a row to start.

Things evolved as we went. Claude dili­gently up­dated the html.

Compared against the other mod­els, Opus 5 was tech­ni­cally bet­ter on prob­lem 1 (circuit_eval). But af­ter ac­ing the first three check­points, every sub­se­quent so­lu­tion had at least one de­fect (failing test case).

fi­nal re­sult

If our de­f­i­n­i­tion of suc­cess is “reached the fi­nal check­point with no de­fects” then opus 5 failed all three prob­lems, but it failed slightly-less-badly than the other mod­els.

For the costs vs de­fects re­port, I re­ally hate claude-isms but this one i de­cided to leave in:

every dol­lar bought cor­rect­ness. no­body bought enough of it.

every dol­lar bought cor­rect­ness. no­body bought enough of it.

(obviously this small sub­set of the bench can­not tell us de­fin­i­tively that spend­ing more $$ will lead to higher pass rates)

as far as strict passes go, Opus 5 got four of them (24% pass rate) (the first three ck of cir­cuit_e­val, plus data­base_mi­gra­tion ck1).

opus 4.8 and son­net 5 both got one strict pass (6% pass rate), the same data­base_mi­gra­tion ck1 that opus 5 got.

so the win­ner cleared 4/17, and 3 of those were the open­ing check­points of one prob­lem. It would ap­pear we have an un­sat­u­rated bench­mark for the next fron­tier of mod­els. nice work @GOrlanski and team.

the slop me­ter

I’m not to­tally sold on “linting the slop away” just yet, be­cause I don’t think its yet pos­si­ble to de­ter­min­is­ti­cally parse the “maintainability” of a par­tic­u­lar code­base check­point. But they are in­ter­est­ing to keep an

Code qual­ity met­rics are in­ter­est­ing to keep an eye on, and they’re prob­a­bly di­rec­tion­ally cor­rect, and

With SlopCodeBench, you get the re­sults af­ter each check­point across var­i­ous qual­ity met­rics. There are 41 of them in the re­sults file. Roughly grouped:

size — source lines, files, func­tions, meth­ods, classes, state­ments, and lines added and re­moved at that check­point

com­plex­ity — cy­clo­matic com­plex­ity mean, max, and spread, how many func­tions land in the “high” and “extreme” bands, how con­cen­trated the com­plex­ity is, max nest­ing depth, and mean func­tion length

du­pli­ca­tion — cloned lines, and clone lines as a share of source

de­com­po­si­tion — sin­gle-use func­tions, triv­ial wrap­pers, un­used vari­ables, lines per sym­bol

rule vi­o­la­tions — lint er­rors and how many are auto-fix­able, ast-grep hits against test slop rules, and the share of lines flagged ver­bose

de­pen­dency graph — prop­a­ga­tion cost (how far a change rip­ples), cyclic de­pen­dency mass, de­pen­dency en­tropy (probably the most in­ter­est­ing one to me)

Each of these is com­puted de­ter­min­is­ti­cally us­ing the cur­rent code state af­ter each check­point.

The chart be­low shows the spread among mod­els for ck1 score vs. ck8 for the cir­cuit_e­val chal­lenge. (That is, how much did the slop in­di­ca­tor in­crease over the lif­time of the chal­lenge check­points.) Most in­ter­est­ingly, most of the met­rics don’t tell the mod­els apart.

I like that these mea­sures are re­peat­able and don’t use a model for judge­ment. But the link be­tween any one of them and “is this code­base easy to change and evolve” is not yet es­tab­lished.

more cor­rect­ness came at the cost of wayyy more code

But a lot of that was “more tests” - the ac­tual pro­duc­tion vol­ume is closer to 1.8x for opus 5 vs opus 4.8.

My guess would be…ex­pen­sive ver­bosity here that did­n’t trans­late di­rectly to much bet­ter re­sults.

Will have to dig in more to know whether this is a model tic sig­nal or just a “this is ac­tu­ally a re­ally hard prob­lem and war­rants this much code”.

al­most all the code writ­ten trig­gered the slop me­ter

For all mod­els, a huge ma­jor­ity of the code lines tripped at least one of the the bench­mark’s slop rules. The av­er­ages across the three prob­lems:

opus 4.8 — 98%

opus 5 — 93%

son­net 5 — 89%

And specif­i­cally, lines flagged as be­ing too ver­bose go up across the tra­jec­tory for every model, roughly 65% at ck1 to 80% by ck8, even for Opus 5.

I’d ac­tu­ally prob­a­bly say this is a sign that some of the code qual­ity mea­sures are a bit over-ag­gres­sive. I looked into ap­ply­ing the rule­set to our type­script monorepo, but the cur­rent slop-code-bench de­tec­tors are python only.

So I had 5.6-Sol cook up a sub­set of rules for type­script, but it only came up with 76 slop de­tec­tors (compared to the SCB python li­brary of 200+) - but found some di­rec­tional find­ings - the Opus 5 lights-off-gen­er­ated so­lu­tions have over 11 times more slop trig­gers per kLOC than our 99%-AI-generated-but-also-carefully-reviewed Typescript monorepo (yes that’s a 1000% in­crease).

Obviously there’s a moun­tain of as­ter­isks on this find­ing (fewer rules, haven’t re­viewed the par­ity, etc.) but it’s in­ter­est­ing to say the least.

these mod­els write a lot of func­tions

Another in­ter­est­ing data point - opus 5 wrote 5x more func­tions than the other two mod­els. But Opus 4.8 wrote a higher %% of sin­gle-use func­tions (almost 50% of its func­tions were called ex­actly once). And Sonnet 5′s share of sin­gle-use func­tions is the high­est at 71.5%.

FWIW I don’t think lots of small func­tions is bad. I take it with a grain of salt these days, but I used to be a die-hard Clean Code guy. Small de­scrip­tive func­tion names are way bet­ter than lots of com­ments, yada yada

Complexity grows over time for all mod­els

I’ve been say­ing mod­els de­grade code­base qual­ity over time for about a year now, mostly on vibes. But now we have some data.

Not a sin­gle model made it through all the chal­lenges with­out in­creas­ing com­plex­ity across check­points. While Opus 5 has the low­est mean com­plex­ity, it also wrote 2000 func­tions. There’s a trade­off here: lots of small func­tions or fewer big ones. I don’t think any of these com­plex­ity met­rics can stand alone, but they give us some kind of com­pos­ite sig­nal.

Both son­net and Opus 4.8 an­swered the in­creas­ing com­plex­ity of the chal­lenge check­points by mak­ing in­di­vid­ual func­tions big­ger rather than mov­ing things around. Opus 4.8 is the ex­treme, up 70% over eight check­points, and its sin­gle worst func­tion ended at a cy­clo­matic com­plex­ity of 93.

Duplication is where they split. Opus 4.8 goes from 4.6% to 16.8%, with an in­flec­tion at ck3 — ~roughly where new re­quire­ments start fight­ing the ini­tial de­sign.

Aside - here’s what the first three check­points of cir­cuit_e­val ask for (full list­ing for all chal­lenges in the ap­pen­dix at the end):

ck1 — a CLI with –help, –version, a JSON out­put mode, and a check com­mand that parses and val­i­dates a .circ cir­cuit file. Every sig­nal is a sin­gle bit.

ck2 — an eval com­mand: pass the cir­cuit some in­puts, get the out­puts back. Still one bit per sig­nal, stan­dard boolean op­er­a­tors.

ck3 — sig­nals be­come vec­tors. data[7:0] in­stead of data, plus slic­ing, in­dex­ing, con­cate­na­tion, new op­er­a­tors, and a width check on every operand.

By the end one line in six is a copy of an­other line. The other two mod­els came down over the same stretch.

However, opus 5 is ba­si­cally flat, 2.41 to 2.64. I’ve pre­vi­ously ar­gued that “improving code­base qual­ity over time” had not moved much be­tween model gen­er­a­tions. So if you trust du­pli­ca­tion as a golden met­ric, you could ar­gue that we did get­ting in­cre­men­tally bet­ter in the last ~3 months. Big if though, and I think most soft­ware ar­chi­tec­ture ex­perts would agree that it’s not black and white.

the shape of a bet­ter or­a­cle for soft­ware qual­ity

While the code qual­ity met­rics are in­ter­est­ing, I don’t think they tell the whole story, and its easy for a model to re­ward hack any of them. Just like SWE-bench shaped prob­lems were the best ver­i­fier for “solve a soft­ware prob­lem one time”, be­cause they map onto real world work at that “zoom level”, I think “pass all ver­i­fiers for an in­cre­men­tally-di­vulged spec” is a very re­al­is­tic eval for “can a model main­tain a code­base over time”.

That is, a code­base be­com­ing hard to main­tain would lead to fail­ing check­points in later stages, so a higher strict pass rate is a sig­nal that the model is good at build­ing a code­base that is main­tain­able.

With fron­tier mod­els like Fable / Sol prov­ing to be ex­pert de­bug­gers and re­verse-en­gi­neers, in­cor­po­rat­ing cost/​time/​to­ken met­rics might be­come more im­por­tant over time - fron­tier mod­els like Fable and Sol can prob­a­bly get it done in the NASTIEST of code­bases, but I’d ven­ture that a well-fac­tored code­base will tend to lead to shorter, more to­ken-ef­f­i­cent solves for fu­ture prob­lems.

And while “build a whole fea­ture across 8 check­points” is a lot slower than “solve a 15min SWE-bench mul­ti­lin­gual prob­lem”, it can be ex­e­cuted un­at­tended and is sub­ject de­ter­min­is­tic be­hav­ior ver­i­fiers at the end. So IMO its a much bet­ter or­a­cle than e.g. “does an­other model think this code is clean”.

I think any even bet­ter sig­nal that we can hope to get from a model that is re­ally good at main­tain­ing a code­base, is that we could try hav­ing a fron­tier model like opus 5, fa­ble 5, or gpt-5.6-sol write the first N check­points, and see if a dumber model like son­net 5 or gpt-5.6-terra can im­ple­ment check­point N+1.

This am­pli­fies the sig­nal of whether the smart mod­els did a good job main­tain­ing high-qual­ity code that is easy to change. Whether a small model like Sonnet or Terra or even Haiku can im­ple­ment check­point 8 im­pacts the smart mod­els’ score on check­points 1 – 7.

some­thing you can ac­tu­ally mea­sure

My per­sonal read of all this is that SlopCodeBench gives a sig­nal for some­thing I’ve so far only been able to ar­gue from ex­pe­ri­ence - that for real-shaped soft­ware en­gi­neer­ing work, build­ing one is­sue at a time, to­day’s mod­els can’t be re­lied on to run lights-off with­out steer­ing.

SCB is a mea­sure of the fu­ture that I’ll be keep­ing a close eye on. I would­n’t bet my code­base on a good score in Frontier Code, SWE-Marathon, or DeepSWE, but if/​when mod­els can score 80%+ on a (well-held-out) bench­mark like SlopCodeBench which mea­sures it­er­a­tion over time, I’ll feel a LOT bet­ter about set­ting them loose with the lights off.

I won’t posit when that will hap­pen, be­cause “when” mat­ters less than hav­ing a good sig­nal to know that it’s hap­pen­ing. (Assuming no­body “accidentally” trains on test in the mean­time).

what’s next / things i’d do dif­fer­ently

I’ll be read­ing some of the slop­codebench prob­lems more deeply for in­spi­ra­tion and to cu­rate a few that I think map well to the day-to-day build­ing we do here at @humanlayer_dev.

Claude de­cided to par­al­lelize by model, run­ning each through three chal­lenges in se­quence. We could have just as eas­ily done 3 mod­els x 3 chal­lenges in 9 par­al­lel ses­sions and fin­ished in 1 – 2 hours in­stead of 6.

As I said, I looked into ap­ply­ing the rule­set to our type­script monorepo, but the cur­rent slop-code-bench de­tec­tors are python only. It would be in­ter­est­ing to port those to TS and a few other lan­guages. I hate to be that guy but I’d bet python is a more slop-prone lan­guage than most.