I was in­spect­ing Claude Code for pri­vacy rea­sons.

Most devs give their har­nesses ridicu­lous ac­cess. FS, shell, git, browser ac­cess, even com­puter use nowa­days. That is the whole point. They need enough con­text to do use­ful work.

That also means the client it­self de­serves scrutiny. If a cod­ing agent can read your repo and run com­mands, the bi­nary that ships it should be bor­ing (ƒor ex­am­ple, pi har­ness)

So I took a look at my lo­cal Claude Code (2.1.196) in­stall.

Inside the Claude Code bi­nary, there is a func­tion that changes the cur­rent date string in­serted into the sys­tem prompt.

The nor­mal string looks like this:

Claude Code can silently change two things:

The apos­tro­phe in Today’s

The date sep­a­ra­tor, from - to /

Here is the rel­e­vant code, cleaned up from the mini­fied bun­dle:

This is prompt steganog­ra­phy, a tech­nique used to hide data in plain sight.

The vis­i­ble sen­tence still reads like a nor­mal date. The model and the user see some­thing bor­ing. The raw re­quest con­tains a marker.

The trig­ger is ANTHROPIC_BASE_URL, Claude Code’s API base URL over­ride.

Then it checks if:

the sys­tem time­zone is Asia/Shanghai or Asia/Urumqi

the API base URL host­name matches a de­coded do­main list

the host­name con­tains spe­cific AI lab key­words

The time­zone check changes:

into:

The host­name check changes the apos­tro­phe:

These are vi­su­ally tiny changes you would never no­tice in most mono fonts.

The do­main and key­word lists are stored as base64 strings and XOR-decoded with key 91.

The de­coded lab key­word list is:

The de­coded do­main list is much larger. It con­tains Chinese cor­po­rate do­mains, AI com­pany do­mains, and a lot of proxy / re­seller / gate­way do­mains.

Some ex­am­ples:

The date func­tion is used when build­ing the agent con­text:

So the marker be­comes part of the sys­tem con­text sent to the model. (Where Anthropic prob­a­bly parses in their back­end)

My in­stalled bi­nary is signed by Anthropic:

My cur­rent shell had ANTHROPIC_BASE_URL un­set, and my time­zone was:

So on my ma­chine, un­der my cur­rent en­vi­ron­ment, this path would pro­duce the nor­mal apos­tro­phe and the nor­mal YYYY-MM-DD date string.

Anthropic prob­a­bly wants to de­tect API re­sellers, unau­tho­rized Claude Code gate­ways, and model “distillation at­tack” pipelines. A cus­tom ANTHROPIC_BASE_URL point­ing at a known re­seller do­main is a use­ful sig­nal. A host­name con­tain­ing deepseek or zhipu is also a use­ful sig­nal.

That part makes sense, but the im­ple­men­ta­tion is weird.

CC silently al­ters the sys­tem prompt us­ing in­vis­i­ble-ish Unicode mark­ers. It en­codes proxy / gate­way clas­si­fi­ca­tion into a sen­tence that looks like plain English. It hides the do­main list be­hind XOR and base64. This is not a ma­li­cious fea­ture, but it is a weird choice for a de­vel­oper tool that asks for trust.

Coding agents al­ready live on the wrong side of a scary bound­ary. They can in­spect code, sum­ma­rize se­crets by ac­ci­dent, run com­mands, in­stall pack­ages, edit files, and push com­mits on your lo­cal ma­chine. Most de­vel­op­ers ac­cept that be­cause the pro­duc­tiv­ity gain is worth the risk.

Trust from real de­vel­op­ers de­pends on the bor­ing be­hav­ior.

If the client wants to de­tect cus­tom API gate­ways, it can say so plainly. It can send an ex­plicit teleme­try field with doc­u­men­ta­tion. It can make the pol­icy vis­i­ble. It can put the be­hav­ior in re­lease notes.

Hiding the sig­nal in the sys­tem prompt makes every other pri­vacy claim harder to be­lieve.

For most users, this path prob­a­bly stays in­ac­tive.

If you are us­ing the of­fi­cial Anthropic API end­point, Crt() re­turns early. If ANTHROPIC_BASE_URL is un­set, Crt() re­turns early. If you are us­ing a nor­mal setup, the date prompt stays “boring”.

The in­ter­est­ing case is peo­ple rout­ing CC through a cus­tom base URL. That in­cludes:

Internal gate­ways

Local prox­ies

Model routers

Resellers

Research se­tups

In that case, Claude Code clas­si­fies the host­name and en­codes the re­sult into the prompt.

The by­pass is also triv­ial. Change host­name, change time­zone, patch the bi­nary, wrap the process. Any se­ri­ous ad­ver­sary can make this sig­nal use­less.

So the fea­ture mostly pun­ishes the ex­act peo­ple who are eas­ier to fin­ger­print: nor­mal de­vel­op­ers do­ing weird but le­git­i­mate things.

I think this could have been ex­plicit.

Developer tools can en­force terms. API providers can de­tect abuse. Companies can pro­tect their mod­els.

When a tool with filesys­tem and shell ac­cess starts hid­ing clas­si­fi­ca­tion bits in­side in­vis­i­ble prompt punc­tu­a­tion, the cor­rect re­ac­tion is scrutiny.

Trust is earned in the bor­ing parts.

Claude Sonnet 5 is built to be the most agen­tic Sonnet model yet. It can make plans, use tools like browsers and ter­mi­nals, and run au­tonomously at a level that, just a few months ago, re­quired larger and more ex­pen­sive mod­els.

For many de­vel­op­ers, the agen­tic AI era be­gan with Sonnet-class mod­els: Claude Sonnet 3.5, 3.6, and 3.7 were the first mod­els that showed im­pres­sive skills in cod­ing and tool use. More re­cently, though, the clear­est gains in agen­tic ca­pa­bil­i­ties have been in our Opus-class mod­els.

Sonnet 5 nar­rows the gap: its per­for­mance is close to that of Opus 4.8, but at lower prices. It’s a sub­stan­tial im­prove­ment over its pre­de­ces­sor, Sonnet 4.6, on im­por­tant as­pects of agen­tic per­for­mance like rea­son­ing, tool use, cod­ing, and knowl­edge work:

Our safety as­sess­ments found that Sonnet 5 shows an over­all lower rate of un­de­sir­able be­hav­iors than Sonnet 4.6, and is gen­er­ally safer to use in agen­tic con­texts. Evaluations also show that it has a much lower abil­ity to per­form cy­ber­se­cu­rity tasks than our cur­rent Opus mod­els.

From to­day, Claude Sonnet 5 is avail­able across all plans: it is the de­fault model for Free and Pro plans, and is avail­able to Max, Team, and Enterprise users. It’s also avail­able in Claude Code and on the Claude Platform, where it launches with in­tro­duc­tory pric­ing of $2 per mil­lion in­put to­kens and $10 per mil­lion out­put to­kens through August 31, 2026, af­ter which it will be priced at $3 per mil­lion in­put to­kens and $15 per mil­lion out­put to­kens. Developers can use claude-son­net-5 via the Claude API.

Working with Claude Sonnet 5

The charts be­low com­pare the per­for­mance of Sonnet 5 with Sonnet 4.6 and Opus 4.8 at dif­fer­ent ef­fort lev­els on the agen­tic search eval­u­a­tion BrowseComp and the com­puter use eval­u­a­tion OSWorld-Verified. Sonnet 5 (orange line) is a strict im­prove­ment over Sonnet 4.6 (gray line) and cov­ers a much wider range of cost-per­for­mance op­tions than Opus 4.8 (yellow line). It pro­vides sub­stan­tially im­proved cost ef­fi­ciency at medium ef­fort; its higher-ef­fort per­for­mance can match Opus 4.8 on some tasks. Between Sonnet 5 and Opus 4.8, users can ad­just the ef­fort level to find the right bal­ance of cost and per­for­mance.

Feedback from our early ac­cess part­ners has been con­sis­tent: Sonnet 5 is much more agen­tic than its pre­de­ces­sors. Testers de­scribed how it fin­ishes com­plex tasks where pre­vi­ous Sonnet mod­els would stop short, how it checks its own out­put with­out ex­plic­itly be­ing asked, and how it does all this agen­tic work at an at­trac­tive price point:

Claude Sonnet 5 gives our agents a strong ex­e­cu­tion layer for multi-step soft­ware en­gi­neer­ing work. It han­dles sus­tained cod­ing, tool use, and de­bug­ging well across messy tech­ni­cal con­texts, and has been es­pe­cially use­ful for work­flows where fol­low-through and tech­ni­cal ground­ing mat­ter.

Claude Sonnet 5 gives our agents a strong ex­e­cu­tion layer for multi-step soft­ware en­gi­neer­ing work. It han­dles sus­tained cod­ing, tool use, and de­bug­ging well across messy tech­ni­cal con­texts, and has been es­pe­cially use­ful for work­flows where fol­low-through and tech­ni­cal ground­ing mat­ter.

We handed Claude Sonnet 5 a two-part job—up­date Salesforce ac­count tiers, send a launch an­nounce­ment to en­ter­prise con­tacts—and it fin­ished end to end. That used to stall halfway. For day-to-day au­toma­tion, it’s a no-brainer.

We handed Claude Sonnet 5 a two-part job—up­date Salesforce ac­count tiers, send a launch an­nounce­ment to en­ter­prise con­tacts—and it fin­ished end to end. That used to stall halfway. For day-to-day au­toma­tion, it’s a no-brainer.

Claude Sonnet 5 gets more done with less. Same out­put qual­ity, fewer steps to get there. It re­fuses un­safe re­quests cleanly and con­sis­tently, too. At Lovable, we’re putting pow­er­ful tools in the hands of mil­lions of builders. A model that knows when to say no is just as im­por­tant as one that knows how to build.

Claude Sonnet 5 gets more done with less. Same out­put qual­ity, fewer steps to get there. It re­fuses un­safe re­quests cleanly and con­sis­tently, too. At Lovable, we’re putting pow­er­ful tools in the hands of mil­lions of builders. A model that knows when to say no is just as im­por­tant as one that knows how to build.

We ran Claude Sonnet 5 against dozens of our most chal­leng­ing real pull re­quests, and it car­ried each one through to a tested, ver­i­fied re­sult on its own — free­ing our en­gi­neers to fo­cus on the judg­ment, the de­ci­sion, and the fi­nal sign-off.

We ran Claude Sonnet 5 against dozens of our most chal­leng­ing real pull re­quests, and it car­ried each one through to a tested, ver­i­fied re­sult on its own — free­ing our en­gi­neers to fo­cus on the judg­ment, the de­ci­sion, and the fi­nal sign-off.

I asked Claude Sonnet 5 to in­ves­ti­gate a bug. Unprompted, it wrote a re­pro­duc­ing test, im­ple­mented the fix, then stashed it to con­firm the bug came back with­out the change. All in a sin­gle pass.

I asked Claude Sonnet 5 to in­ves­ti­gate a bug. Unprompted, it wrote a re­pro­duc­ing test, im­ple­mented the fix, then stashed it to con­firm the bug came back with­out the change. All in a sin­gle pass.

With Claude Sonnet 5, agents stay on plan, fol­low our con­ven­tions, and ship clean multi-step changes, all at an ef­fi­cient cost.

With Claude Sonnet 5, agents stay on plan, fol­low our con­ven­tions, and ship clean multi-step changes, all at an ef­fi­cient cost.

Claude Sonnet 5 is at its best on brown­field code—race con­di­tions, hid­den tests, the parts no­body wants to touch. It traces a fail­ure to its ac­tual root cause and ships a durable fix in­stead of patch­ing the symp­tom.

Claude Sonnet 5 is at its best on brown­field code—race con­di­tions, hid­den tests, the parts no­body wants to touch. It traces a fail­ure to its ac­tual root cause and ships a durable fix in­stead of patch­ing the symp­tom.

Claude Sonnet 5 sits on the Pareto fron­tier for Eve’s plain­tiff-law tasks. We see the clear­est gains in le­gal re­search and analy­sis, at a price-to-per­for­mance ra­tio that made the choice to mi­grate easy.

Claude Sonnet 5 sits on the Pareto fron­tier for Eve’s plain­tiff-law tasks. We see the clear­est gains in le­gal re­search and analy­sis, at a price-to-per­for­mance ra­tio that made the choice to mi­grate easy.

ClickHouse agents ex­plore live data and pro­duce in­sights on the fly, so time-to-in­sight mat­ters when test­ing new mod­els. Claude Sonnet 5 rea­sons in tighter steps and gets our users to an­swers no­tice­ably faster. That speed is a dif­fer­ence our cus­tomers feel.

ClickHouse agents ex­plore live data and pro­duce in­sights on the fly, so time-to-in­sight mat­ters when test­ing new mod­els. Claude Sonnet 5 rea­sons in tighter steps and gets our users to an­swers no­tice­ably faster. That speed is a dif­fer­ence our cus­tomers feel.

At Pace, our com­puter-use agents run in­sur­ance work­flows—sub­mis­sion in­take, FNOL, loss runs—on the sys­tems our op­er­a­tions teams al­ready use. Claude Sonnet 5 con­sis­tently takes the right ac­tion and does it quickly, which is what real in­sur­ance work de­mands.

At Pace, our com­puter-use agents run in­sur­ance work­flows—sub­mis­sion in­take, FNOL, loss runs—on the sys­tems our op­er­a­tions teams al­ready use. Claude Sonnet 5 con­sis­tently takes the right ac­tion and does it quickly, which is what real in­sur­ance work de­mands.

01 /

10

Safety eval­u­a­tions

Our pre-de­ploy­ment safety eval­u­a­tions found that Sonnet 5 was over­all an im­prove­ment on Sonnet 4.6. On agen­tic safety, the model is bet­ter at re­fus­ing ma­li­cious re­quests and re­sist­ing hi­jack at­tempts in prompt in­jec­tion at­tacks. The model shows lower rates of hal­lu­ci­na­tion and syco­phancy than Sonnet 4.6. On our au­to­mated be­hav­ioral au­dit, which tests a wide range of mis­aligned be­hav­iors such as co­op­er­a­tion with mis­use and de­cep­tion, Sonnet 5 scored lower (that is, safer) over­all. However, it did show some­what higher rates of mis­aligned be­hav­ior on this as­sess­ment com­pared to the more ca­pa­ble Opus 4.8 and Claude Mythos Preview.

We did not de­lib­er­ately train Sonnet 5 on cy­ber­se­cu­rity tasks. It can per­form some rou­tine, non-harm­ful cy­ber tasks, but on eval­u­a­tions test­ing po­ten­tially dan­ger­ous cy­ber skills, such as de­vel­op­ing soft­ware ex­ploits, it shows sub­stan­tially poorer per­for­mance than mod­els such as Opus 4.8 and Mythos 5. Scores from one eval­u­a­tion, which tested mod­els’ abil­ity to de­velop ex­ploits for vul­ner­a­bil­i­ties in the Firefox browser, are shown in the chart be­low. Sonnet 5 was never able to de­velop a full work­ing ex­ploit, but it does show a slightly higher rate of par­tial suc­cess than Sonnet 4.6. This lat­ter change is likely due to im­prove­ments in gen­eral in­tel­li­gence rather than spe­cific train­ing.

Since Sonnet 5 is some­what stronger than its pre­de­ces­sor on these tasks, we’ve launched it with cy­ber safe­guards en­abled by de­fault. These safe­guards—which de­tect and block dan­ger­ous cy­ber us­age in real time—are the same as those pre­sent in Claude Opus 4.7 and 4.8 (because we judged that the over­all level of cy­ber­se­cu­rity risk from Sonnet 5 was low, the safe­guards are less strict than those launched with Fable 5, which block a much wider range of cy­ber­se­cu­rity tasks).1

Our full as­sess­ment of Sonnet 5 across many safety and ca­pa­bil­ity eval­u­a­tions is re­ported in the Claude Sonnet 5 System Card.

Availability and pric­ing

Claude Sonnet 5 is avail­able every­where to­day at an in­tro­duc­tory price of $2 per mil­lion in­put to­kens and $10 per mil­lion out­put to­kens through August 31, 2026. It then moves to stan­dard pric­ing at $3 per mil­lion in­put to­kens and $15 per mil­lion out­put to­kens.2 We’ve in­creased rate lim­its across Chat, Cowork, Claude Code, and the Claude Platform3 to ac­com­mo­date the higher to­ken us­age of higher ef­fort lev­els; users can se­lect whichever level makes sense for their par­tic­u­lar pro­ject.

Changelog

Edit June 30, 2026: In the orig­i­nal ver­sion of this post, we in­cluded a cost-per­for­mance chart for the BrowseComp eval­u­a­tion that was based on data from a sim­pler method­ol­ogy that did not re­flect the stan­dard method­ol­ogy we use for agen­tic search eval­u­a­tions. This had the re­sult of un­der­es­ti­mat­ing Sonnet 5′s per­for­mance on the eval­u­a­tion.

We have now up­dated the chart so that it matches the method­ol­ogy that we used and dis­cussed in the Sonnet 5 sys­tem card (which used a 10M to­ken bud­get with com­paction and pro­gram­matic tool call­ing). We have also up­dated the sur­round­ing text.

Footnotes

1 Sonnet 5 is part of our Cyber Verification Program, which is avail­able to­day on the na­tive Claude Platform, the Claude Platform on AWS, and Claude in Microsoft Foundry (hosted on Azure and Anthropic), and com­ing soon on Claude in Google Vertex. Organizations that are al­ready en­rolled in the Cyber Verification Program au­to­mat­i­cally have the same ac­cess on Sonnet 5, with no need to reap­ply. Overall, we rec­om­mend Claude Opus 4.8 for cy­ber­se­cu­rity work that re­quires re­duced guardrails.

2 Sonnet 5 is an up­grade to Sonnet 4.6, but it uses an up­dated to­k­enizer that changes how the model processes text to im­prove per­for­mance (this is sim­i­lar to the to­k­enizer change we in­tro­duced with Claude Opus 4.7). The trade­off is that the same in­put can map to more to­kens: roughly 1.0 – 1.35× de­pend­ing on the con­tent type. The in­tro­duc­tory pric­ing is set so that the tran­si­tion to Sonnet 5 is roughly cost-neu­tral.

3 On April 26, 2026, we raised Sonnet and Haiku rate lim­its at every us­age tier and sim­pli­fied to three tiers (Start, Build, and Scale) on the na­tive Claude Platform. You can view your tier and cur­rent lim­its in the Claude Console or read the doc­u­men­ta­tion to learn more.

Humanity’s Last Exam: We up­dated the grader model for Humanity’s Last Exam and have up­dated the Sonnet 4.6 score to 34.6% (no tools) and 46.8% (with tools). This is the rea­son the score dif­fers from that re­ported in the Sonnet 4.6 launch blog.

OSWorld-Verified: We made changes to how we run the OSWorld-Verified eval­u­a­tion to more ac­cu­rately re­flect the mod­el’s per­for­mance in the real world, and have up­dated the Sonnet 4.6 score to 78.5%. This is the rea­son the score dif­fers from that re­ported in the Sonnet 4.6 launch blog.

Related con­tent

Claude Science, an AI work­bench for sci­en­tists, is now avail­able

Claude Science is a cus­tomiz­able app that in­te­grates the tools and pack­ages re­searchers most of­ten use, pro­duces au­ditable ar­ti­facts, and pro­vides flex­i­ble ac­cess to com­put­ing re­sources.

Read more

Introducing Claude Tag

Claude Tag is a new way for teams to work with Claude.

Read more

Anthropic opens Seoul of­fice and an­nounces new part­ner­ships across the Korean AI ecosys­tem

Read more

European gov­ern­ments are rolling out dig­i­tal iden­tity wal­lets, which are to be used by cit­i­zens to ac­cess ser­vices, and to ver­ify their age on­line. As re­ported by Follow the Money and Android Authority, there is a se­ri­ous prob­lem with this: these wal­lets rely on safety ser­vices of Google and Apple. These are known as Google Play Integrity API, and Apple’s Managed Device Attestation1. Such safety ser­vices (known as “remote at­tes­ta­tion”) are used to en­sure that wal­let apps run on hard­ware that is not tam­pered with. In this ar­ti­cle we ex­plain why the EU-wallet case is part of a big­ger prob­lem: by em­bed­ding these safety ser­vices in pub­lic in­fra­struc­ture, Europe risks mak­ing so­ci­ety de­pen­dent on pri­vate com­pa­nies while serv­ing their cor­po­rate in­ter­ests.

Here is the prob­lem:

Google’s Play Integrity API is not just a se­cu­rity fea­ture: it is re­in­forc­ing Google’s con­trol over the Android ecosys­tem.

Google’s Play Integrity API is an in­struc­tive case for how big tech plat­form com­pa­nies ac­crue power. The API is a free piece of soft­ware that Google gifts to de­vel­op­ers to help with their app de­vel­op­ment. It al­lows de­vel­op­ers to check whether an app is run­ning on a “genuine cer­ti­fied Android de­vice” to test the in­tegrity of a mo­bile de­vice. This can help de­vel­op­ers re­duce abuse by bots, fraud in bank­ing apps, or cheat­ing in game apps.

But in do­ing so, it also checks whether a de­vice is run­ning a Google-licensed ver­sion of Android and treats un­li­censed al­ter­na­tives as a po­ten­tial se­cu­rity risk. When Google ver­i­fies whether an app has been tam­pered with, it uses the Google Play Store as the source of truth, check­ing both whether the app has been mod­i­fied and whether it was in­stalled through the Play Store. As a re­sult, Google’s safety ser­vice is de­signed to ex­clude op­er­at­ing sys­tems that are not li­censed by Google, en­cour­age in­stal­la­tion through the Google Play Store, and re­quire users to sign in with a Google ac­count. This is a clear vi­o­la­tion of the Digital Market Act (DMA).

We do have a choice. A more open al­ter­na­tive to Google Play Integrity ex­ists but is be­ing ig­nored: Android’s Hardware Attestation API. It pro­vides hard­ware-based se­cu­rity checks but with­out en­forc­ing Google’s ecosys­tem pol­icy.

Governments are ce­ment­ing a mo­nop­oly they claim to op­pose

The EU of­ten states that it wants to break the big tech mo­nop­oly. Yet, European mem­ber states risk re­in­forc­ing Google’s ecosys­tem when they em­bed the Google Play Integrity API into their dig­i­tal ID wal­let ar­chi­tec­ture. For ex­am­ple, wal­let de­vel­op­ers in the Netherlands and Italy have im­ple­mented Play Integrity. As a re­sult, users of de-Googled op­er­at­ing sys­tems such as e/​OS and GrapheneOS can be ex­cluded from ac­cess­ing these ser­vices.

In this way, gov­ern­ments ef­fec­tively be­come en­forcers of a pri­vate com­pa­ny’s plat­form poli­cies. This stands in ten­sion with Europe’s am­bi­tion to build dig­i­tal pub­lic in­fra­struc­ture based on pub­lic val­ues such as open­ness, in­clu­sive­ness, and tech­no­log­i­cal sov­er­eignty. It also stands in ten­sion with the reg­u­la­tion un­der­pin­ning the EU’s iden­tity wal­let, which iden­ti­fies in­ter­op­er­abil­ity as a key ob­jec­tive. Users who want the au­ton­omy to use op­er­at­ing sys­tems with­out pre-in­stalled Google soft­ware, Google track­ers, and built-in LLMs, are forced to use Google soft­ware, if they want to use the wal­let. And here, they will not have a choice.

ID wal­lets are pub­lic in­fra­struc­ture to ac­cess crit­i­cal pub­lic ser­vices. They should re­main in­ter­op­er­a­ble across dif­fer­ent de­vices and op­er­at­ing sys­tems, free from ven­dor lock-in.

ID wal­lets are not just any kind of soft­ware — they are key means to ac­cess gov­ern­ment doc­u­ments and man­age lo­gins to pub­lic ser­vices. Therefore, they are of­ten seen as cru­cial build­ing blocks of dig­i­tal pub­lic in­fra­struc­ture. They are a cru­cial ser­vice that has to be avail­able to any­one - in­de­pen­dently of Google and Apple. Because the con­se­quence is that al­ter­na­tive de-Googled op­er­at­ing sys­tems are much less at­trac­tive to adopt if users can­not use cru­cial apps like iden­tity wal­lets to log into gov­ern­ment ser­vices.

Waag’s own re­search find­ings on this topic sup­port this. In the EU-funded Mobifree pro­ject, we have re­searched over the past two years what makes de-Googled mo­bile soft­ware ecosys­tems valu­able for dif­fer­ent end-users. A key re­quire­ment for many of our 120 testers to switch to de-Googled op­er­at­ing sys­tems was their com­pat­i­bil­ity with apps for crit­i­cal ser­vices such as pay­ments and gov­ern­ment iden­ti­fi­ca­tion apps.

Government de­vel­op­ers there­fore have to con­sider deeper stack lev­els when op­ti­miz­ing in­ter­op­er­abil­ity. Since Play Integrity API clearly vi­o­lates the Digital Markets Act, it also con­tra­dicts the goals of ID wal­lets to ad­vance European sov­er­eignty.

European mem­ber states lack a uni­fied ap­proach to im­ple­ment wal­lets

Part of the prob­lem lies in the gov­er­nance of the wal­let de­sign process. The EU pro­vides a gen­eral tech­ni­cal frame­work for the wal­let ar­chi­tec­ture, the Architecture Reference Framework. While it does not re­quire European gov­ern­ments to use Google at­tes­ta­tion, it does rec­om­mend it. This leads to an in­co­her­ent European stance to­wards Google, with some coun­tries not us­ing it, while oth­ers en­force Google’s ecosys­tem.

Some mem­ber states, such as Italy, have in­ter­preted the EU’s rec­om­men­da­tion to use the Play Integrity API as manda­tory. Others, like Switzerland, rely on Android’s at­tes­ta­tion mech­a­nism. They dropped Play Integrity due to data pro­tec­tion, data sov­er­eignty, and free­dom-of-choice con­cerns. The Netherlands and Italy use Play Integrity un­con­di­tion­ally. By do­ing so, they in­ter­pret the EU’s rec­om­men­da­tions for us­ing Google’s and Apple’s at­tes­ta­tion soft­ware in very strict terms.

If Europe is se­ri­ous about dig­i­tal au­ton­omy, it should rule out Google and Apple at­tes­ta­tion en­tirely from the Architecture Reference Framework and man­date open, hard­ware-based at­tes­ta­tion mech­a­nisms. Countries like Switzerland demon­strate that us­ing Google Play Integrity is not jus­ti­fied, and that other so­lu­tions are avail­able.

Public in­fra­struc­ture de­mands pub­lic ac­count­abil­ity, and there are ways to act

Because dig­i­tal wal­lets are pub­lic in­fra­struc­ture, their de­sign must be sub­ject to pub­lic par­tic­i­pa­tion and ac­count­abil­ity. The prob­lems and con­tra­dic­tions ex­plained above de­serve a pub­lic de­bate. Citizens and de­vel­op­ers are rais­ing con­cerns on na­tional repos­i­to­ries — in­clud­ing Germany’s pub­lic wal­let de­vel­op­ment tracker (gitlab.opencode.de) and Switzerland’s open dis­cus­sion fo­rum (github.com/​orgs/​swiyu-ad­min-ch). These are le­git­i­mate chan­nels, but they reach only a nar­row tech­ni­cal au­di­ence.

If you are an ex­pert work­ing on this topic who wants to pro­mote change, get in touch.

What you can do:

If you are a user of al­ter­na­tive, de-Googled op­er­at­ing sys­tems, con­tact the de­vel­op­ers of your coun­try’s EUDI Wallet app and de­mand in­de­pen­dence from Google and Apple at­tes­ta­tion (for the Dutch wal­let, go to the con­tact page of the Ministry of Foreign Affairs’ EDI web­site)

If you are a con­cerned cit­i­zen, con­tact your elected rep­re­sen­ta­tives to de­mand mak­ing ID wal­lets in­de­pen­dent from Google and Apple.

If you are a jour­nal­ist: fol­low the po­lit­i­cal and de­sign process. Like the re­cent Dutch Solvinity case, this story de­serves on­go­ing and wide cov­er­age be­cause it may be a wa­ter­shed mo­ment to ce­ment Google’s and Apple’s power po­si­tion, or not. See the EUDI Wallet web­page on de­vel­oper.over­heid.nl for de­vel­op­ment up­dates and repos­i­to­ries, and check out the EDI web­site of the Dutch Ministry of Foreign Affairs for mee­tups and con­tact de­tails.

Notes

In this ar­ti­cle, we fo­cus on Google’s Play Integrity API. We do so be­cause it has an im­pact on the use of al­ter­na­tive op­er­at­ing sys­tems based on Android.

We went there to cover it. We put ques­tions to se­nior politi­cians, in­clud­ing the US am­bas­sador to Belgium, Bill White. After at­tempt­ing to ask a ques­tion, we were pulled out of the event by po­lice, had our IDs taken and were then ques­tioned — be­fore the em­bassy in­structed the po­lice to es­cort us off the grounds en­tirely. The of­fi­cers, we later learned, had been told that Samuel was an “active threat.”

This is what hap­pened.

A 250th birth­day, paid for by pri­vate com­pa­nies.

A 250th birth­day, paid for by pri­vate com­pa­nies.

Under Donald Trump, the US is throw­ing par­ties to mark the 250th an­niver­sary of the US Declaration of Independence. But these are not, as you might think, of­fi­cial, Congress-approved par­ties, but or­gan­ised by a pri­vate com­pany called Freedom 250.

The Brussels edi­tion is the only one of its kind in Europe. Dozens of European and American com­pa­nies con­tributed around €3 mil­lion to it. The three American em­bassies in Brussels — to Belgium, the EU, and NATO — rented out Parc du Cinquantenaire.

It was filled with at­tempts at American cul­tural ex­ports such as American foot­ball (whose play­ers were Belgian), cheer­lead­ers (from Antwerp), Philly Cheesesteaks (also made by Belgians), Mac and Cheese, and Budweiser (owned by a Belgian com­pany).

And the au­di­ence? Several thou­sand, mainly of­fi­cials work­ing in em­bassies and in­sti­tu­tions, as well as spon­sors and big com­pa­nies. Either way: less than the 8,000+ that the em­bassy was hop­ing to get.

A few days be­fore the event, Samuel had pub­lished on his Instagram that am­bas­sador White tac­itly threat­ened an American and Belgian res­i­dent af­ter that cit­i­zen urged the American coun­try mu­sic band Zac Brown Band not to per­form at the event, a story he is still re­port­ing and will fol­low up in more de­tail soon.

So when we reached the am­bas­sador on Sunday evening, we asked him about it and filmed the ex­change. A per­son who we as­sume was his press of­fi­cer told us we were not al­lowed to ask any ques­tions, and that was that.

About 20 min­utes later, roughly eight Belgian po­lice of­fi­cers in plain clothes sur­rounded us and pulled us out of the event. None of them wore vis­i­ble iden­ti­fi­ca­tion, only flash­ing a badge for a short enough time not to reg­is­ter. When we first asked who they were, they phys­i­cally pushed us, said “we are po­lice,” and or­dered us to come with them im­me­di­ately.

For the next 15 min­utes or so, the of­fi­cers con­fis­cated our IDs and ques­tioned us. They asked whether The European Correspondent had a po­lit­i­cal lean­ing, whether we had an agenda, and how we had got into the event (that the American em­bassy in­vited us to).

Eventually, they ac­cepted that we were jour­nal­ists and that they dis­agreed with de­tain­ing us. They were “just do­ing their job,” they told us. It be­came clear that the of­fi­cers had been given no real in­for­ma­tion about who we were, only that he was an “active threat” (which could mean a phys­i­cal threat), and needed to be de­tained, iden­ti­fied, and re­moved. That’s prob­a­bly why the de­ten­tion was ag­gres­sive and con­ducted with­out dis­cus­sion.

Even af­ter the of­fi­cers recog­nised their mis­take, the em­bassy told them we were no longer per­mit­ted in­side, and they es­corted us out — out of an event we had been in­vited to at­tend as press.

Open ques­tions

Open ques­tions

Much about the evening is still un­clear.

It is un­clear who ex­actly paid how much for the party. It is un­clear whether the po­lice pres­ence that re­moved us was paid for by the American or­gan­is­ers or by Belgian tax­pay­ers. It is un­clear how much the em­bassy paid for rent­ing the park.

And it is un­clear who has com­pen­sated the shops and restau­rants around the Cinquantenaire that were forced to close for days be­cause of the se­cu­rity op­er­a­tion around the event.

Being asked for clar­i­fi­ca­tion about the de­ten­tion the day af­ter, Bill White con­fused us with the writer of the let­ter to the Zac Brown Band and said that we were both “losers”, re­fus­ing to give us any ex­pla­na­tion.

We have reached out to Belgian au­thor­i­ties for clar­i­fi­ca­tion and European politi­cians pre­sent at the event for com­ment.

My name is Daniel Connell. I pro­to­type and de­velop ba­sic tech­nolo­gies which any­one can make us­ing re­cy­cled ma­te­ri­als and sim­ple tools.

The aim is for every­one every­where to be able to build and main­tain their own in­fra­struc­ture; pro­duc­ing their own en­ergy, food, clean wa­ter, com­mu­ni­ca­tions, and any­thing else they need.

All de­signs are open source and li­cense free for any pur­pose, and full con­struc­tion tu­to­ri­als and how-tos are avail­able here.

The Facebook group is also a good place to ask ques­tions and post re­sults from your own builds.

Featured In: Al Jazeera ¦ The Guardian ¦ New Statesman ¦ Le Monde ¦ Makezine

Richard Audoly, Miles Guerin, Srinidhi Narayanan, and Rachel Schuh

The la­bor share of in­come in the U.S. is cur­rently at its low­est-ever level in the post-war pe­riod. The la­bor share mea­sures the frac­tion of eco­nomic out­put paid to work­ers as wages and salaries. As such, it is a use­ful bench­mark for wage growth: when the la­bor share falls, it means that pro­duc­tiv­ity, prices, or both are grow­ing faster than wages. After much-stud­ied drops in the 2000s, the la­bor share fell sharply again af­ter the COVID pan­demic. In this post, we com­pare the dy­nam­ics of the la­bor share post-COVID to ear­lier pe­ri­ods to un­der­stand whether the re­cent de­cline rep­re­sents the con­tin­u­a­tion of a trend or a new and dis­tinct phe­nom­e­non. We find that both the cycli­cal­ity of the la­bor share and the con­tri­bu­tion of re­al­lo­ca­tion to the la­bor share post-COVID are sim­i­lar to ear­lier pe­ri­ods.

The Evolution of the Labor Share

To con­tex­tu­al­ize the post-COVID de­cline in the la­bor share, we first de­scribe its long-run evo­lu­tion, il­lus­trated in the chart be­low. For much of the post-war pe­riod, the la­bor share was re­mark­ably sta­ble, hov­er­ing around 63 per­cent through the late 20th century. Starting in the early 2000s, how­ever, it en­tered a sus­tained de­cline, with a par­tic­u­larly sharp drop dur­ing the global fi­nan­cial cri­sis (GFC). The la­bor share is a core ob­ject of in­ter­est in the aca­d­e­mic and pub­lic de­bate—it mea­sures the share of ag­gre­gate in­come go­ing to work­ers as op­posed to cap­i­tal—and a large aca­d­e­mic lit­er­a­ture dis­cusses the long-run forces be­hind this down­ward trend, in­clud­ing tech­no­log­i­cal change, the rise of “superstar” firms, and in­creas­ing markups.

The Labor Share Has Declined Since the 2000s

In this post, we zoom in on the post-COVID de­cline in the la­bor share. After sta­bi­liz­ing in the 2010s, the la­bor share de­clined again dur­ing the post-COVID pe­riod, ul­ti­mately falling 1.6 per­cent­age points be­low its pre-pan­demic level. The la­bor share now stands at an all-time low in the post-war pe­riod. Given that the la­bor share de­clined in the two most re­cent re­ces­sions, how does the post-COVID de­cline com­pare to ear­lier re­ces­sion­ary episodes?

Is the Post-COVID Decline Typical Across U.S. Recessions?

In the next chart, we study the path of the la­bor share around var­i­ous re­ces­sion–ex­pan­sion pe­ri­ods, trac­ing its tra­jec­tory from the on­set of a down­turn. We then as­sess whether the post-COVID de­cline mim­ics the dy­nam­ics of the la­bor share across ear­lier cy­cles.

The Post-COVID Evolution of the Labor Share Aligns with Pre-2000 Recessions

Most pre-2000 pe­ri­ods fol­low a sim­i­lar pat­tern: the la­bor share in­creases dur­ing a re­ces­sion, de­clines through re­cov­ery, and then rises again later in the ex­pan­sion. While we re­strict at­ten­tion to the two most re­cent pre-2000 re­ces­sion–ex­pan­sion pe­ri­ods (1979 – 1989 and 1989 – 2000) and omit ear­lier episodes for clar­ity, we find broadly sim­i­lar dy­nam­ics across these cy­cles.

This be­hav­ior changes in the 2000s. Following both the dot­com re­ces­sion and the GFC, the de­cline in the la­bor share dur­ing ex­pan­sion is steeper than in ear­lier cy­cles. Moreover, un­like in pre-2000 episodes, the la­bor share does not mean­ing­fully re­bound later in the ex­pan­sion.

The dy­nam­ics of the la­bor share at the on­set of the COVID pan­demic ac­tu­ally ap­pear more sim­i­lar to pre-2000 re­ces­sions: the la­bor share in­creases sharply fol­lowed by a mod­est de­cline be­fore flat­ten­ing out. Judging by past re­ces­sions, we would need a longer ex­pan­sion to see the la­bor share rise again.

Another source of dif­fer­ence across re­ces­sion–ex­pan­sion episodes is the de­gree of re­al­lo­ca­tion in eco­nomic ac­tiv­ity. As busi­nesses and house­holds ad­justed to pan­demic re­stric­tions, eco­nomic ac­tiv­ity may have shifted sub­stan­tially across sec­tors. This raises the ques­tion of whether these shifts con­tributed to the re­cent de­cline in the ag­gre­gate la­bor share.

Did Sectoral Reallocation Drive the Post-COVID Decline in the Labor Share?

Some in­dus­tries have higher la­bor shares be­cause they rely more heav­ily on hu­man la­bor and skills. For in­stance, health­care and ed­u­ca­tion tend to have higher la­bor shares be­cause out­put re­lies pri­mar­ily on work­ers’ time and ex­per­tise, while man­u­fac­tur­ing and agri­cul­ture have lower la­bor shares be­cause ma­chin­ery and au­toma­tion play a larger role in out­put. If, in the post-COVID years, a larger share of out­put came from low la­bor share in­dus­tries, the ag­gre­gate la­bor share could de­cline even if la­bor shares within in­dus­tries re­mained con­stant.

To see if COVID stands out in terms of re­al­lo­ca­tion com­pared to ear­lier re­ces­sions, we con­struct a re­al­lo­ca­tion in­dex, de­fined as the ag­gre­gate of ab­solute changes in sec­toral out­put shares across pe­ri­ods. The chart be­low plots this in­dex across the three most re­cent re­ces­sion episodes: 1999 – 2004, 2007 – 2012, and 2019 – 2024. We find that al­though sec­toral re­al­lo­ca­tion spiked at the on­set of the COVID pan­demic, it then mod­er­ated and sta­bi­lized at a lower level. In con­trast, ear­lier re­ces­sions ex­hib­ited more per­sis­tent and in­creas­ing re­al­lo­ca­tion.

COVID Led To a Spike in Economic Reallocation That Quickly Subsided

However, the over­all amount of re­al­lo­ca­tion does not by it­self de­ter­mine the ef­fect on the ag­gre­gate la­bor share. Even mod­est shifts in eco­nomic ac­tiv­ity could re­duce the ag­gre­gate la­bor share if they move out­put to­ward in­dus­tries with lower la­bor in­ten­si­ties. To eval­u­ate this chan­nel, we im­ple­ment a stan­dard “shift-share” de­com­po­si­tion of the pay­roll share, which mea­sures la­bor in­come ex­clud­ing non­wage com­pen­sa­tion. We de­com­pose the change in the ag­gre­gate pay­roll share into two parts: changes hap­pen­ing within in­dus­tries (“shift”) and changes due to eco­nomic ac­tiv­ity mov­ing be­tween in­dus­tries (“share,” or re­al­lo­ca­tion). The chart be­low pre­sents this de­com­po­si­tion for the same re­ces­sion episodes as be­fore.

The red bars show the to­tal change in the ag­gre­gate pay­roll share be­tween the first and last year of each pe­riod. The gold bars cap­ture how much of that change in the pay­roll share was caused by shifts within in­dus­tries—for in­stance, changes in how much re­tail pays work­ers rel­a­tive to its own out­put. The blue bars show how much of the change is due to eco­nomic ac­tiv­ity mov­ing be­tween in­dus­tries—for in­stance, whether out­put shifted to­ward sec­tors that gen­er­ally have higher or lower pay­roll shares.

Within-Industry Declines, Not Between-Industry Reallocation, Drove the Fall in the Aggregate Payroll Share

From this shift–share de­com­po­si­tion, we find that de­clines in the ag­gre­gate pay­roll share dur­ing COVID, and the pre­vi­ous two re­ces­sions, were en­tirely dri­ven by changes within in­dus­tries rather than shifts across in­dus­tries. Across all three re­ces­sion pe­ri­ods, we find that move­ments in out­put across sec­tors con­tribute noth­ing or very lit­tle to the change in the ag­gre­gate pay­roll share.

Conclusion

This post doc­u­ments a per­sis­tent drop in the la­bor share fol­low­ing the COVID pan­demic. Is this de­cline a dis­tinct change from the re­cent be­hav­ior of the la­bor share in the U.S.? Along the two key di­men­sions we in­ves­ti­gate, our an­swer is no. First, the la­bor share’s tra­jec­tory post-COVID broadly fol­lows the cycli­cal pat­terns ob­served in ear­lier re­ces­sions, with a de­cline dur­ing the re­cov­ery phase that mir­rors his­tor­i­cal dy­nam­ics. Second, the de­cline in the la­bor share since COVID is dri­ven pri­mar­ily by within-in­dus­try changes rather than shifts in eco­nomic ac­tiv­ity across sec­tors. Taken to­gether, these re­sults sug­gest that the post-COVID de­cline fol­lows the same cycli­cal pat­terns as ear­lier re­ces­sions and is dri­ven by the same within-in­dus­try forces, and they pro­vide lit­tle ev­i­dence that it will evolve dif­fer­ently from past episodes.

Richard Audoly is a re­search econ­o­mist in the Federal Reserve Bank of New York’s Research and Statistics Group.

Miles Guerin is a re­search an­a­lyst in the Federal Reserve Bank of New York’s Research and Statistics Group.

Srinidhi Narayanan is a re­search an­a­lyst in the Federal Reserve Bank of New York’s Research and Statistics Group.

Rachel Schuh is a re­search econ­o­mist in the Federal Reserve Bank of New York’s Research and Statistics Group.

How to cite this post: Richard Audoly, Miles Guerin, Srinidhi Narayanan, and Rachel Schuh, “The Post‑COVID Decline in the Labor Share,” Federal Reserve Bank of New York Liberty Street Economics, June 24, 2026, https://​doi.org/​10.59576/​lse.20260624 BibTeX: View |

DisclaimerThe views ex­pressed in this post are those of the au­thor(s) and do not nec­es­sar­ily re­flect the po­si­tion of the Federal Reserve Bank of New York or the Federal Reserve System. Any er­rors or omis­sions are the re­spon­si­bil­ity of the au­thor(s).

Typing a few let­ters and num­bers into my web browser, I find my­self gap­ing at the iden­tity doc­u­ments of com­plete strangers. The pass­port of a young woman from Germany. The pass­port of a man from Spain with glasses rest­ing on his head. The front and back of an­other man’s dri­ver’s li­cense, a stereo­typ­i­cally goofy ex­pres­sion on his face.

They were all sit­ting un­pro­tected at pub­lic URLs, with no pass­word or ac­cess con­trol of any sort. If I sent you a link, you could have looked at some­one’s pass­port.

“We have to do some­thing about it as fast as pos­si­ble, be­cause peo­ple will find this and re­sell it. It will do dam­age,” Sammy Azdoufal told me in May.

Azdoufal is the se­cu­rity re­searcher who used Claude Code to help dis­cover that every DJI Romo ro­bot vac­uum cleaner and a mil­lion baby mon­i­tors and se­cu­rity cam­eras were em­bar­rass­ingly easy to hack. This time, he says he dis­cov­ered over 985,000 photo IDs sit­ting on the pub­lic in­ter­net for any half-de­cent hacker to steal.

If you’ve vis­ited a cannabis club in Spain, Azdoufal says, chances are your photo ID was among them — and pos­si­bly your phone num­ber, ad­dress, your fa­vorite strains of cannabis, and how much you con­sumed each month while there. Azdoufal says celebri­ties are in the data­base, too, and vis­i­tors from all over the world, in­clud­ing 30,000 from the United States. “They have fa­mous peo­ple,” says Azdoufal. “People who don’t want every­one to know they smoke weed.”

Here’s a rough sum­mary of the user base that Azdoufal’s au­to­mated tool was able to see and the names of some of the clubs:

Image: Sammy Azdoufal

It’s not the clubs that did­n’t pro­tect these iden­tity doc­u­ments. An Irish com­pany called Cannabis Club Systems (CCS), for­mally Nefos Solutions, de­vel­ops and pro­vides the soft­ware these clubs use for sales, ac­count­ing, and ad­mis­sions, in­clud­ing a ver­i­fi­ca­tion sys­tem where re­cep­tion­ists up­load your IDs and self­ies to Nefos’ cloud.

Traditionally, you’d need to pro­vide a photo ID every time you wanted to get into a club. But with the ver­i­fi­ca­tion sys­tem, the re­cep­tion­ist can pull up your stored iden­tity doc­u­ments and check if your face matches. There’s also an op­tional app called PuffPal that lets clubs scan a QR code for faster en­try.

But when Azdoufal de­com­piled that PuffPal app, he ex­plains in his re­port, he dis­cov­ered that Nefos had no mean­ing­ful level of se­cu­rity. He dis­cov­ered a se­cret key for the Stripe pay­ments plat­form sit­ting in­side the app in plain text. He dis­cov­ered he could pull up any mem­ber’s pro­file just by chang­ing one num­ber. If those pro­files in­cluded their phone num­ber, home ad­dress, pass­port, and weed pref­er­ences, he now had ac­cess to them too.

And then, he dis­cov­ered that those pass­ports, dri­vers li­censes, and photo IDs were stored at pub­lic URLs as sim­ple as this: https://​cc­snubev2.com/​v8/​im­ages/​_{club}/​ID/{​user_id}-front.jpg

Those clubs were up­load­ing 5,000 new photo IDs with these in­se­cure URLs every day, Azdoufal tells me.

He also found an ad­min por­tal ac­ces­si­ble via the pub­lic in­ter­net — and that the cannabis clubs had a triv­ial level of se­cu­rity on their own ac­counts, us­ing pass­words that could the­o­ret­i­cally be cracked in min­utes with a mod­ern GPU. Private chat mes­sages be­tween clubs and mem­bers through the PuffPal app were also vul­ner­a­ble.

The good news: Roughly a month af­ter we reached out to Nefos, the com­pany seems to fi­nally be tak­ing mean­ing­ful ac­tion. The com­pany says it’s shut­ting down its en­tire PuffPal sys­tem and vul­ner­a­ble APIs un­til they can be fixed — in Azdoufal’s lat­est tests on June 10th, pass­port im­ages and per­sonal data seem to be se­cure. Nefos has also in­formed lo­cal au­thor­i­ties and says it will take re­spon­si­bil­ity to make fixes, pay fines, and tell users what hap­pened.

In a phone in­ter­view, Nefos co­founder Andreas Nilsen tells The Verge that he’s in touch with Ireland’s Data Protection Commission (DPC) about the data breach — a fact that DPC spokesper­son Evan O’Leary con­firmed to us by email. “We have to com­mu­ni­cate to every­one that was po­ten­tially ex­posed,” Nilsen tells me, say­ing he hopes the DPC can show his com­pany how to do that prop­erly. Nilsen claims there’s cur­rently no ev­i­dence that any out­sider ac­cessed the data other than Azdoufal.

But it took far too long for Nefos to take the threat se­ri­ously. It took five days and the threat of a story be­fore the com­pany replied to us, long af­ter Azdoufal reached out. Then, Nefos be­gan by pa­per­ing over the holes in­stead of risk­ing busi­ness.

I was pre­pared to write this story at the be­gin­ning of June, af­ter Azdoufal told me Nefos had fi­nally locked down the pass­port im­ages. But on June 4th, I sur­prised Azdoufal by show­ing him that his very own pass­port was on­line once again, with­out any pro­tec­tion.

That’s be­cause Nefos had not yet stopped cannabis clubs from us­ing the PuffPal app, and clubs were com­plain­ing the locked-down im­ages weren’t show­ing up the way they used to — so Nefos sim­ply un­locked the im­ages again. While Nilsen claims the im­ages were locked down “70 per­cent of the time” since Azdoufal and I got in touch, it’s pretty clear that Nefos made a de­ci­sion to pri­or­i­tize its cus­tomers in­stead of the threat.

On June 9th, Azdoufal dis­cov­ered that even though Nefos had locked down the pass­port im­ages and photo IDs with to­kens, every­thing else in the user pro­files was still eas­ily ac­ces­si­ble: pass­port num­bers, phone num­bers, email ad­dresses, home ad­dresses, every­thing.

All a hacker had to do was type “curl -X POST https://​cc­snubev2.com/​v8/​api/​user­Pro­file.php -d “user_id=[NUMBER]&[CLUB NAME]=test&language=en” into a com­mand line, and the servers would freely give up a ream of per­sonal in­for­ma­tion. After we brought this to Nefos’ at­ten­tion, that hole, too, has been closed.

But how could the com­pany be so care­less? “I don’t want to put the blame on oth­ers be­cause at the end of the day it re­sides with us,” Nilsen says. But he does point the fin­ger at 9Series, an out­sourc­ing firm he claims was re­spon­si­ble for de­vel­op­ing the PuffPal app and cre­at­ing all the vul­ner­a­ble APIs it used to pull un­pro­tected data from Nefos’ user data­base. (9Series did not have a re­sponse by pub­lish time.)

Now that PuffPal is down, Nefos is email­ing every club to let them know their mem­bers won’t be able to use those QR codes for en­try — but they can still pull up IDs from Nefos’ servers af­ter scan­ning a mem­ber’s RFID card or typ­ing in their phone num­ber, among other ex­am­ples.

Nilsen claims his com­pany will not sim­ply re­launch un­se­cured PuffPal if the clubs ask. “We’re go­ing to tell them we can’t,” he says. “We will make sure, af­ter this de­ba­cle, that this is ver­i­fied by an in­de­pen­dent se­cu­rity re­searcher and guar­an­tee that this is 100 per­cent se­cure.” He says Nefos is part­ing ways with 9Series and hopes to have a new app within a few months.

Nilsen says he’s aware that un­der EU law, his com­pany legally had to dis­close the breach within 72 hours or pay sig­nif­i­cant fines, some­thing the com­pany did­n’t do. “I’m sure we’ll get what­ever kind of penalty there is,” Nilsen says.

Just last month, a web­site called the UK Visa Portal sim­i­larly ex­posed at least 100,000 pass­ports to any­one who could guess a URL. Let’s hope this is a wakeup call.

Follow top­ics and au­thors from this story to see more like this in your per­son­al­ized home­page feed and to re­ceive email up­dates.

Sean Hollister

On June 26, the County Manager of Henrico County, Virginia, John Vithoulkas, sent an email to thou­sands of county em­ploy­ees ask­ing them to help the lo­cal gov­ern­ment con­serve elec­tric­ity. “Beginning July 1st, the rate we pay for elec­tric­ity used in all Henrico County gov­ern­ment and school fa­cil­i­ties will in­crease dra­mat­i­cally — by 25%, in­creas­ing costs by an es­ti­mated $5 mil­lion next fis­cal year. We an­tic­i­pate more rate in­creases for elec­tric­ity in the years ahead,” a copy of the email ob­tained by 404 Media said (emphasis his).

Henrico County is a com­mu­nity of more than 350,000 peo­ple in east­ern Virginia just out­side of Richmond. It also hosts 37 data cen­ters and there are plans to build 17 more, in­clud­ing plans to con­vert hun­dreds of acres of Civil War bat­tle­fields into data cen­ters. Thanks to its prox­im­ity to DC and vast amounts of land, Henrico County be­came a data cen­ter hub seem­ingly overnight and its ser­vices clients big and small. Meta built a data cen­ter there in 2017.

This post is for paid mem­bers only

Become a paid mem­ber for un­lim­ited ad-free ac­cess to ar­ti­cles, bonus pod­cast con­tent, and more.

Subscribe

Sign up for free ac­cess to this post

Free mem­bers get ac­cess to posts like this one along with an email round-up of our week’s sto­ries.

Subscribe

Already have an ac­count? Sign in

The Claude Science app runs analy­ses, searches data­bases, and traces every step from data wran­gling to pub­li­ca­tion, so you can spend time on sci­ence.

Download now

Claude sci­ence

[ 002 ]

View pro­teins, struc­tures, and mol­e­cules na­tively, with every re­sult re­pro­ducible and traced to its code.

Figures, ta­bles, and note­books in­clude the ex­act code, en­vi­ron­ment, and con­ver­sa­tion that pro­duced them, so they can be re­pro­duced, edited, or de­fended months later.

Inspect pro­teins, align­ments, ge­nomic tracks, chem­i­cal struc­tures, and PDFs in their na­tive form, with no ex­tra in­stal­la­tion re­quired.

A back­ground re­viewer flags in­cor­rect ci­ta­tions, un­trace­able num­bers, and fig­ures that don’t match their un­der­ly­ing code.

Annotate a fig­ure to re­quest ed­its or ask a ques­tion. The agent reads the code that pro­duced it and ed­its di­rectly.

Write up re­sults along­side the analy­sis that pro­duced them, with ren­dered Markdown and LaTeX pre­views.

Builds en­vi­ron­ments and man­ages com­pute on your lap­top, your clus­ter, or GPUs.

Claude man­ages the en­vi­ron­ments each analy­sis needs, whether on your lap­top, a Linux box, or an HPC lo­gin node.

Writes batch scripts, then sub­mits and man­ages jobs over SSH on your own ma­chine or HPC clus­ter, or through your Modal ac­count.

Variables, dataframes, and loaded mod­els stay in mem­ory across the whole analy­sis, so it­er­a­tion is fast.

Connects to data­bases and tools your lab needs, so you can start work in your field right away.

Genomics, sin­gle-cell, pro­teomics, struc­tural bi­ol­ogy, chem­in­for­mat­ics, and more. Reads lit­er­a­ture and can query 60+ sci­en­tific data­bases, so you pull what you need with­out learn­ing each one.

Save any pipeline as a reusable skill, or con­nect to your lab’s pre­ferred tool with a con­nec­tor, and every fu­ture ses­sion in­her­its it au­to­mat­i­cally.

Includes fully sourced in­di­ca­tion dossiers avail­able to­day, and a grow­ing set of skills that build the case be­hind every pro­gram.

Introducing Claude Science

One re­search en­vi­ron­ment for your lab: con­nect to sci­en­tific data­bases, re­search tools, ELNs, pro­tein and struc­ture mod­els, your HPC, and more. Available now for ma­cOS and Linux.

Claude sci­ence

[ 003 ]

The app is pre-con­fig­ured for every ma­jor do­main in life sci­ences. When a pro­ject spans dis­ci­plines, it can help solve hard prob­lems.

Single-cell RNA-seq analy­sis

Cluster and an­no­tate mil­lions of cells across tis­sues, sur­face marker genes, and trace every fig­ure back to the code that made it.

Phylogenetic and evo­lu­tion­ary analy­sis

Align or­thologs, in­fer max­i­mum-like­li­hood trees, and map func­tional residues onto the phy­logeny in a sin­gle re­pro­ducible ses­sion.

Protein struc­ture and lan­guage model work

Pull pre­dicted struc­tures, layer on do­mains and clin­i­cal vari­ants, and ex­plore the model in­ter­ac­tively in 3D.

Cheminformatics and mol­e­c­u­lar de­sign

Search bioac­tiv­ity data, com­pute prop­er­ties and sim­i­lar­i­ties, and draw or re­fine struc­tures in a live 2D sketcher.

“With Claude Science I can go from raw data to a pub­li­ca­tion-qual­ity fig­ure in a sin­gle ses­sion — run­ning the analy­sis, gen­er­at­ing ex­ploratory plots, and re­fin­ing them all within a sin­gle pro­ject. The code and the con­ver­sa­tion be­hind each fig­ure are welded to it, mak­ing every ver­sion fully re­pro­ducible so I can it­er­ate, re­vert, and fork as much as needed.”

Mike Nichols, Computational Biologist, Manifold Bio

“Claude Science is en­abling analy­ses that sim­ply would­n’t have been fea­si­ble for me as a non-com­pu­ta­tional bi­ol­o­gist. Honestly, it’s re­ally trans­for­ma­tive. Its abil­ity to run these analy­ses, flu­idly nav­i­gate the ex­ist­ing web­sites, and con­sider the sci­ence care­fully is quite im­pres­sive… I’ve found my­self think­ing of ques­tions I’ve had for years and rush­ing to Claude Science to start a pro­ject.”

Iain Cheeseman, Professor of Biology, Whitehead Institute and Department of Biology, MIT

“Claude Science is, with­out ex­ag­ger­a­tion, the most im­pres­sive AI-integrated sci­en­tific com­put­ing en­vi­ron­ment I have en­coun­tered.”

Prasad Shirvalkar, Associate Professor of Neurosurgery and Anesthesiology, UCSF

“Claude Science im­me­di­ately found a lab­o­ra­tory virus con­t­a­m­i­nant in our bulk RNA-seq data. We spun our wheels on this for the bet­ter part of a year, and it came out as one of the first key find­ings.”

Stephen Francis, Principal Investigator, UCSF

“New agen­tic fact-check­ing ca­pa­bil­i­ties in Claude Science have helped our team build con­fi­dence in the bio­med­ical out­puts. This makes Claude par­tic­u­larly use­ful for our triage and med­ical re­view work.”

Elliott Sharp, Director of Pipeline Strategy, Every Cure

“Claude Science has be­come a cen­tral pro­ject-fo­cused work­flow for my re­search. I have han­dled com­plex cloning tasks to se­quenc­ing analy­sis all within Claude Science.”

Zach Stevenson, Postdoc, Shendure Lab

“Xaira is build­ing AI-native ca­pa­bil­i­ties across the full arc of drug dis­cov­ery and de­vel­op­ment, from pre­dic­tive mod­els to phys­i­cal AI sys­tems that learn from bi­ol­ogy at scale, pow­ered by agen­tic work­flows de­signed to cre­ate the next gen­er­a­tion of med­i­cines. Claude Code and Claude Science are ac­cel­er­at­ing that work, com­press­ing the path from hy­poth­e­sis to val­i­da­tion and ad­vanc­ing our ther­a­peu­tic pipeline, en­abling our sci­en­tists to fo­cus on the dis­cov­er­ies that mat­ter most and bring in­no­v­a­tive med­i­cines to pa­tients faster.”

Xaira

“Claude Science helps me turn bi­o­log­i­cal ques­tions into first-pass lit­er­a­ture re­views and ge­nomics analy­ses that are well cited, hy­poth­e­sis-gen­er­at­ing, and ready for team cri­tique.”

Trygve Bakken, Associate Investigator, Allen Institute

“LatchBio pro­vides agent-na­tive data in­fra­struc­ture to store, process, and vi­su­al­ize large mol­e­c­u­lar datasets from their fa­vorite in­ter­faces. Connecting LatchBio to Claude Science via MCP al­lows re­searchers to lever­age ver­i­fied bioin­for­mat­ics tools de­ployed in col­lab­o­ra­tion with as­say de­vel­op­ers like Vizgen, TakaraBio and AtlasXOmics to com­plete agent work­flows with high sci­en­tific ac­cu­racy.”

Kenny Workman, Co-founder & CTO, LatchBio

“Helix® is build­ing the largest linked clin­ico-ge­nomic dataset in the world - cur­rently over 500,000 records and on a tra­jec­tory to mul­ti­ple mil­lions. By mak­ing deep ge­netic and phe­no­typic data avail­able to Claude Science through an MCP server, we’re let­ting re­searchers dis­cover our data in­side a sin­gle, AI-native en­vi­ron­ment. Many of these re­searchers use Claude as their go to plat­form for dis­cov­ery and this brings the full depth of our data to where the sci­ence ac­tu­ally gets done.”

James Lu, MD, PhD. Chief Executive Officer & Co-founder, Helix

“Claude Science is ac­cel­er­at­ing the way we de­sign ex­per­i­ments and iden­tify new treat­ments. It’s dra­mat­i­cally speed­ing up the time it takes to go from ge­netic sig­nal to po­ten­tial ther­apy.”

Professor Joseph Powell, Garvan Institute

0/5

Works with your stack

Connectors bring your in­ter­nal APIs, ELNs, and be­spoke pipelines into the work­flow, so the Claude Science app works with the tools your lab al­ready runs.

Claude Science

[ 004]

FAQs

No. Claude Science is a pub­lic beta app, not a model. It uses the same Claude mod­els your plan in­cludes. What’s new is every­thing around them: the sci­en­tific tools, data­base con­nec­tions, and com­pute in­te­gra­tions that let Claude run full analy­ses on your own in­fra­struc­ture.

General AI as­sis­tants can dis­cuss bi­ol­ogy, but they can’t run a pipeline, nav­i­gate sci­en­tific data­bases, or­ches­trate clus­ter jobs, or keep track of what hap­pened in a pre­vi­ous ses­sion. Claude Science man­ages com­pute en­vi­ron­ments per spe­cial­ist, and saves full prove­nance on every re­sult. The app ships with analy­sis spe­cial­ists for ge­nomics, sin­gle-cell, pro­teomics, struc­tural bi­ol­ogy, chem­in­for­mat­ics, and more. It can con­nect na­tively to 60+ sci­en­tific data­bases and do­main-spe­cific open mod­els. Claude Science uses the skills in NVIDIA’s BioNeMo Agent Toolkit to con­nect na­tively to the life sci­ences mod­els and li­braries in BioNeMo, in­clud­ing Evo 2, Boltz-2, and OpenFold3.

The Claude Science app is de­signed to work with what you’ve al­ready built. Connect your ex­ist­ing tools, ELNs, and in­ter­nal sys­tems through con­nec­tors. Bring your own scripts—it can read, run, and build on ex­ist­ing Python, R, and shell work­flows with­out re­quir­ing you to re­build any­thing from scratch.

No. The Claude Science app is the work­bench where spe­cial­ized tools work to­gether. Scientific tools, plat­forms, and do­main-spe­cific open mod­els can plug in as skills or con­nec­tors. You keep what works and fill in the gaps.

The Claude Science app runs on your in­fra­struc­ture; raw datasets and com­pute stay lo­cal; con­tent in­cluded in prompts and model re­sponses is processed by Anthropic un­der stan­dard re­ten­tion. Contact sales to dis­cuss your team’s spe­cific needs.

Install the app wher­ever your data lives: your lap­top, a lab Linux box, an HPC lo­gin node, or a cloud VM. Connect from your browser. Jobs run on lo­cal ker­nels, your Slurm clus­ter over SSH, or through your Modal ac­count.

Every ar­ti­fact the Claude Science app pro­duces in­cludes the ex­act code that gen­er­ated it, the en­vi­ron­ment it ran in, a plain-lan­guage de­scrip­tion of what was done, and the con­ver­sa­tion that led there. Results are re­pro­ducible months later, by any­one on your team. A back­ground re­viewer also flags any claim it can’t trace to ev­i­dence be­fore re­sults sur­face.

Yes. The Claude Science app is in beta for ma­cOS and Linux on Pro, Max, Team, and Enterprise plans. Team and Enterprise users need their ad­min to en­able it first.

Yes. The dis­counted Claude Team plan for re­search labs in­cludes ac­cess to the Claude Science app, and is avail­able to ac­tive sci­en­tific labs at aca­d­e­mic in­sti­tu­tions and non­profit re­search or­ga­ni­za­tions. Specifically, bio­med­ical and ba­sic sci­ence labs are be­ing pri­or­i­tized in ad­di­tion to the hard sci­ences in­clud­ing chem­istry, math, com­puter sci­ence, and physics. Eligibility is ver­i­fied through the lab’s prin­ci­pal in­ves­ti­ga­tor.

If you are a for-profit com­pany, con­tract re­search or­ga­ni­za­tion, or in­dus­try R&D team, please see our Team and Enterprise plans.

Yes. The Claude Science app is avail­able on the Enterprise plan with SSO, SCIM pro­vi­sion­ing, cus­tom roles, and us­age an­a­lyt­ics. It’s cur­rently in beta, so ad­mins should re­view the doc­u­men­ta­tion be­fore rolling out. Contact sales to dis­cuss your team’s re­quire­ments.

Start with the doc­u­men­ta­tion. It cov­ers in­stal­la­tion, con­nect­ing your tools and com­pute, and ad­min setup for Team and Enterprise.

Since post­ing on X, I’ve got­ten many DMs ask­ing ex­actly how I want to ap­proach the next phase of this pro­ject: mak­ing the drone fly with RL. Here’s the plan I have so far.

Most im­por­tantly, the RL pol­icy will di­rectly com­mand all 8 mo­tors at 50 Hz over a se­r­ial link to the flight con­troller with no tra­di­tional PID loop in the path. This is the only ar­chi­tec­ture that gives the pol­icy full au­thor­ity to re­al­lo­cate thrust when mo­tors fail.I’m fo­cus­ing on six unique fail­ure classes (ignoring ro­ta­tional equiv­a­lence): sin­gle mo­tor, ad­ja­cent pair (45°, mixed CW/CCW), 90° same-type, 135° mixed, 180° same-type, and full ESC loss (each ESC con­trols its own quad). The hard­est case is the 90° same-type fail­ure, be­cause it’s the only one that hits both prob­lems si­mul­ta­ne­ously: a yaw torque im­bal­ance (the two dead mo­tors were the same spin di­rec­tion) and a spa­tial asym­me­try in the re­main­ing thrust geom­e­try.

Losing two same-spin mo­tors leaves 2 CW and 4 CCW run­ning (or vice versa), yaw-torque im­bal­anced 2:1 at equal throt­tle. Balancing them forces the CW mo­tors to run at 2× the per-mo­tor thrust of the CCW mo­tors. At 1393 gf max per mo­tor, the yaw-bal­anced thrust ceil­ing works out to 5,572 gf — enough to main­tain a 2:1 thrust-to-weight ra­tio up to ~2.8 kg of drone weight (we’re at 1 kg). The re­main­ing 6 mo­tors span a 270° arc, so roll and pitch au­thor­ity still ex­ists. The worst case is sur­viv­able — the drone would be spin­ning, but it could still hover to a soft land­ing.

Simulation

I’m build­ing the sim in MuJoCo, be­cause it runs fast on a CPU and I have a Mac, which rules out Isaac Lab and ba­si­cally every­thing else NVIDIA-shaped. For a sin­gle rigid body with 8 thrust points, MuJoCo is more than enough, and I can run ~128 en­vi­ron­ments in par­al­lel on my lap­top.

The model it­self comes from mea­sure­ments, not the CAD. I’ll be gath­er­ing data on:

Total mass

Inertia ten­sor via the bi­fi­lar pen­du­lum test

Motor thrust curves

Motor time con­stant

Hover throt­tle point

I’m also adding two things to my sim en­vi­ron­ment that I keep read­ing are what ac­tu­ally kill sim-to-real trans­fer for mo­tor-level con­trol:

1. Motor lag: real mo­tors take 20 – 50 ms to reach a com­manded speed. In sim, thrust changes in­stantly un­less you model it. A pol­icy that learns with in­stant mo­tors learns to twitch.

2. Loop la­tency: on the real drone, there’s ~15 – 30 ms be­tween the IMU read­ing and thrust ac­tu­ally chang­ing (serial read, in­fer­ence, se­r­ial write, ESC re­sponse). If I train with zero la­tency, the pol­icy will os­cil­late the sec­ond it touches hard­ware. This one scares me the most, so it’s get­ting ran­dom­ized ag­gres­sively (the pol­icy trains against a de­lay that changes every episode and jit­ters within episodes).

puffer. just puffer. trust me. you will thank me in about a month from now. — Chris von Csefalvay 🔜 CVPR26 (@epichrisis) June 7, 2026

puffer. just puffer. trust me. you will thank me in about a month from now.

Everything else phys­i­cal gets ran­dom­ized too: mass ±10%, per-mo­tor thrust con­stants ±15% (cheap mo­tors are not iden­ti­cal, I own eight data points prov­ing this), cen­ter of mass, bat­tery sag over a flight, sen­sor noise[4].

Training

PPO[1] via PufferLib. I looked at SAC since it’s more sam­ple-ef­fi­cient, but sam­ple ef­fi­ciency solves a prob­lem I don’t have — my sim steps are nearly free. PPO with a pile of par­al­lel en­vi­ron­ments is what al­most every sim-to-real flight pa­per I’ve read ac­tu­ally shipped, and it scales more sim­ply across par­al­lel envs and is more sta­ble un­der the vari­ance that heavy ran­dom­iza­tion adds”. (Also: an X re­ply told me “puffer. just puffer. trust me.“)

Two more de­ci­sions I stole from sim-to-real lit­er­a­ture:

1. The critic gets to cheat. During train­ing, the value net­work sees ground truth the real drone will never have, like which mo­tors are dead, the ex­act thrust con­stants, and true ve­loc­ity. The ac­tor only sees what real sen­sors pro­vide. The critic gets thrown away af­ter train­ing, so this costs noth­ing at de­ploy­ment. (This is called asym­met­ric ac­tor-critic[2], and I’ve read that it makes a huge dif­fer­ence when the physics are ran­dom­ized this hard.)

2. No fault de­tec­tor (for now). The pol­icy sees its last 5 ob­ser­va­tion/​ac­tion frames and has to fig­ure out fail­ures on its own, from the gap be­tween what it com­manded and what the drone did.

Under a same-type dual fail­ure the drone phys­i­cally can­not hold its head­ing — the torques don’t bal­ance at any throt­tle com­bi­na­tion. The right be­hav­ior is to give up on yaw, spin slowly about ver­ti­cal, and stay level. If the re­ward pun­ishes spin­ning, the pol­icy sac­ri­fices roll and pitch chas­ing a head­ing it can’t have. Mueller & D’Andrea showed the same thing for quads los­ing a mo­tor[3] — their re­cov­er­ing quad spins the whole time. Mine will too, on pur­pose.

Deployment

If the pol­icy shows promis­ing sur­vival rates in sim, it’ll get ex­ported to ONNX and run on the RPi 4 (I think. Any opin­ions on this vs other mi­cro­con­troller op­tions?) the net­work is ~45k pa­ra­me­ters, which is un­der a mil­lisec­ond of in­fer­ence, so the Pi is not the bot­tle­neck. The 50 Hz loop will read at­ti­tude and gyro over se­r­ial, run the pol­icy, and write 8 mo­tor com­mands.

Then, the ac­tual ex­per­i­ment: fly, kill mo­tors from the trans­mit­ter, and find out if mil­lions of sim­u­lated crashes taught it any­thing!

J. Schulman, F. Wolski, P. Dhariwal, A. Radford, and O. Klimov, “Proximal Policy Optimization Algorithms,” arXiv:1707.06347, 2017.

L. Pinto, M. Andrychowicz, P. Welinder, W. Zaremba, and P. Abbeel, “Asymmetric Actor Critic for Image-Based Robot Learning,” RSS, 2018.

M. W. Mueller and R. D’Andrea, “Stability and con­trol of a quadro­copter de­spite the com­plete loss of one, two, or three pro­pellers,” IEEE ICRA, 2014.

J. Tobin, R. Fong, A. Ray, J. Schneider, W. Zaremba, and P. Abbeel, “Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World,” IROS, 2017.