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

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.

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

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.

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

Godot has been suf­fer­ing from a slop prob­lem. In February, the main­tain­ers of the open source game en­gine, which pow­ers games like Slay the Spire 2 and The Case of the Golden Idol, said they were de­lib­er­at­ing how to ad­dress a ris­ing tide of AI slop pull re­quests, which had be­come “increasingly drain­ing and de­mor­al­iz­ing” for the pro­jec­t’s code re­view­ers.

Today, af­ter months of dis­cus­sion, the Godot Foundation and its main­tain­ers are draw­ing a line in the sand. In a blog post, the Foundation an­nounced that Godot’s guide­lines for con­trib­u­tors will soon be amended to for­bid AI-authored code, pull re­quests sub­mit­ted by AI agents, and AI-generated text in hu­man-to-hu­man com­mu­ni­ca­tion.

“It is time for us to rec­og­nize that these prob­lems aren’t go­ing away and there­fore we need to take steps to re­duce the bur­den on main­tain­ers while en­sur­ing we still have a pipeline to men­tor new con­trib­u­tors to be­come fu­ture main­tain­ers,” the Godot Foundation said.

The Foundation says the pileup of Godot pull re­quests pend­ing re­view is­n’t all bad: It’s a sign that in­ter­est in us­ing and con­tri­bu­tion to Godot is in­creas­ing. But the in­flux of con­tri­bu­tions au­thored or sub­mit­ted by AI is sap­ping the pro­jects’ main­tain­ers of their will­ing­ness to con­front the “already te­dious” work of re­view­ing pull re­quests.

“If your feed­back on PRs is just be­ing ab­sorbed by a ma­chine and not go­ing to­wards men­tor­ing a po­ten­tial fu­ture main­tainer, it be­comes much harder to jus­tify spend­ing your free time on PR re­view,” the Foundation said.

As the prob­lem be­comes in­creas­ingly un­sus­tain­able, the Godot Foundation says it’s in the process of up­dat­ing its con­tri­bu­tion poli­cies, fo­cus­ing on “adding bar­ri­ers to low-ef­fort slop” con­tri­bu­tions, en­cour­ag­ing main­tain­ers to re­view code, de­vel­op­ing new con­trib­u­tors into fu­ture main­tain­ers, and cru­cially, re­quir­ing that all con­tri­bu­tions come from hu­mans who are ac­count­able for their code—and fix­ing it if it fails.

“AI can­not take re­spon­si­bil­ity, and we can’t trust heavy users of AI to un­der­stand their code enough to fix it,” the Foundation said.

Keep up to date with the most im­por­tant sto­ries and the best deals, as picked by the PC Gamer team.

The Foundation says we can ex­pect Godot’s con­tribut­ing pol­icy to soon in­clude ex­plicit re­jec­tions of AI-authored code, not­ing that con­trib­u­tors should only use AI as­sis­tance for “menial things” and must dis­close its use. Additionally, the Foundation will re­ject any AI-generated text in hu­man-to-hu­man com­mu­ni­ca­tions, say­ing it’s “a ba­sic prin­ci­ple of re­spect”—though it says ma­chine trans­la­tions “are still ac­cept­able” if the orig­i­nal text was hu­man-au­thored.

“Things change every day with re­spect to the cur­rent suite of AI tools avail­able,” the Foundation said. “We will con­tinue tak­ing a con­ser­v­a­tive ap­proach in our poli­cies to­wards them, but we will re-eval­u­ate as things evolve.”

Lincoln has been writ­ing about games for 12 years—un­less you in­clude the es­says about pro­ce­dural sto­ry­telling in Dwarf Fortress he con­vinced his col­lege pro­fes­sors to ac­cept. Leveraging the brain­worms from a youth spent in World of Warcraft to write for sites like Waypoint, Polygon, and Fanbyte, Lincoln spent three years free­lanc­ing for PC Gamer be­fore join­ing on as a full-time News Writer in 2024, bring­ing an ex­per­tise in Caves of Qud bird diplo­macy, get­ting sons killed in Crusader Kings, and hit­ting di­nosaurs with ham­mers in Monster Hunter.

What is KNOPPIX®?

KNOPPIX is a bootable Live sys­tem on CD, DVD or USB flash dri­ves, con­sist­ing of a rep­re­sen­ta­tive col­lec­tion of GNU/Linux soft­ware, au­to­matic hard­ware de­tec­tion, and sup­port for many graph­ics cards, sound cards, SCSI and USB de­vices and other pe­riph­er­als. KNOPPIX can be used as a pro­duc­tive Linux sys­tem for the desk­top, ed­u­ca­tional CD, res­cue sys­tem, or adapted and used as a plat­form for com­mer­cial soft­ware prod­uct demos. It is not nec­es­sary to in­stall any­thing on a hard disk. Due to on-the-fly de­com­pres­sion, the CD can have up to 2 GB of ex­e­cutable soft­ware in­stalled on it (over 9GB on the DVD “Maxi” edi­tion).

Linux 7.1 is now here, and of course with it comes an­other progress re­port. We’ve got M3 progress, Apple bugs, and more!

Welcome back Master Boot Record

When you long-press the power but­ton on your Mac to bring up the boot picker (or use the Startup Disk ap­pli­ca­tion), what you see listed as Asahi is not ac­tu­ally the par­ti­tion with the op­er­at­ing sys­tem on it. Apple’s boot tool­ing will only work with what it con­sid­ers to be a “valid” ma­cOS in­stal­la­tion in­side an APFS con­tainer. So that we can use Apple’s boot­loader and avoid need­ing users to run com­mands from Recovery every time they want to use Asahi, the Asahi Installer cre­ates a small APFS con­tainer (2.5 GB) with just enough of ma­cOS on it to con­vince Apple’s tools that it is a bootable in­stal­la­tion of ma­cOS with m1n1 as its ker­nel. This arrange­ment worked com­pletely un­changed from ma­cOS 12 to ma­cOS 26, and Apple even fixed a cou­ple of bugs in their tools that are only en­coun­tered when at­tempt­ing to boot raw bi­na­ries that are not a real XNU ker­nel.

Shortly af­ter the re­lease of the ma­cOS 27 Golden Gate de­vel­oper beta how­ever, we be­gan re­ceiv­ing re­ports that peo­ple were no longer able to boot into Linux on their ma­chines — the op­tion had sim­ply dis­ap­peared from both Startup Disk and the boot picker! Obviously this is quite con­cern­ing, and so we made in­ves­ti­gat­ing this a pri­or­ity.

Inspecting the disk us­ing disku­til re­vealed that all Asahi-related par­ti­tions were still pre­sent on the disk af­ter up­grad­ing to ma­cOS 27. No data loss was oc­cur­ring, which is a pos­i­tive sign. Additionally, Asahi was still bootable on the same ma­chine when us­ing the boot tool­ing from a sec­ond in­stall of ma­cOS 26.

chaos_princess be­gan in­spect­ing Apple’s own ma­cOS Installer and old streams from way back when we were first pok­ing at Apple’s boot tools. The ma­cOS Installer sets some APFS meta­data be­fore re­boot­ing the ma­chine, which fur­ther in­ves­ti­ga­tion re­vealed to be a flag that marks the vol­ume as bootable. Until ma­cOS 27, the boot tool­ing sim­ply ig­nored this flag en­tirely. After set­ting the flag man­u­ally on an Asahi APFS con­tainer, it be­comes avail­able in the ma­cOS 27 boot picker with no fur­ther changes.

Going for­ward, all new Asahi in­stalls will have this flag set au­to­mat­i­cally by the Asahi Installer. We’ve also added an in­staller mode that will fix ex­ist­ing in­stal­la­tions. If you’ve in­stalled the ma­cOS 27 de­vel­oper beta and can­not ac­cess your Asahi in­stall, please run the in­staller again and use the “Fix ma­cOS 27 boot picker com­pat­i­bil­ity” op­tion.

chaos_princess has also de­vel­oped a pro­gram that can be run from Linux to fix the is­sue. While we would even­tu­ally like to de­ploy this fix au­to­mat­i­cally, we need more test­ing data to con­firm that it is re­li­able and will not de­stroy any­ones’ filesys­tems. That’s where you come in. If you are will­ing to help us test this, clone this repo, then build and run it from Linux be­fore up­grad­ing to ma­cOS 27. If your Asahi vol­ume is still se­lec­table as a boot tar­get from ma­cOS, it has worked. Do be sure to let us know how it went by pop­ping in to one of our chan­nels on OFTC or Matrix, es­pe­cially if you run in to any is­sues.

Three bytes forc­ing shut­downs

ma­cOS 27 also brings firmware up­dates for all pe­riph­er­als with global firmware, in­clud­ing the SMC. One of the SMC’s myr­iad func­tions is bat­tery man­age­ment. Our Linux power sup­ply dri­ver talks to the SMC to get in­for­ma­tion such as charge state, volt­age, time un­til empty and bat­tery health. The dri­ver also uses the SMC’s firmware in­ter­face to con­fig­ure charge start and stop thresh­olds to pro­long the life of the bat­tery. ma­cOS 27’s SMC firmware changed one of the bat­tery man­age­ment in­ter­faces from re­turn­ing a 32-bit in­te­ger to re­turn­ing a sin­gle byte. This change con­fuses our dri­ver, which un­der cer­tain con­di­tions con­sid­ers the bat­tery as hav­ing failed and ini­ti­ates an emer­gency shut­down to pro­tect the sys­tem. We have al­ready patched this in the down­stream ker­nel; start­ing with ver­sion 7.0.12, the power sup­ply dri­ver can deal with both firmware ABIs.

On in­stalling be­tas

Bugs like these are an im­por­tant re­minder that de­vel­oper be­tas are just that, de­vel­oper be­tas. It is ill-ad­vised to in­stall them on pro­duc­tion ma­chines. The two is­sues we have had so far have luck­ily mi­nor, but that does­n’t mean that all fu­ture is­sues will be too. Global firmware up­dates are ef­fec­tively per­ma­nent too, and can only be rolled back with a DFU re­store of the ma­chine. Please re­frain from in­stalling de­vel­oper be­tas go­ing for­ward. We have sac­ri­fi­cial ma­chines we use to test these things on your be­half, there is no need to risk your own ex­pen­sive hard­ware and im­por­tant data.

The more things change…

Designing and val­i­dat­ing com­puter plat­forms and the ICs that go into them is ex­tremely ex­pen­sive and time con­sum­ing, so it makes very lit­tle sense to make changes to ex­ist­ing de­signs when they are not nec­es­sary. Early on in the pro­ject, we made a bet that Apple would agree and re­frain from mak­ing con­stant break­ing changes to ei­ther. Discounting a few of the larger SoC blocks like the GPU that are al­most re­quired to change every gen­er­a­tion, this bet has largely paid off.

Audio on an Apple Silicon lap­top in­volves a few dif­fer­ent ICs and SoC blocks. The de­facto in­dus­try stan­dard for au­dio ICs is I2S, an I2C-based bus op­ti­mised for au­dio data. Apple’s I2S con­troller has re­mained un­changed since M1. All of these au­dio ICs also need a sta­ble clock source, which must be con­fig­urable to ac­com­mo­date the wide va­ri­ety of au­dio data rates. Apple’s Numerically Controlled Oscillator (NCO) has also re­mained un­changed since M1. Apple have also used the ex­act same speaker and head­set am­pli­fier chips in al­most all Apple Silicon ma­chines. So, when chaos_princess started adding speaker and head­phone jack sup­port to M3 ma­chines, lit­tle more was re­quired than some triv­ial Devicetree ad­di­tions and con­fig files for asahi-au­dio and speak­er­safe­tyd. As such, M3 ma­chines now sport high-qual­ity au­dio out­put on Asahi Linux!

M3 ma­chines have also grown sup­port for both CPU fre­quency switch­ing and proper big.LIT­TLE task sched­ul­ing. Apple have not changed how CPU fre­quency switch­ing works since the base M2, mean­ing that all M3 and M3 Pro/Max/Ultra SoCs re­quired noth­ing more than Devicetree changes to work with our ex­ist­ing cpufreq dri­ver. Tasks should now be more in­tel­li­gently placed on ei­ther ef­fi­ciency or per­for­mance cores ac­cord­ing to their re­quire­ments, and the CPU cores them­selves should clock up and down based on load. This will both save en­ergy and im­prove per­for­mance!

Adding sup­port for the SMC’s hard­ware sen­sors was sim­i­larly triv­ial; the SMC’s firmware is not ma­te­ri­ally dif­fer­ent across ma­chines, so once again noth­ing more than a few Devicetree changes was re­quired here.

On top of the above, we also have PCIe, WiFi, Bluetooth, NVMe, key­board, track­pad, and other core SoC block dri­vers work­ing in Linux for M3 se­ries ma­chines. Most of this work has come by way of Yureka, who has been very busy hack­ing on both m1n1 and Linux with her M3 se­ries ma­chines for a while now. We still have a ways to go be­fore we can start en­abling Asahi Installer sup­port for these ma­chines, but progress is rapid so watch this space!

We’re writ­ing firmware now?

Most of the com­pli­cated hard­ware on this plat­form uses com­pli­cated firmware blobs. Most of this is based on RTKit, an RTOS-like firmware frame­work used by Apple to pre­sent a mostly stan­dard­ised in­ter­face for the ker­nel to talk to the var­i­ous bits of hard­ware. There are ex­cep­tions to this, how­ever. Some blocks, like DCP and AOP, use RTKit as the ba­sis for their firmware, but layer yet an­other set of ab­strac­tions called EPIC on top of it. Others still, like the Broadcom WiFi/Bluetooth chipset, use third-party firmware that Apple has no di­rect con­trol over. Then, there’s the Apple Video Decoder (AVD).

AVD is spe­cial. Its firmware is nei­ther RTKit nor EPIC, it’s a se­cret third thing. The hard­ware it­self is es­sen­tially an ARM Cortex-M3 con­trol­ling a se­ries of fixed-func­tion hard­ware units for de­cod­ing video frames en­coded in AVC (H.264), HEVC (H.265), VP9, and AV1 on more re­cent SoCs. The CM3 runs a blob of firmware that ex­poses an in­ter­face for XNU to point it to video data, and then pro­grams the ac­tual de­coder hard­ware it­self. This would nor­mally be fine, how­ever Apple made the in­ter­est­ing choice of bundling both the AVD’s firmware and a pile of con­fig­u­ra­tion data in­side the AVD kext. Making mat­ters worse, each SoC has a slightly dif­fer­ent AVD vari­ant. This is lo­gis­ti­cally chal­leng­ing, as the Asahi Installer would have to con­stantly be up­dated with (and keep track of) Apple’s changes to the off­sets of the firmware data in the kext. We could do this, but what if there’s a bet­ter way?

The firmware loaded by XNU is not ver­i­fied by the CM3. It will be­gin ex­e­cut­ing from its re­set vec­tor when sig­nalled, no mat­ter what is ac­tu­ally there. What if we just… used our own firmware?

Since the firmware is ef­fec­tively just there to ab­stract away the un­der­ly­ing video de­coder hard­ware, it does­n’t ac­tu­ally mat­ter what it does, so long as it in­stalls in­ter­rupt han­dlers for the var­i­ous hard­ware blocks. If we un­der­stand what the un­der­ly­ing hard­ware ex­pects, we can just pro­gram it all from a Linux dri­ver. To do this, we need to un­der­stand how the firmware dri­ves each de­coder.

Being stan­dard Cortex-M3 code, it is pos­si­ble to run the AVD firmware in an em­u­la­tor. A num­ber of so­lu­tions ex­ist to do this, in­clud­ing QEMU, which al­lows you to sin­gle-step your pro­gram and in­spect bus and reg­is­ter op­er­a­tions. The ground­work for this was laid many years ago by Jamie, R and Eileen, who through a com­bined ef­fort man­aged to re­verse en­gi­neer the in­struc­tions and data for­mats re­quired by the AVC and VP9 de­coders.

The XNU kext also ap­plies a unique set of tun­ables to each AVD re­vi­sion. We are not en­tirely cer­tain what these do, so ap­ply­ing these es­sen­tially needs to be a re­play of MMIO writes made by XNU. We need to keep track of each AVD re­vi­sion, each set of tun­ables, and which re­vi­sion they need to be ap­plied to. This would be im­pos­si­ble to main­tain sat­is­fac­to­rily in an up­stream Linux ker­nel dri­ver, so this should also prob­a­bly live in firmware.

While not much work hap­pened on this front for a long time, new con­trib­u­tor so­fus re­cently stepped up to fill the gap. With a blob of cus­tom AVD firmware that sim­ply in­stalls in­ter­rupt han­dlers and ap­plies each vari­ant’s set of tun­ables, he was able to write a work­ing V4L2 dri­ver for the AVC hard­ware! The hard­ware can de­code 10-bit AVC-encoded video up to 4K, and works well with soft­ware that im­ple­ments the V4L2 Request API. Keeping the firmware ba­sic and state­less, with user­space and the ker­nel be­ing re­spon­si­ble for pars­ing all video data and pro­gram­ming the de­coders them­selves, also en­ables us to more eas­ily sup­port other video ac­cel­er­a­tion APIs like VA-API and Vulkan Video at some point in the fu­ture.

There’s still some work to do be­fore we can ship AVD sup­port to users. AVD sup­ports VP9, HEVC and even AV1 on some SoCs, but we have not im­ple­mented sup­port for any of these yet. Some de­vices also have quirks that must be tested and ac­counted for in the dri­ver. We hope to have some­thing ship­pable for you all in the not too dis­tant fu­ture!

A large m1n1 re­lease

We have also re­cently tagged ver­sion 1.6.0 of m1n1. This is a con­se­quen­tial re­lease for dis­tros, as it is the first ver­sion that re­quires Rust for stage 2 builds. Previously, m1n1 only made use of Rust when built with chain­load­ing sup­port. Stage 1 m1n1 re­places the XNU ker­nel in Apple’s boot tool­ing, and is used only to mount the EFI System Partition and chain­load Stage 2 m1n1 from there. A lit­tle while ago how­ever, we made the de­ci­sion to move GPU ini­tial­i­sa­tion into m1n1. This re­moved the need for the ker­nel dri­ver to deal with the float­ing point num­bers found in Apple’s hard­ware ini­tial­i­sa­tion data, and also greatly sim­pli­fied the Devicetree bind­ings. The ver­sion of the GPU dri­ver we even­tu­ally sub­mit to the Linux Kernel Mailing List will there­fore rely on m1n1 to do this ini­tial­i­sa­tion for it. We also ported the Apple Device Tree pars­ing code to Rust, which is con­sumed by just about every other part of m1n1.

Given that m1n1 is ef­fec­tively firmware, it uses no_std Rust and tar­gets aarch64-none-soft­float. To avoid pulling in su­per­flu­ous de­pen­den­cies, you can pass BUILDSTD=1 to make to build core and al­loc with­out re­quir­ing a full soft­float tool­chain to be in­stalled.

Version 1.6.0 also brings a whole host of im­prove­ments to M3 se­ries sup­port, in­clud­ing sup­port for the SPMI con­troller and PCIe ini­tial­i­sa­tion. We also now sup­port tun­nelling the SoC’s hard­ware UART di­rectly over DebugUSB with kisd, which can be used to achieve much the same func­tion­al­ity as the Central Scrutiniser. Much of this work is also cour­tesy of Yureka.

We are also lay­ing the ground­work for M4 and A18 Pro (MacBook Neo) sup­port, with bet­ter han­dling of Apple’s non-ma­cOS boot mode and sup­port for new power do­main meta­data found in the Apple Device Tree.

Thanks again!

As al­ways, we would like to thank our gen­er­ous sup­port­ers on GitHub Sponsors and Open Collective, with­out whom we would not be able to con­tinue work­ing on un­fin­ished M1 and M2 fea­tures or work on M3, M4 and A18 Pro sup­port while sup­port­ing our en­thu­si­as­tic new con­trib­u­tors!

James Calligeros · 2026 – 06-30

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.