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

Redeploying Fable 5

Fable 5 re­turns glob­ally July 1. We’re also propos­ing an in­dus­try-wide frame­work for scor­ing jail­break sever­ity, to­gether with Amazon, Microsoft, Google, and other Glasswing part­ners.

Read more

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

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.

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).

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.

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

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.

Create more for less with Nano Banana 2 Lite. Generate and edit im­ages faster and more ef­fi­ciently than ever be­fore.

Capabilities

Hands-on

Comparisons

Showcase

Performance

Safety

Try Nano Banana 2 Lite

Lightning-fast la­tency

Explore, it­er­ate, and keep your work­flow mov­ing with dra­mat­i­cally re­duced la­tency.

Cost-efficient at scale

Generate thou­sands of im­ages at a frac­tion of the cost of heav­ier pro­duc­tion mod­els.

No com­pro­mise on qual­ity

The con­trol and ac­cu­racy you ex­pect from Nano Banana, ac­cel­er­ated. Maintain char­ac­ter con­sis­tency, edit vi­su­als with pre­ci­sion, and lean on real-world knowl­edge.

Slide 1 of 4

Space Lift

Space Lift is an in­te­rior de­sign app that lets you in­stantly reimag­ine any room. Upload an im­age of your space, and watch the app gen­er­ate a va­ri­ety of fully re­al­ized con­cepts, from Mid-Century Modern to Bohemian Chic. Swipe through each cus­tom card to find the per­fect de­sign scheme for your home.

Gridscape

Gridscape’s in­fi­nite can­vas lets you ex­plore and learn about any topic. When you ask a ques­tion, an in­for­ma­tional “node” maps out ideas us­ing text and im­ages gen­er­ated with Nano Banana 2 Lite and Gemini 3.1 Flash Lite. Dive deeper us­ing click­able path­ways that ex­plore re­lated con­cepts.

Peek-A-Word

Transforming pas­sive read­ing into an in­ter­ac­tive learn­ing jour­ney, Peek-A-Word turns se­lected text into AI-generated vi­su­als. Concise de­f­i­n­i­tions and con­tex­tual im­agery are gen­er­ated in one space, with­out any dis­tract­ing tab-switch­ing to dis­turb flow of learn­ing with Nano Banana 2 Lite and Gemini 3.1 Flash Lite.

Anywhere

Be trans­ported to dream des­ti­na­tions across the world with Anywhere, an in­ter­ac­tive 3D globe cre­ated with Nano Banana 2 Lite. Attach an im­age to gen­er­ate a se­ries of per­son­al­ized post­cards at iconic global land­marks. Spin the globe, click on any photo, and un­cover fas­ci­nat­ing travel facts about your vir­tual va­ca­tion spots.

Slide 1 of 5

“Nano Banana 2 Lite is fast and re­li­able, help­ing de­sign­ers ex­plore more ideas to craft unique im­ages on Figma Weave’s node-based can­vas. It’s ideal for rapid it­er­a­tion while stay­ing in the cre­ative flow.”

Itay SchiffCo-founder & Creative Director, Figma Weave

“We have been test­ing Nano Banana 2 Lite to power real-time im­age gen­er­a­tion within Manus’s au­tonomous work­flows—from slide decks to web pages. Its speed suits these sce­nar­ios well, al­low­ing our AI Agent to it­er­ate on vi­su­als quickly and de­liver re­sults in sec­onds. The im­age qual­ity is also im­pres­sive, com­ing close to the full Nano Banana 2. We look for­ward to con­tin­u­ing our part­ner­ship and build­ing bet­ter ex­pe­ri­ences to­gether.”

Tao ZhangCo-Founder & Chief Product Officer, Manus AI

“Speed is no longer a lim­i­ta­tion. When gen­er­a­tion is faster than imag­i­na­tion, cre­ators can stay in­side the idea in­stead of wait­ing on the tool. Nano Banana 2 Lite brings that feel­ing into the cre­ative process, let­ting thoughts move into vi­su­als al­most in­stantly. For Artlist’s users, it means less time star­ing at a progress bar and more time cre­at­ing, it­er­at­ing, per­son­al­iz­ing, and mov­ing at the speed of cul­ture.”

Idan Yonas Director of AI Content & Innovation, Artlist

“For our voice-con­trolled TV game Wit’s End, [instant-ramen] de­liv­ers con­sis­tent, high-qual­ity 1k im­ages ~2.7× faster than Gemini 3.1 Flash Image with in­cred­i­bly tight la­tency vari­ance. Its abil­ity to han­dle text-to-im­age, ed­its, and multi-im­age com­po­si­tion in one drop-in API gives us Flash-Lite speed and cost with Nano-Banana qual­ity. It’s what makes real-time gen­er­a­tive play vi­able at scale.”

Max ChildCEO, Weekend

“Our en­gine gen­er­ates the world as play­ers ex­plore it, so im­age speed gen­er­a­tion is es­sen­tial. Instant-ramen is a huge up­grade, en­abling ac­cu­rate vi­su­als, while do­ing it quick enough to keep up with the play­er’s ex­pe­ri­ence. Instant-ramen’s speed and fi­delity make on-the-fly art gen­er­a­tion some­thing we can use to power liv­ing vi­sual worlds.”

Nick WaltonCEO & Co-Founder, Latitude

Slide 1 of 4

Image Editing

Image edit­ing Elo scores against com­peti­tors per arena.ai

Image Generation

Image gen­er­a­tion Elo scores against com­peti­tors per arena.ai

Price per 1k res­o­lu­tion im­age

Creating your prompts

Use de­tailed prompts to take more con­trol over the im­ages you gen­er­ate. Think about what you want to see — the char­ac­ters, the set­ting, and the over­all feel. The more de­tail you add, the closer the im­age will be to what you’ve imag­ined.

Visual and text fi­delity

Not every im­age Gemini gen­er­ates will be per­fect — it can still strug­gle with small faces, ac­cu­rate spelling, and fine de­tails in im­ages.

Data and fac­tual ac­cu­racy

The mod­el’s real-world knowl­edge is ex­ten­sive but not in­fal­li­ble. When gen­er­at­ing in­fo­graph­ics, an­no­tat­ing di­a­grams, or rep­re­sent­ing com­plex data, it may mis­in­ter­pret in­for­ma­tion or pro­duce fac­tu­ally in­cor­rect re­sults. Always ver­ify data-dri­ven out­puts.

Translation and lo­cal­iza­tion

The model is ca­pa­ble of gen­er­at­ing and trans­lat­ing text in many lan­guages, but it may strug­gle with gram­mar, spelling, cul­tural nu­ances, or id­iomatic phrases.

Complex ed­its and im­age blend­ing

Advanced fea­tures like masked edit­ing, ma­jor light­ing changes (like day to night), or blend­ing mul­ti­ple im­ages may some­times pro­duce un­nat­ural re­sults, vi­sual ar­ti­facts, or dis­jointed scenes.

Character fea­tures

The model ex­cels at char­ac­ter con­sis­tency, but it may not al­ways get it right. We’re work­ing to make this con­sis­tency even more re­li­able.

Gemini

Supercharge your cre­ativ­ity and pro­duc­tiv­ity

Google AI Studio

The fastest path from prompt to pro­duc­tion

Gemini API

Get started build­ing with cut­ting-edge AI mod­els

Gemini Enterprise Agent Platform

Build, scale, and gov­ern agents

Large Language Models (LLMs), such as Gemini 3.1 Flash-Lite Image, may some­times pro­vide in­ac­cu­rate or of­fen­sive con­tent that does­n’t rep­re­sent Google’s views.

Use dis­cre­tion be­fore re­ly­ing on, pub­lish­ing, or oth­er­wise us­ing con­tent pro­vided by LLMs.

Don’t rely on LLMs for med­ical, le­gal, fi­nan­cial, or other pro­fes­sional ad­vice. Any con­tent re­gard­ing those top­ics is pro­vided for in­for­ma­tional pur­poses only and is not a sub­sti­tute for ad­vice from a qual­i­fied pro­fes­sional.

You only ever know the things you can lose to.

FILED 2026 – 06-26

WORDS 773

READ 4 MIN

BY CYRUS LOPEZ

To play a com­puter game in in the 1990s, you first had to un­der­stand how the com­puter worked.

So you learned. You opened files like au­toexec.bat and you read them. Sometimes you built a boot disk for a sin­gle game. A floppy whose en­tire rea­son to ex­ist was to start the com­puter in the con­fig­u­ra­tion that one pro­gram de­manded.

A ten year old did this. I did this. You did it be­cause you wanted to play badly enough, and the ma­chine would not let you play un­til you had learned a lit­tle of how it worked. That was the arrange­ment. The ma­chine had terms!

Everything had terms then. The mo­dem sang its ne­go­ti­a­tion out loud, and that shriek was two ma­chines ar­gu­ing about how to speak to each other, and af­ter enough times you could hear when the ar­gu­ment was go­ing south and the call was about to drop. You set lit­tle jumpers on dri­ves with your fin­ger­nail. You knew which in­ter­rupt your sound card an­swered to, be­cause if you guessed wrong it an­swered to noth­ing. The ma­chine was made of edges and you cut your­self on them, and that is how you found out where they were.

This might sound like I’m com­plain­ing, but I’m not.

The dif­fi­culty was the knowl­edge. You came to know that ma­chine the way you come to know any­thing that pushes back. The re­sis­tance was the whole medium. You only ever know the things that you can lose to.

Which is what makes the ma­chines and ser­vices we are build­ing now so strange, and so easy to mis­take for an old story about con­ve­nience.

We de­scribe it as the last con­ve­nience, the AI as­sis­tant, the thing that fi­nally sands off the fric­tion. And it does. You say what you want and it ap­pears. It never makes you read a con­fig file. It never sets terms. It re­arranges it­self around your sen­tence, says sorry when you frown, and tries again. It is the most ac­com­mo­dat­ing thing any­one has ever built.

And a ma­chine that can­not chal­lenge you is a thing you can­not know. You can only use it.

Some of us keep telling the story of this mo­ment as a loss of com­pe­tence. The gray­beards are ag­ing out, no­body com­piles their ker­nel any­more, and some­day some­thing deep will break and there will be no one left who can climb down and fix it. Maybe. But I think com­pe­tence is the part that’s fine. The knowl­edge is not in dan­ger, in fact, it has never been safer. The AI mod­els have read every man­ual that no hu­man reads. They will re­cite, flaw­lessly and for­ever, ex­actly how all ma­chines work. If this were only about com­pe­tence, it would be the most se­cure mo­ment in the his­tory of com­put­ing.

What is dy­ing is ac­quain­tance. The plain, unglam­orous in­ti­macy of hav­ing fought a par­tic­u­lar ma­chine, and lost, and gone back, and fi­nally felt the thing give. We are about to lean on these ma­chines harder than we have ever leaned on any tool, and we are go­ing to know them less well than I knew a beige com­puter in 1995 that would­n’t run a game un­til I had re­arranged its bits by hand. More de­pen­dent than ever. Less ac­quainted than ever. Both at once, and for the same rea­son.

The kids com­ing up will not feel this as a loss, and they are not wrong not to. You can­not miss a re­la­tion­ship you never had. They will have a tool that does every­thing and asks for noth­ing, and they will be as easy with it as you are with the light switch you never once thought about. There is noth­ing sad in their ease. The grief is en­tirely ours. We hap­pen to be the last peo­ple who knew a ma­chine the only way a ma­chine was ever re­ally known: by hav­ing it be dif­fi­cult. And we are also the last peo­ple who will know that any­thing is gone.

I went look­ing the other night for a record­ing of a mo­dem con­nect­ing. People keep them around like pressed flow­ers. I played one back for no rea­son ex­cept to hear it. The dial tones, the hiss, the rush of sta­tic, and then the sud­den hush when the two ma­chines fi­nally agreed on some­thing. My mod­ern com­puter played it in­stantly and per­fectly. Without ef­fort, the way it does every­thing now.

I know that sound by heart. People will never know the ma­chine that just played the sound back to me. Not the way I knew the one that used to make it.

It does­n’t need me to. That’s what we built. That’s what we wanted.