Here are three sto­ries about the state of gam­bling in America.

In November 2025, two pitch­ers for the Cleveland Guardians, Emmanuel Clase and Luis Ortiz, were charged in a con­spir­acy for “rigging pitches.” Frankly, I had never heard of rigged pitches be­fore, but the fed­eral in­dict­ment de­scribes a scheme so sim­ple that it’s a mir­a­cle that this sort of thing does­n’t hap­pen all the time. Three years ago, a few cor­rupt bet­tors ap­proached the pitch­ers with a tan­ta­liz­ing deal: (1) We’ll bet that cer­tain pitches will be balls; (2) you throw those pitches into the dirt; (3) we’ll win the bets and give you some money.

The plan worked. Why would­n’t it? There are hun­dreds of pitches thrown in a base­ball game, and no­body cares about one bad pitch. The bets were so de­vi­ously clever be­cause they of­fered enor­mous re­wards for bet­tors and only in­ci­den­tal in­con­ve­nience for play­ers and view­ers. Before their plan was snuffed out, the fraud­sters won $450,000 from pitches that not even the most ar­dent Cleveland base­ball fan would ever re­mem­ber the next day. Nobody watch­ing America’s pas­time could have guessed that they were wit­ness­ing a six-fig­ure fraud.

On the morn­ing of February 28th, some­one logged onto the pre­dic­tion mar­ket web­site Polymarket and made an un­usu­ally large bet. This bet was­n’t placed on a base­ball game. It was­n’t placed on any sport. This was a bet that the United States would bomb Iran on a spe­cific day, de­spite ex­tremely low odds of such a thing hap­pen­ing.

A few hours later, bombs landed in Iran. This one bet was part of a $553,000 pay­day for a user named “Magamyman.” And it was just one of dozens of sus­pi­cious, per­fectly-timed wa­gers, to­tal­ing mil­lions of dol­lars, placed in the hours be­fore a war be­gan.

It is al­most im­pos­si­ble to be­lieve that, who­ever Magamyman is, he did­n’t have in­side in­for­ma­tion from mem­bers of the ad­min­is­tra­tion. The term war prof­i­teer­ing typ­i­cally refers to arms deal­ers who get rich from war. But we now live in a world not only where on­line bet­tors stand to profit from war, but also where key de­ci­sion mak­ers in gov­ern­ment have the tan­ta­liz­ing op­tions to make hun­dreds of thou­sands of dol­lars by syn­chro­niz­ing mil­i­tary en­gage­ments with their gam­bling po­si­tion.

On March 10, sev­eral days into the Iran War, the jour­nal­ist Emanuel Fabian re­ported that a war­head launched from Iran struck a site out­side Jerusalem.

Meanwhile on Polymarket, users had placed bets on the pre­cise lo­ca­tion of mis­sile strikes on March 10. Fabian’s ar­ti­cle was there­fore poised to de­ter­mine pay­outs of $14 mil­lion in bet­ting. As The Atlantic’s Charlie Warzel re­ported, bet­tors en­cour­aged him to rewrite his story to pro­duce the out­come that they’d bet on. Others threat­ened to make his life “miserable.”

A clever dystopian nov­el­ist might con­ceive of a fu­ture where poorly paid jour­nal­ists for news wires are of­fered six-fig­ure deals to re­port fic­tions that cash out bets from on­line pre­dic­tion mar­kets. But just how fan­ci­ful is that sce­nario when we have good rea­son to be­lieve that jour­nal­ists are al­ready be­ing pres­sured, bul­lied, and threat­ened to pub­lish spe­cific sto­ries that align with multi-thou­sand dol­lar bets about the fu­ture?

Put it all to­gether: rigged pitches, rigged war bets, and at­tempts to rig wartime jour­nal­ism. Without con­text, each story would sound like a wacky con­spir­acy the­ory. But these are not con­spir­acy the­o­ries. These are things that have hap­pened. These are con­spir­a­cies—full stop.

“If you’re not para­noid, you’re not pay­ing at­ten­tion” has his­tor­i­cally been one of those bumper­stick­ers you find on the back of a car with so many other bumper­stick­ers that you worry for the san­ity of its oc­cu­pants. But in this weird new re­al­ity where every event on the planet has a price, and be­hind every price is a shad­owy coun­ter­party, the jit­tery gam­bler’s para­noia—is what I’m watch­ing hap­pen­ing be­cause some­body more pow­er­ful than me bet on it?—is start­ing to seem, eerily, like a kind of per­verse com­mon sense.

What’s re­mark­able is not just the fact that on­line sports books have taken over sports, or that bet­ting mar­kets have metas­ta­sized in pol­i­tics and cul­ture, but the speed with which both have taken place.

For most of the last cen­tury, the ma­jor sports leagues were ve­he­mently against gam­bling, as the Atlantic staff writer McKay Coppins ex­plained in his re­cent fea­ture. In 1992, NFL com­mis­sioner Paul Tagliabue told Congress that “nothing has done more to de­spoil the games Americans play and watch than wide­spread gam­bling on them.” In 2012, NBA com­mis­sioner David Stern loudly threat­ened New Jersey Gov. Chris Christie for sign­ing a bill to le­gal­ize sports bet­ting in the Garden State, re­port­edly scream­ing, “we’re go­ing to come af­ter you with every­thing we’ve got.”

So much for that. Following the 2018 Supreme Court de­ci­sion Murphy vs. NCAA, sports gam­bling was un­leashed into the world, and the leagues haven’t looked back. Last year, the NFL saw $30 bil­lion gam­bled on foot­ball games, and the league it­self made half a bil­lion dol­lars in ad­ver­tis­ing, li­cens­ing, and data deals.

Nine years ago, Americans bet less than $5 bil­lion on sports. Last year, that num­ber rose to at least $160 bil­lion. Big num­bers mean noth­ing to me, so let me put that sta­tis­tic an­other way: $5 bil­lion is roughly the amount Americans spend an­nu­ally at coin-op­er­ated laun­dro­mats and $160 bil­lion is nearly what Americans spent last year on do­mes­tic air­line tick­ets. So, in a decade, the on­line sports gam­bling in­dus­try will have risen from the level of coin laun­dro­mats to ri­val the en­tire air­line in­dus­try.

And now here come the pre­dic­tion mar­kets, such as Polymarket and Kalshi, whose com­bined 2025 rev­enue came in around $50 bil­lion. “These pre­dic­tive mar­kets are the log­i­cal end­point of the on­line gam­bling boom,” Coppins told me on my pod­cast Plain English. “We have taught the en­tire American pop­u­la­tion how to gam­ble with sports. We’ve made it fric­tion­less and easy and put it on every­body’s phone. Why not ex­tend the logic and cul­ture of gam­bling to other seg­ments of American life?” He con­tin­ued:

Why not let peo­ple gam­ble on who’s go­ing to win the Oscar, when Taylor Swift’s wed­ding will be, how many peo­ple will be de­ported from the United States next year, when the Iranian regime will fall, whether a nu­clear weapon will be det­o­nated in the year 2026, or whether there will be a famine in Gaza? These are not things that I’m mak­ing up. These are all bets that you can make on these pre­dic­tive mar­kets.

Indeed, why not let peo­ple gam­ble on whether there will be a famine in Gaza? The mar­ket logic is cold and sim­ple: More bets means more in­for­ma­tion, and more in­for­ma­tional vol­ume is more ef­fi­ciency in the mar­ket­place of all fu­ture hap­pen­ings. But from an­other per­spec­tive—let’s call it, base­line moral­ity?—the trans­for­ma­tion of a famine into a wind­fall event for pre­scient bet­tors seems so grotesque as to re­quire no elab­o­ra­tion. One imag­ines a young man send­ing his 1099 doc­u­ments to a tax ac­coun­tant the fol­low­ing spring: “right, so here are my div­i­dends, these are the cap gains, and, oh yeah, here’s my $9,000 pay­out for to­tally nail­ing when all those kids would die.”

It is a com­fort­ing myth that dystopias hap­pen when ob­vi­ously bad ideas go too far. Comforting, be­cause it plays to our naive hope that the world can be di­vided into sta­tic cat­e­gories of good ver­sus evil and that once we stig­ma­tize all the bad peo­ple and ghet­toize all the bad ideas, some utopia will spring into view. But I think dystopias more likely hap­pen be­cause seem­ingly good ideas go too far. “Pleasure is bet­ter than pain” is a sen­si­ble no­tion, and a so­ci­ety de­voted to its im­pli­ca­tions cre­ated Brave New World. “Order is bet­ter than dis­or­der” sounds al­right to me, but a so­ci­ety de­voted to the most grotesque vi­sion of that prin­ci­ple takes us to 1984. Sports gam­bling is fun, and pre­dic­tion mar­kets can fore­cast fu­ture events. But ex­tended with­out guardrails or lim­i­ta­tions, those prin­ci­ples lead to a world where ubiq­ui­tous gam­bling leads to cheat­ing, cheat­ing leads to dis­trust, and dis­trust leads ul­ti­mately to cyn­i­cism or out­right dis­en­gage­ment.

“The cri­sis of au­thor­ity that has kind of al­ready vis­ited every other American in­sti­tu­tion in the last cou­ple of decades has ar­rived at pro­fes­sional sports,” Coppins said. Two-thirds of Americans now be­lieve that pro­fes­sional ath­letes some­times change their per­for­mance to in­flu­ence gam­bling out­comes. “Not to over­state it, but that’s a dis­as­ter,” he said. And not just for sports.

There are four rea­sons to worry about the ef­fect of gam­bling in sports and cul­ture.

The first is the risk to in­di­vid­ual bet­tors. Every time we cre­ate 1,000 new gam­blers, we cre­ate dozens of new ad­dicts and a hand­ful of new bank­rupt­cies. As I’ve re­ported, there is ev­i­dence that about one in five men un­der 25 is on the spec­trum of hav­ing a gam­bling prob­lem, and calls to the National Problem Gambling Helpline have roughly tripled since sports gam­bling was broadly le­gal­ized in 2018. Research from UCLA and USC found that bank­rupt­cies in­creased by 10 per­cent in states that le­gal­ized on­line sports bet­ting be­tween 2018 and 2023. People will some­times ask me what busi­ness I have wor­ry­ing about on­line gam­bling when peo­ple should be free to spend their money how­ever they like. My re­sponse is that wise rules place guardrails around eco­nomic ac­tiv­ity with a cer­tain rate of per­sonal harm. For al­co­hol, we have li­cens­ing re­quire­ments, min­i­mum drink­ing ages, bound­aries around hours of sale, and rules about pub­lic con­sump­tion. As al­co­hol con­sump­tion is de­clin­ing among young peo­ple, gam­bling is surg­ing; Gen Z has re­placed one (often fun) vice with a mean­ing­ful chance of ad­dic­tion with an­other (often fun) vice with a mean­ing­ful chance of ad­dic­tion. But whereas we have cen­turies of ex­pe­ri­ence cur­tail­ing ex­ces­sive drink­ing with rules and cus­toms, we are cur­rently in a free-for-all era of gam­bling.

The sec­ond risk is to in­di­vid­ual play­ers and prac­ti­tion­ers. One rea­son why sports com­mis­sion­ers might have wanted to keep gam­bling out of their busi­ness is that gam­blers turns some peo­ple into com­plete psy­chopaths, and that’s not a very nice ex­pe­ri­ence for folks on the re­ceiv­ing end of gam­bling-af­flicted psy­chopaths. In his fea­ture, McKay Coppins re­ports on the ex­pe­ri­ence of Caroline Garcia, a top-ranked ten­nis player, who said she re­ceived tor­rents of abu­sive mes­sages from gam­blers both for los­ing games and for win­ning games. “This has be­come a very com­mon ex­pe­ri­ence for ath­letes at the pro­fes­sional level, even at the col­lege level too,” Coppins said. As the ex­pe­ri­ence of jour­nal­ist Emanuel Fabian shows, gam­bling can turn or­di­nary peo­ple into mini mob bosses, who go around threat­en­ing play­ers and prac­ti­tion­ers who they be­lieve are cost­ing them thou­sands of dol­lars.

The third risk is to the in­tegrity of sports—or any other in­sti­tu­tion. At the end of 2025, in ad­di­tion to its in­dict­ment of the Cleveland Guardians pitch­ers, the FBI an­nounced 30 ar­rests in­volv­ing gam­bling schemes in the NBA. This cav­al­cade of ar­rests has dra­mat­i­cally re­duced trust in sports. Two-thirds of Americans now be­lieve that pro­fes­sional ath­letes change their per­for­mance to in­flu­ence gam­bling out­comes. It does not re­quire ex­tra­or­di­nary cre­ativ­ity to imag­ine how this prin­ci­ple could ex­tend to other do­mains and in­sti­tu­tions. If more peo­ple start to be­lieve that things only hap­pen in the world as a di­rect re­sult of shad­owy in­ter­ests in vast bet­ting mar­kets, it’s go­ing to be a per­ma­nent open sea­son for con­spir­acy the­o­ries.

The ul­ti­mate risk is al­most too dark to con­tem­plate in much de­tail. As the logic and cul­ture of casi­nos moves from sports to pol­i­tics, the scan­dals that have vis­ited base­ball and bas­ket­ball might soon ar­rive in pol­i­tics. Is it re­ally so un­be­liev­able that a politi­cian might tip off a friend, or as­suage an en­emy, by giv­ing them in­side in­for­ma­tion that would al­low them to profit on bet­ting mar­kets? Is it re­ally so in­cred­i­ble to be­lieve that a gov­ern­ment of­fi­cial would try to align pol­icy with a bet­ting po­si­tion that stood to earn them, or an al­lied group, hun­dreds of thou­sands of dol­lars? That is what a “rigged pitch” in pol­i­tics would look like. It’s not just wa­ger­ing on a pol­icy out­come that you sus­pect will hap­pen. It’s chang­ing pol­icy out­comes based on what can be wa­gered.

Gambling is flour­ish­ing be­cause it meets the needs of our mo­ment: a low-trust world, where lonely young peo­ple are seek­ing high-risk op­por­tu­ni­ties to launch them into wealth and com­fort. In such an en­vi­ron­ment, fi­nan­cial­iza­tion might seem to be the last form of civic par­tic­i­pa­tion that feels hon­est to a large por­tion of the coun­try. Voting is com­pro­mised, and polling is ma­nip­u­lated, and news is al­go­rith­mi­cally cu­rated. But a bet set­tles. A game ends. There is com­fort in that. In an un­cer­tain and il­leg­i­ble world, it does­n’t get much more cer­tain and leg­i­ble than this: You won, or you lost.

A 2023 Wall Street Journal poll found that Americans are pulling away from prac­ti­cally every value that once de­fined na­tional life—pa­tri­o­tism, re­li­gion, com­mu­nity, fam­ily. Young peo­ple care less than their par­ents about mar­riage, chil­dren, or faith. But na­ture, ab­hor­ring a vac­uum, is fill­ing the moral void left by re­treat­ing in­sti­tu­tions with the mar­ket. Money has be­come our fi­nal virtue.

I of­ten find my­self think­ing about the philoso­pher Alasdair MacIntyre, who ar­gued in the in­tro­duc­tion of After Virtue that moder­nity had de­stroyed the shared moral lan­guage once sup­plied by tra­di­tions and re­li­gion, leav­ing us with only the lan­guage of in­di­vid­ual pref­er­ence. Virtue did not dis­ap­pear, I think, so much as it died and was rein­car­nated as the mar­ket. It is now the mar­ket that tells us what things are worth, what events mat­ter, whose pre­dic­tions are cor­rect, who is win­ning, who counts. Money has, in a strange way, be­come the last moral ar­biter stand­ing—the fi­nal uni­ver­sal lan­guage that a plu­ral­is­tic, dis­trust­ful, post-in­sti­tu­tional so­ci­ety can use to com­mu­ni­cate with it­self.

As this moral vo­cab­u­lary scales across cul­ture, it also cor­rodes cul­ture. In sports, when you have money on a game, you’re not root­ing for a team. You’re root­ing for a propo­si­tion. The so­cial func­tion of fan­dom—shared iden­tity, in­her­ited loy­alty, some­thing larger than your­self—dis­solves into in­di­vid­ual risk. In pol­i­tics, I fear the con­se­quences will be worse. Prediction mar­kets can be use­ful for those who want to know the fu­ture, but their util­ity re­cruits par­tic­i­pants into a re­la­tion­ship with the news cy­cle that is ad­ver­sar­ial, and even mis­an­thropic. A young man bet­ting on a ter­ror­ist at­tack or a famine is not act­ing as a mere con­cerned cit­i­zen whose par­tic­i­pa­tion im­proves the ef­fi­ciency of global pre­dic­tion mar­kets. He’s just a dude, on his phone, alone in a room, choos­ing to root for death.

If that does­n’t bother you, I don’t know how to make it bother you. Based on eco­nomic and mar­ket ef­fi­ciency prin­ci­ples alone, this young man’s be­hav­ior is de­fen­si­ble. But there is moral­ity out­side of mar­kets. There is more to life than the ef­fi­ciency of in­for­ma­tion net­works. But will we re­dis­cover it, any time soon? Don’t bet on it.

It’s the end of an era: Apple has con­firmed to 9to5Mac that the Mac Pro is be­ing dis­con­tin­ued. It has been re­moved from Apple’s web­site as of Thursday af­ter­noon. The “buy” page on Apple’s web­site for the Mac Pro now redi­rects to the Mac’s home­page, where all ref­er­ences have been re­moved.

Apple has also con­firmed to 9to5Mac that it has no plans to of­fer fu­ture Mac Pro hard­ware.

The Mac Pro has lived many lives over the years. Apple re­leased the cur­rent Mac Pro in­dus­trial de­sign in 2019 along­side the Pro Display XDR (which was also dis­con­tin­ued ear­lier this month). That ver­sion of the Mac Pro was pow­ered by Intel, and Apple re­freshed it with the M2 Ultra chip in June 2023. It has gone with­out an up­date since then, lan­guish­ing at its $6,999 price point even as Apple de­buted the M3 Ultra chip in the Mac Studio last year.

With that in mind, the Mac Studio is clearly set up to be the ‘pro’ desk­top Mac of the fu­ture in Apple’s lineup. The Mac Studio can be con­fig­ured with the M3 Ultra chip and a 32-core CPU and an 80-core GPU, paired with 256GB of uni­fied mem­ory and 16TB of SSD stor­age.

With the dis­con­tin­u­a­tion of Mac Pro to­day, Apple now sells three desk­top Macs:

To me, this is the strongest Mac lineup in years, and per­haps the strongest Mac lineup ever. This is es­pe­cially true with the re­cent ad­di­tion of the MacBook Neo in the en­try-level spot. There are op­tions span­ning dra­mat­i­cally dif­fer­ent price points, con­fig­u­ra­tions, and form fac­tors.

Furthermore, with the re­lease of ma­cOS Tahoe 26.2 last year, Apple added a new low-la­tency fea­ture that lets you use RDMA over Thunderbolt 5 to con­nect mul­ti­ple Macs to­gether. This gives Mac users at the ul­tra-high-end of the mar­ket an­other way to scale per­for­mance. At the time, many spec­u­lated this fea­ture could be an­other nail in the Mac Pro’s cof­fin.

Ultimately, Apple needed to make a de­ci­sion to ei­ther up­date the Mac Pro or dis­con­tinue it. Continuing to sell it with the M2 Ultra at such a high price was a dis­ser­vice to Mac shop­pers. I think Apple made the right call by dis­con­tin­u­ing it and pri­or­i­tiz­ing the Mac Studio go­ing for­ward.

Of course, there will un­doubt­edly be some Mac Pro loy­al­ists dis­ap­pointed by to­day’s news. But the writ­ing has been on the wall for a while.

A. T.L.A.S achieves 74.6% LiveCodeBench pass@1-v(k=3) with a frozen 14B model on a sin­gle con­sumer GPU — up from 36-41% in V2 — through con­straint-dri­ven gen­er­a­tion and self-ver­i­fied it­er­a­tive re­fine­ment. The premise: wrap a frozen smaller model in in­tel­li­gent in­fra­struc­ture — struc­tured gen­er­a­tion, en­ergy-based ver­i­fi­ca­tion, self-ver­i­fied re­pair — and it can com­pete with fron­tier API mod­els at a frac­tion of the cost. No fine-tun­ing, no API calls, no cloud. Fully self-hosted — no data leaves the ma­chine, no API keys re­quired, no us­age me­ter­ing. One GPU, one box.

*pass@k-v(k=3) = one so­lu­tion sub­mit­ted per task, but gen­er­ated via best-of-3 can­di­dates + Lens se­lec­tion + it­er­a­tive re­pair on fail­ures. Not sin­gle-shot gen­er­a­tion, it is not pass@1. See method­ol­ogy.

A sin­gle patched llama-server runs on K3s, pro­vid­ing both gen­er­a­tion with spec­u­la­tive de­cod­ing (~100 tok/​s) and 5120-dim self-em­bed­dings for Lens scor­ing. The Geometric Lens C(x) en­ergy field se­lects the best can­di­date (87.8% ac­cu­racy on mixed-re­sult tasks). Failed tasks en­ter Phase 3, where the model gen­er­ates its own test cases and it­er­a­tively re­pairs so­lu­tions via PR-CoT — real tests are used only for fi­nal scor­ing.

Before you be­gin: ATLAS was de­vel­oped and tested on spe­cific hard­ware. Read the Hardware & Reproduction sec­tion be­low to check com­pat­i­bil­ity and tune vari­ables for your setup be­fore run­ning.

git clone https://​github.com/​it­igges22/​AT­LAS.git && cd ATLAS

cp at­las.conf.ex­am­ple at­las.conf # set MODEL_PATH, DATA_DIR, GPU de­vice

sudo ./scripts/install.sh

./scripts/verify-install.sh

# Run V3 bench­mark

python3 bench­mark/​v3_run­ner.py

V3 re­sults were pro­duced on RHEL 9 run­ning as a Proxmox VM with an RTX 5060 Ti 16GB passed through via VFIO. Other NVIDIA GPUs with 16GB+ VRAM should work, though you may need to ad­just dri­ver ver­sions and VRAM al­lo­ca­tion.

The pipeline is not yet plug-and-play on ar­bi­trary hard­ware — V3.1 will im­prove porta­bil­ity. That said, Claude Code can be used to retro­fit the pipeline to your spe­cific setup (different GPU, OS, VRAM bud­get).

Key vari­ables to tune for your hard­ware:

–parallel slots (default 2 — re­duce to 1 if VRAM is tight)

Full VRAM bud­get break­down is doc­u­mented in docs/​AR­CHI­TEC­TURE.md. Community re­pro­duc­tion at­tempts are wel­come — open an is­sue with your hard­ware con­fig and re­sults.

These are ac­tively be­ing ad­dressed in V3.1:

LCB-only op­ti­miza­tion. V3 phases were de­signed and tuned for LiveCodeBench. GPQA Diamond (47.0%) and SciCode (14.7%) re­sults are in­cluded but those bench­marks were not op­ti­mized for. Cross-domain gen­er­al­iza­tion is a V3.1 pri­or­ity.

Phase 2 (Geometric Lens rout­ing) con­tributed +0.0pp. C(x) was re­trained on self-em­bed­dings for V3 (fixing the V2 nomic em­bed­ding fail­ure), but the train­ing dataset was only ~60 sam­ples — far too small to learn a mean­ing­ful en­ergy land­scape. With an un­der­trained C(x), the Lens can­not dis­crim­i­nate can­di­dates dur­ing rout­ing. V3.1 re­trains C(x) on a prop­erly sized dataset drawn from real bench­mark prob­lems.

G(x) met­ric ten­sor is dor­mant. G(x) is down­stream of C(x): it ap­plies met­ric cor­rec­tions to C(x)’s gra­di­ent sig­nal. With C(x) un­der­trained and pro­duc­ing a weak/​noisy en­ergy land­scape, G(x) has no mean­ing­ful geom­e­try to nav­i­gate — the cor­rec­tion term Δx = -G⁻¹∇C con­tributes noth­ing. G(x) is cur­rently be­ing re­designed from the ground up; V3.1 will ei­ther ship a work­ing re­design or re­move it en­tirely pend­ing fur­ther re­search.

SandboxAdapter stdio bug. S* dis­tin­guish­ing in­put tiebreak­ing is im­ple­mented but non-func­tional on LCB tasks due to a stdio han­dling bug in the SandboxAdapter. Fixed in V3.1.

* Model swap: Qwen3-14B → Qwen3.5-9B with DeltaNet lin­ear at­ten­tion ar­chi­tec­ture. Native multi-to­ken pre­dic­tion (MTP) gives ~3-4x through­put im­prove­ment at com­pa­ra­ble or bet­ter ac­cu­racy. Smaller model also frees VRAM head­room.

* Lens Evolution: Online C(x) re­cal­i­bra­tion — Geometric Lens up­dates based on bench­mark feed­back rather than re­main­ing sta­tic af­ter ini­tial train­ing.

V3 was eval­u­ated only on LiveCodeBench v5. V3.1 ex­pands eval­u­a­tion to cover cod­ing, rea­son­ing, and gen­eral knowl­edge — be­cause ATLAS is not purely a cod­ing sys­tem. The Confidence Router al­lo­cates com­pute based on task dif­fi­culty: sim­ple knowl­edge ques­tions route to raw in­fer­ence + RAG (~30 sec­onds per re­sponse), while hard cod­ing prob­lems use the full V3 pipeline (PlanSearch + best-of-3 + PR-CoT re­pair), which can take up to 20 min­utes per task. The bench­mark suite should re­flect this full range.

GPQA Diamond — sci­en­tific rea­son­ing, run in V2 (47.0%), needs V3 re-eval­u­a­tion un­der full pipeline

AA-Omniscience — knowl­edge ac­cu­racy and hal­lu­ci­na­tion rate; im­por­tant for gen­eral-pur­pose use cases where users ask fac­tual ques­tions rather than cod­ing prob­lems

Humanity’s Last Exam — ex­treme rea­son­ing and knowl­edge, use­ful as a ceil­ing test

General knowl­edge bench­marks mat­ter be­cause ATLAS is de­signed as a gen­eral-pur­pose self-hosted AI sys­tem, not a cod­ing-only tool. The Confidence Router han­dles this by rout­ing knowl­edge queries di­rectly to raw in­fer­ence + RAG (~30s), while re­serv­ing the full pipeline for hard cod­ing prob­lems (~20min). Benchmarks like AA-Omniscience and Humanity’s Last Exam val­i­date the fast-path rout­ing, not the cod­ing pipeline.

None of these V3.1 bench­marks have been run yet. This sec­tion is for­ward-look­ing roadmap only.

Licensed un­der the A. T.L.A.S Source Available License v1.0 — see LICENSE.

A warn­ing about ris­ing prices, van­ish­ing con­sumer choice, and a fu­ture where own­ing a com­puter may mat­ter more than ever as hard­ware, power, and con­trol drift to­ward data cen­ters and away from peo­ple.

A warn­ing about ris­ing prices, van­ish­ing con­sumer choice, and a fu­ture where own­ing a com­puter may mat­ter more than ever as hard­ware, power, and con­trol drift to­ward data cen­ters and away from peo­ple.

For the bet­ter part of two decades, con­sumers lived in a golden age of tech. Memory got cheaper, stor­age in­creased in ca­pac­ity and hard­ware got faster and ab­surdly af­ford­able. Upgrades were rou­tine, al­most ca­sual. If you needed more RAM, a big­ger SSD, or a faster CPU or GPU, you barely had to wait a week for a dis­count of­fer and you moved on with your life. This era is end­ing.

What’s form­ing now is­n’t just an­other pric­ing cy­cle or a short-term short­age, it is a struc­tural shift in the hard­ware in­dus­try that paints a deeply grim out­look for con­sumers. Today, I am urg­ing you to hold on to your hard­ware, as you may not be able to re­place it af­ford­ably in the fu­ture. While I have al­ways been a stark critic of to­day’s con­sumer in­dus­try, as well as

the ideas be­hind it, and a strong pro­po­nent of buy­ing it for life

(meaning, in­vest­ing into durable, re­pairable, qual­ity prod­ucts) the in­dus­try’s shift has noth­ing to do with the pro­tec­tion of valu­able re­sources or the en­vi­ron­ment, but is in­stead a move to­wards a tra­jec­tory that has the po­ten­tial to erode tech­no­log­i­cal self-suf­fi­ciency and in­de­pen­dence for peo­ple all over the world.

In re­cent months the buzz­word RAM-pocalypse has started pop­ping up across tech jour­nal­ism and en­thu­si­ast cir­cles. It’s an in­ten­tion­ally dra­matic term that de­scribes the sharp in­crease in RAM prices, pri­mar­ily dri­ven by high de­mand from data cen­ters and “AI” tech­nol­ogy, which most peo­ple had con­sid­ered a mere

blip in the mar­ket. This pre­sumed tem­po­rary blip, how­ever, turned out to be a lot more than just that, with one man­u­fac­turer af­ter the other openly stat­ing that prices will con­tinue to rise, with sup­pli­ers fore­cast­ing short­ages of spe­cific com­po­nents that could last well be­yond 2028, and with key play­ers like

Western Digital and Micron ei­ther com­pletely dis­re­gard­ing or even ex­it­ing the con­sumer mar­ket al­to­gether.

The RAM-pocalypse is­n’t just a tem­po­rary head­line any­more, but has seem­ingly be­come long-term re­al­ity. However, RAM and mem­ory in gen­eral is only the be­gin­ning.

The main rea­son for the short­ages and hence the in­creased prices is data cen­ter de­mand, specif­i­cally from “AI” com­pa­nies. These data cen­ters re­quire mind-bog­gling amounts of hard­ware, specif­i­cally RAM, stor­age dri­ves and GPUs, which in turn are RAM-heavy graph­ics units for “AI” work­loads. The en­ter­prise de­mand for spe­cific com­po­nents sim­ply out­paces the cur­rent global pro­duc­tion ca­pac­ity, and out­bids the com­par­a­tively poor con­sumer mar­ket.

For ex­am­ple, OpenAI’s Stargate pro­ject alone re­port­edly

re­quires ap­prox­i­mately 900,000 DRAM wafers per month, which could ac­count for roughly 40% of cur­rent global DRAM out­put. Other big tech gi­ants in­clud­ing Google, Amazon, Microsoft, and Meta have placed open-ended or­ders with mem­ory sup­pli­ers, ac­cept­ing as much sup­ply as avail­able. The ex­ist­ing and fu­ture data cen­ters for/​of these com­pa­nies are ex­pected to con­sume 70% of all mem­ory chips pro­duced in 2026.

However, mem­ory is just the first domino.

RAM and SSDs are where the pain is most vis­i­ble to­day, but rest as­sured that the same forces are qui­etly re­shap­ing all as­pects of con­sumer hard­ware. One of the most im­me­di­ate and tan­gi­ble con­se­quences of this broader sup­ply-chain re­align­ment are sharp, cas­cad­ing price hikes across con­sumer elec­tron­ics, with

LPDDR mem­ory stand­ing out as an early pres­sure point that most con­sumers did­n’t rec­og­nize un­til it was al­ready un­avoid­able.

LPDDR is used in smart­phones, lap­tops, tablets, hand­held con­soles, routers, and in­creas­ingly even low-power PCs. It sits at the in­ter­sec­tion of con­sumer de­mand and en­ter­prise pri­or­i­ti­za­tion, mak­ing it uniquely vul­ner­a­ble when man­u­fac­tur­ers re­al­lo­cate ca­pac­ity to­ward “AI” ac­cel­er­a­tors, servers, and data-cen­ter-grade mem­ory, where mar­gins are higher and con­tracts are long-term. As fabs shift pro­duc­tion to­ward HBM and server DRAM, as well as GPU wafers, con­sumer hard­ware pro­duc­tion qui­etly be­comes non-es­sen­tial, tight­en­ing sup­ply just as de­vices be­come more power- and mem­ory-hun­gry, all while con­tin­u­ing on their path to re­main frus­trat­ingly un­ser­vice­able and un-upgrad­able.

The re­sult is a rip­ple ef­fect, in which de­vice mak­ers pay more for chips and mem­ory and pass those costs on through higher re­tail prices, cut base con­fig­u­ra­tions to pre­serve mar­gins, or lock fea­tures be­hind pre­mium tiers. At the same time, con­sumers lose the abil­ity to com­pen­sate by up­grad­ing later, be­cause most com­po­nents these days, like LPDDR, are sol­dered down by de­sign. This is fur­ther am­pli­fied by scarcity, as even mod­est sup­ply dis­rup­tions can spike prices dis­pro­por­tion­ately in a mar­ket where just a few sup­pli­ers dom­i­nate, turn­ing what should be in­cre­men­tal cost in­creases into sud­den jumps that af­fect en­tire prod­uct cat­e­gories at once.

In prac­tice, this means that phones, ul­tra­books, and em­bed­ded de­vices are be­com­ing more ex­pen­sive overnight, not be­cause of new fea­tures, but be­cause the in­vis­i­ble sil­i­con in­side them has qui­etly be­come a

con­tested re­source in a world that no longer builds hard­ware pri­mar­ily for con­sumers.

In late January 2026, the Western Digital CEO

con­firmed dur­ing an earn­ings call that the com­pa­ny’s en­tire HDD pro­duc­tion ca­pac­ity for cal­en­dar year 2026 is al­ready sold out. Let that sink in for a mo­ment. Q1 has­n’t even ended and a ma­jor hard drive man­u­fac­turer has

zero re­main­ing ca­pac­ity for the year. Firm pur­chase or­ders are in place with its top cus­tomers, and long-term agree­ments al­ready ex­tend into 2027 and 2028. Consumer rev­enue now ac­counts for just 5% of Western Digital’s to­tal sales, while cloud and en­ter­prise clients make up 89%. The com­pany has, for all prac­ti­cal pur­poses, stopped be­ing a con­sumer stor­age com­pany.

And Western Digital is not alone. Kioxia, one of the world’s largest NAND flash man­u­fac­tur­ers, ad­mit­ted that its en­tire 2026 pro­duc­tion vol­ume is

al­ready in a “sold out” state, with the com­pany ex­pect­ing tight sup­ply to per­sist through at least 2027 and long-term cus­tomers fac­ing 30% or higher year-on-year price in­creases. Adding to this, the Silicon Motion CEO put it bluntly dur­ing a re­cent earn­ings call:

We’re fac­ing what has never hap­pened be­fore: HDD, DRAM, HBM, NAND… all in se­vere short­age in 2026.

In ad­di­tion, the Phison CEO has gone even fur­ther, warn­ing that the NAND short­age could per­sist un­til 2030, and that it risks the

“destruction” of en­tire seg­ments of the con­sumer elec­tron­ics in­dus­try. He also noted that fac­to­ries are now de­mand­ing pre­pay­ment for ca­pac­ity three years in ad­vance, an un­prece­dented prac­tice that ef­fec­tively locks out smaller play­ers.

The col­lat­eral dam­age of this can al­ready be felt, and it’s sig­nif­i­cant. For ex­am­ple Valve con­firmed that the Steam Deck OLED is now out of stock in­ter­mit­tently in mul­ti­ple re­gions “due to mem­ory and stor­age short­ages”. All mod­els are cur­rently un­avail­able in the US and Canada, the cheaper LCD model has been dis­con­tin­ued en­tirely, and there is no time­line for when sup­ply will re­turn to nor­mal. Valve has also

been forced to de­lay the pric­ing and launch de­tails for its up­com­ing Steam Machine con­sole and Steam Frame VR head­set, di­rectly cit­ing mem­ory and stor­age short­ages.

At the same time, Sony is con­sid­er­ing de­lay­ing the PlayStation 6 to 2028 or even 2029, and Nintendo is re­port­edly

con­tem­plat­ing a price in­crease for the Switch 2, less than a year af­ter its launch. Both de­ci­sions are seem­ingly dri­ven by the same mem­ory sup­ply con­straints. Meanwhile, Microsoft has al­ready raised

prices on the Xbox.

Now you might think that every­thing so far is about GPUs and other gam­ing-re­lated hard­ware, but that could­n’t be fur­ther from the truth. General com­put­ing, like the Raspberry Pi is not im­mune to any of this ei­ther. The Raspberry Pi Foundation has been forced to raise prices twice in three months, with the flag­ship Raspberry Pi 5 (16GB) jump­ing from $120 at launch to $205 as of February 2026, a 70% in­crease dri­ven en­tirely by LPDDR4

mem­ory costs. What was once a sym­bol of af­ford­able com­put­ing is rapidly be­ing priced out of reach for the ed­u­ca­tional and hob­by­ist com­mu­ni­ties it was de­signed to serve.

HP, on the other hand, seems to have al­ready pre­pared for the hard­ware short­age by launch­ing a lap­top sub­scrip­tion ser­vice where you pay a monthly fee to use a lap­top but never own it, no mat­ter how long you sub­scribe. While HP frames this as a con­ve­nience, the tim­ing, right in the mid­dle of a hard­ware af­ford­abil­ity cri­sis, makes it feel a lot more like a pre­view of a rented com­pute fu­ture. But more on that in a sec­ond.

“But we’ve seen price spikes be­fore, due to crypto booms, pan­demic short­ages, fac­tory floods and fires!”, you might say. And while we did live through those crises, things even­tu­ally eased when bub­bles popped and mar­kets or sup­ply chains re­cov­ered. The cur­rent sit­u­a­tion, how­ever, does­n’t ap­pear to be go­ing away any­time soon, as it looks like the in­dus­try’s pri­or­i­ties have fun­da­men­tally

changed.

These days, the biggest cus­tomers are not gamers, cre­ators, PC builders or even crypto min­ers any­more. Today, it’s hy­per­scalers. Companies that use hard­ware for “AI” train­ing clus­ters, cloud providers, en­ter­prise data cen­ters, as well as gov­ern­ments and de­fense con­trac­tors. Compared to these hy­per­scalers

con­sumers are small fish in a big pond.

These buy­ers don’t care if RAM costs 20% more and nei­ther do they wait for

Black Friday deals. Instead, they sign con­tracts mea­sured in ex­abytes and bil­lions of dol­lars. With such clients lin­ing up, the con­sumer mar­ket in con­trast is sud­denly an in­con­ve­nience for man­u­fac­tur­ers. Why set­tle for smaller mar­gins and deal with higher mar­ket­ing and sup­port costs, frag­mented SKUs, price sen­si­tiv­ity and re­tail lo­gis­tics headaches, when you can have be­he­moths throw­ing money at you? Why sell a $100 SSD to one con­sumer, when you can sell a whole rack of en­ter­prise NVMe dri­ves to a data cen­ter with

vir­tu­ally in­fi­nite money?

All of this goes to show that the con­sumer mar­ket is not just de­pri­or­i­tized, but in­stead it is be­ing starved. In fact, IDC has al­ready warned

that the PC mar­ket could shrink by up to 9% in 2026 due to sky­rock­et­ing mem­ory prices, and has de­scribed the sit­u­a­tion not as a cycli­cal short­age but as “a po­ten­tially per­ma­nent, strate­gic re­al­lo­ca­tion of the world’s sil­i­con wafer ca­pac­ity”.

Leading PC OEMs in­clud­ing Lenovo, Dell, HP, Acer, and ASUS have all sig­naled 15-20% PC price in­creases for 2026, with some mod­els see­ing even steeper hikes. Framework, the re­pairable lap­top com­pany, has also been trans­par­ent about ris­ing mem­ory costs im­pact­ing its pric­ing. And an­a­lyst Jukan Choi re­cently re­vised his short­age time­line es­ti­mate, not­ing that DRAM pro­duc­tion ca­pac­ity is ex­pected to grow at just 4.8% an­nu­ally through 2030, with even that in­cre­men­tal ca­pac­ity con­cen­trated on HBM rather than con­sumer mem­ory. TrendForce’s lat­est fore­cast pro­jects DRAM con­tract prices ris­ing by 90-95% quar­ter over quar­ter in Q1 2026. And that is not a typo.

The price of hard­ware is one thing, but value-for-money is an­other as­pect that ap­pears to be only get­ting worse from here on. Already to­day con­sumer parts feel like cut-down ver­sions of en­ter­prise sil­i­con. As “AI” ac­cel­er­a­tors and server chips dom­i­nate R&D bud­gets, con­sumer im­prove­ments will slow even fur­ther, or ar­rive at higher prices jus­ti­fied as pre­mium fea­tures. This is true for CPUs and GPUs, and it will be equally true for moth­er­boards, chipsets, power sup­plies, net­work­ing, etc. We will likely see fewer low-end op­tions, more seg­men­ta­tion, ar­ti­fi­cial fea­ture gat­ing and gen­er­ally higher base­line prices that, once es­tab­lished, won’t be com­ing back down again.

As en­ter­prise stan­dards be­come the pri­or­ity, con­sumer gear is be­com­ing an af­ter­thought that is be­ing re­badged, over­priced, and poorly sup­ported. The un­com­fort­able truth is that the con­sumer hard­ware mar­ket is no longer the cen­ter of grav­ity, as we all were able to see at this year’s CES. It’s or­bit­ing some­thing much larger, and none of this is ac­ci­den­tal. The in­dus­try is­n’t fail­ing, it’s suc­ceed­ing, just not for you.

And to be fair, from a cor­po­rate stand­point, this pivot makes per­fect sense.

“AI” and en­ter­prise cus­tomers are rewrit­ing rev­enue charts, all while con­sumers con­tinue to be noisy, de­mand­ing, and com­par­a­tively poor. It is pretty clear that con­sumer hard­ware is be­com­ing a sec­ond-class cit­i­zen, which means that the ma­chines we al­ready own are more valu­able than we might be think­ing right now.

“But what does the in­dus­try think the fu­ture will look like if no­body can af­ford new hard­ware?”, you might be ask­ing.

There is a darker, con­spir­a­to­r­ial in­ter­pre­ta­tion of to­day’s hard­ware trends that reads less like mar­ket eco­nom­ics and more like a re­hearsal for a man­aged

fu­ture. Businesses, hav­ing dis­cov­ered that own­er­ship is in­ef­fi­cient and obe­di­ence is prof­itable, are qui­etly steer­ing so­ci­ety to­ward a world where no one owns com­pute at all, where hard­ware ex­ists only as an ab­strac­tion rented back to the pub­lic through vir­tual servers, SaaS sub­scrip­tions, and me­tered ex­pe­ri­ences, and where dig­i­tal sov­er­eignty, that any­one with a PC tower un­der their desk once had, be­comes an out­dated, ec­cen­tric, and even sus­pi­cious con­cept.

… a morn­ing in said fu­ture, where an or­di­nary cit­i­zen wakes up, taps their ter­mi­nal, which is a sealed de­vice with­out ports, stor­age, and so­phis­ti­cated lo­cal ex­e­cu­tion ca­pa­bil­i­ties, and logs into their Personal Compute Allocation. This bun­dle of cloud CPU min­utes, RAM cred­its, and stor­age to­kens leased from a con­glom­er­ate whose logo has qui­etly re­placed the word “computer” in every­day speech, just like “to search” has made way for “to google”, has re­moved the con­cept of in­stalling soft­ware, be­cause soft­ware no longer ex­ists as a thing, but only as a ser­vice tier in which every task routes through servers owned by en­ti­ties. Entities that in­sist that this is all for the planet. Entities that out­lawed con­sumer hard­ware years ago un­der the ban­ner of en­vi­ron­men­tal pro­tec­tion­ism, cit­ing e-waste sta­tis­tics, car­bon bud­gets, and un­safe un­reg­u­lated sil­i­con, while con­ve­niently ig­nor­ing that the data cen­ters

hum­ming be­yond the city lim­its burn more power in an hour than the old neigh­bor­hood ever did in a decade. In this world, the or­di­nary cit­i­zen re­mem­bers their par­ents’ dusty Personal Computer, locked away in a stor­age unit like con­tra­band. A ma­chine that once ran freely, of­fline if it wanted, im­mune to ar­bi­trary ac­count sus­pen­sions and pric­ing changes. As they go about their day, pay­ing a mi­cro-fee to open a doc­u­ment, los­ing ac­cess to their own pho­tos be­cause a sub­scrip­tion lapsed, watch­ing a warn­ing ban­ner ap­pear when they type some­thing that vi­o­lates the ever evolv­ing terms-of-ser­vice, and shout­ing “McDonald’s!” to skip the oth­er­wise un­skip­pable ads within every other app they open, they be­gin to un­der­stand that the true crime of con­sumer hard­ware was­n’t pri­mar­ily pol­lu­tion but in­de­pen­dence. They re­al­ize that own­ing a ma­chine meant own­ing the means of com­pu­ta­tion, and that by cen­tral­iz­ing hard­ware un­der the guise of ef­fi­ciency, safety, and sus­tain­abil­ity, so­ci­ety traded re­silience for con­ve­nience and au­ton­omy for com­fort.In this utopia, noth­ing ever breaks be­cause noth­ing is

yours, noth­ing is re­pairable be­cause noth­ing is phys­i­cal, and noth­ing is

pri­vate be­cause every­thing runs some­where else, on some­one else’s com­puter. The quiet moral, felt when the net­work briefly stut­ters and the world freezes, is that keep­ing old hard­ware alive was never nos­tal­gia or para­noia, but a small, stub­born act of dig­i­tal self-de­fense; A re­fusal to ac­cept that the fu­ture must be rented, per­mis­sioned, and re­vo­ca­ble at any mo­ment.

If you think that dystopian “rented com­pute over owned hard­ware” fu­ture could never hap­pen, think again. In fact, you’re al­ready likely rent­ing rather than own­ing in many dif­fer­ent ar­eas. Your means of

com­mu­ni­ca­tion are run by Meta, your mu­sic is pro­vided by Spotify, your movies are streamed from Netflix, your data is stored in Google’s data cen­ters and your of­fice suite runs on Microsoft’s cloud. Maybe even your car is leased in­stead of owned, and you pay a monthly pre­mium for seat heat­ing or sElF-dRi­ViNg, what­ever that means. After all, the av­er­age Gen Z and Millennial US con­sumer to­day ap­par­ently has 8.2 sub­scrip­tions, not in­clud­ing their DaIlY aV­o­CaDo ToAsTs and StArBuCkS cHoCo­Late ChIp LaTtEs that the same Boomers

re­spon­si­ble for the cur­rent (and past) eco­nomic crises love to dunk on.

Besides, look no fur­ther than what’s al­ready hap­pen­ing in for ex­am­ple China, a coun­try that man­u­fac­tures mas­sive amounts of the world’s sought-af­ter hard­ware yet faces re­stric­tions on buy­ing that very hard­ware. In re­cent years, a com­plex web of ex­port con­trols and chip bans has put a spot­light on how hard­ware can be­come a geopo­lit­i­cal bar­gain­ing chip rather than a con­sumer good. For ex­am­ple, ex­port con­trols im­posed by the United States in re­cent years barred Nvidia

from sell­ing many of its high-per­for­mance GPUs into China with­out spe­cial li­censes, sig­nif­i­cantly re­duc­ing le­gal ac­cess to cut­ting-edge com­pute in­side the coun­try.

Meanwhile, en­force­ment ef­forts have re­peat­edly busted smug­gling op­er­a­tions mov­ing pro­hib­ited Nvidia chips into Chinese ter­ri­tory through Southeast Asian hubs, with over $1 bil­lion worth of banned GPUs re­port­edly mov­ing through gray mar­kets, even as of­fi­cial chan­nels re­main re­stricted. Coverage by out­lets such as Bloomberg, as well as ac­tual in­ves­tiga­tive jour­nal­ism like

Gamer’s Nexus has doc­u­mented these black-mar­ket flows and the lengths to which both sides go to en­force or evade re­stric­tions, in­clud­ing smug­gling net­works and in­creased reg­u­la­tory scrutiny.

On top of this, Chinese reg­u­la­tors have at times re­stricted do­mes­tic tech firms from buy­ing spe­cific Nvidia mod­els, fur­ther un­der­scor­ing how gov­ern­ment pol­icy can over­ride ba­sic mar­ket ac­cess for hard­ware, even in the coun­try where much of that hard­ware is man­u­fac­tured. While some of these ex­port rules have seen par­tial re­ver­sals or reg­u­la­tory shifts, the over­all sit­u­a­tion high­lights a world in which hard­ware ac­cess is in­creas­ingly de­ter­mined by pol­i­tics, se­cu­rity regimes, and cor­po­rate strat­egy, and not by con­sumer de­mand. This should serve as a cau­tion­ary tale for any­one who thinks own­ing their own ma­chines won’t mat­ter in the years to come.

In an ironic twist, how­ever, one of the few po­ten­tial sources of re­lief may, in fact, come from China. Two Chinese man­u­fac­tur­ers, CXMT (ChangXin Memory Technologies) and YMTC (Yangtze Memory Technologies), are em­bark­ing on their most ag­gres­sive ca­pac­ity ex­pan­sions ever, view­ing the global short­age as a golden op­por­tu­nity to close the gap with the in­cum­bent big three

(Samsung, SK Hynix, Micron).

CXMT is now the world’s fourth-largest DRAM maker by pro­duc­tion vol­ume, hold­ing roughly 10-11% of global wafer ca­pac­ity, and is build­ing a mas­sive new DRAM fa­cil­ity in Shanghai ex­pected to be two to three times larger than its ex­ist­ing Hefei head­quar­ters, with vol­ume pro­duc­tion tar­geted for 2027. The com­pany is also prepar­ing a $4.2 bil­lion IPO on Shanghai’s STAR Market to fund fur­ther ex­pan­sion and has re­port­edly de­liv­ered HBM3 sam­ples to do­mes­tic cus­tomers in­clud­ing Huawei.

YMTC, tra­di­tion­ally a NAND flash sup­plier, is con­struct­ing a third fab in Wuhan with roughly half of its ca­pac­ity ded­i­cated to DRAM, and has reached 270-layer 3D NAND ca­pa­bil­ity, rapidly nar­row­ing the gap with Samsung (286 lay­ers) and SK Hynix (321 lay­ers). Its NAND mar­ket share by ship­ments reached 13% in Q3 2025, close to Micron’s 14%. What’s par­tic­u­larly no­table is that

ma­jor PC man­u­fac­tur­ers are al­ready

turn­ing to these sup­pli­ers.

However, as men­tioned be­fore, with hard­ware hav­ing be­come a geopo­lit­i­cal topic, both com­pa­nies face on­go­ing (US-imposed) re­stric­tions. Hence, for ex­am­ple HP

has in­di­cated it would only use CXMT chips in de­vices for non-US mar­kets. Nevertheless, for con­sumers world­wide the emer­gence of vi­able fourth and fifth play­ers in the mem­ory mar­ket rep­re­sents the most tan­gi­ble hope of even­tu­ally break­ing the cur­rent sup­ply stran­gle­hold. Whether that re­lief ar­rives in time to pre­vent last­ing dam­age to the con­sumer hard­ware ecosys­tem re­mains an open ques­tion, though.

The rea­son I’m writ­ing all of this is­n’t to cre­ate panic, but to help put things into per­spec­tive. You don’t need to scav­enger-hunt for legacy parts in your lo­cal land­fill (yet) or swear off up­grades for­ever, but you do need to rec­og­nize that the rules have changed. The mar­ket that once catered to en­thu­si­asts and every­day users is turn­ing its back. So take care of your hard­ware, stretch its lifes­pan, up­grade thought­fully, and don’t as­sume re­place­ment will al­ways be easy or af­ford­able.

That PC, lap­top, NAS, or home server is­n’t dis­pos­able any­more. Clean it, main­tain it, repaste it, re­place fans and pro­tect it, as it may need to last far longer than you orig­i­nally planned.

Also, re­al­ize that the best time to up­grade your hard­ware was yes­ter­day and that the sec­ond best time is now. If you can af­ford sen­si­ble up­grades, es­pe­cially RAM and SSD ca­pac­ity, it may be worth do­ing sooner rather than later. Not for per­for­mance, but for in­sur­ance, be­cause the next time some­thing fails, it might be un­af­ford­able to re­place, as the era of ca­sual up­grades seems to be over. Five-year sys­tems may be­come eight- or ten-year sys­tems.

Software bloat will hurt more and

will re­quire re-think­ing. Efficiency will

mat­ter again. And look­ing at it from a dif­fer­ent an­gle, maybe that’s a good thing.

Additionally, the as­sump­tion that prices will nor­mal­ize again at some point is most likely a pipe dream. The old logic wait a year and it’ll be cheaper no longer ap­plies when man­u­fac­tur­ers are de­lib­er­ately con­strain­ing sup­ply. If you

need a new de­vice, buy it; If you don’t, how­ever, there is ab­solutely no need to spend money on the mi­nor yearly re­fresh cy­cle any longer, as the re­turns will be in­creas­ingly di­min­ish­ing. And again, look­ing at it from a dif­fer­ent an­gle, prob­a­bly that is also a good thing.

Consumer hard­ware is head­ing to­ward a bleak fu­ture where own­ing pow­er­ful, af­ford­able ma­chines be­comes harder or maybe even im­pos­si­ble, as man­u­fac­tur­ers aban­don every­day users to chase vastly more prof­itable data cen­ters, “AI”

firms, and en­ter­prise clients. RAM and SSD price spikes, Micron’s exit from the con­sumer mar­ket, and the re­sult­ing Samsung/SK Hynix du­op­oly are early warn­ing signs of a broader shift that will even­tu­ally af­fect CPUs, GPUs, and the en­tire PC ecosys­tem.

With large man­u­fac­tur­ers hav­ing sold out their en­tire pro­duc­tion ca­pac­ity to

hy­per­scalers for the rest of the year while si­mul­ta­ne­ously cut­ting con­sumer pro­duc­tion by dou­ble-digit per­cent­ages, con­sumers will have to take a back seat. Already to­day con­sumer hard­ware is over­priced, out of stock or even in­ten­tion­ally be­ing de­layed due to sup­ply is­sues.

In ad­di­tion, man­u­fac­tur­ers are piv­ot­ing to­wards con­sumer hard­ware sub­scrip­tions, where you never own the hard­ware and in the most dystopian tra­jec­tory, con­sumers might not buy any hard­ware at all, with the ex­cep­tion of low-end thin-clients

that are merely in­ter­faces, and will rent com­pute through cloud plat­forms, los­ing dig­i­tal sov­er­eignty in ex­change for con­ve­nience. And de­spite all of this sound­ing like sci­ence fic­tion, there is al­ready hard ev­i­dence prov­ing that ac­cess to hard­ware can in fact be po­lit­i­cally and eco­nom­i­cally re­voked.

Therefor I am urg­ing you to main­tain and up­grade wisely, and hold on to your

ex­ist­ing hard­ware, be­cause own­er­ship may soon be a lux­ury rather than the norm.

I can’t ex­press how much I ut­terly hate the “Continuing Disability Review.”

It is a let­ter that ar­rives every few years from the gov­ern­ment, ask­ing a ques­tion that is med­ically ab­surd and philo­soph­i­cally in­sult­ing: “Are you still dis­abled?”

As if my blind­ness were a sea­sonal al­lergy. As if I might have woken up last Tuesday, blinked, and re­al­ized that my op­tic nerves had de­cided to re­gen­er­ate spon­ta­neously.

This week, I re­ceived The Letter. It de­manded “updated med­ical ev­i­dence” to prove that I—a man who has been blind since birth—am, in fact, still blind.

I called the num­ber. I nav­i­gated the phone tree hellscape. I fi­nally reached a hu­man be­ing. Let’s call her “Karen from Compliance.”

“I have the doc­u­ments in PDF for­mat,” I told her, us­ing my po­lite, I haven’t had my morn­ing tea so make this easy on me, voice. “I can email them to you right now. You’ll have them in ten sec­onds.”

“We can­not ac­cept email,” Karen said. Her voice was flat, dry, and sounded like stale cof­fee and rigid ad­her­ence to a rule­book writ­ten in 1994. “It is a se­cu­rity risk. You must mail phys­i­cal copies, or you can fax them.”

“Fax them?” I asked. “You want me to fax you med­ical records when you could just delete the email af­ter sav­ing the at­tach­ments?”

“Those are the op­tions, sir. If we don’t re­ceive them by Friday, your ben­e­fits will be sus­pended.”

I did­n’t un­der­stand why they could­n’t just look back in my file, no­ticed noth­ing had changed in decades, and up­date it based on past data.

She said it with a chal­lenge in her tone. She knew who she was talk­ing to. She was talk­ing to a blind man liv­ing be­low the poverty line. She as­sumed that “fax it” was an im­pos­si­ble hur­dle. She as­sumed I would have to find a ride to a li­brary, pay twenty cents a page, and strug­gle with a phys­i­cal ma­chine I could­n’t read. She was count­ing on the fric­tion of the phys­i­cal world to make me give up.

I am a nerd. And I have an in­ter­net con­nec­tion.

“Okay,” I said, my voice drop­ping into the cool, smooth, ‘Let’s sys­tem­i­cally tango,’ tone of a man with a plan. “I will fax them. What is the num­ber?”

I hung up. And then, I went to work.

She wanted ev­i­dence? Oh boy, I would give her ev­i­dence.

I did­n’t just pull the re­cent files. I went into the archives. I dug into the deep, dig­i­tal bedrock of my hard drive. I pulled records from when I was five. I pulled the sur­gi­cal notes from my cere­bral palsy treat­ments. I pulled the in­take forms from every spe­cial­ist, every ther­a­pist, every so­cial worker who has ever writ­ten a note about my “deficits.”

I com­piled a sin­gle, mono­lithic PDF. It was a mon­u­ment to med­ical trauma. It was a li­brary of di­ag­no­sis.

It was five hun­dred and twelve pages long.

I opened my pre­ferred in­ter­net fax­ing ser­vice. This is a tool that al­lows me to send a fax purely through dig­i­tal data. It would cost $20, ex­actly the amount some­one had do­nated to the blog last week, but if I did­n’t do this, I would lose all my benifits. It costs me zero pa­per. It costs me zero toner.

By the way, your tips keep me writ­ing.

But for the re­cip­i­ent?

For the re­cip­i­ent, a fax is a phys­i­cal re­al­ity. It re­quires pa­per. It re­quires ink. It re­quires time.

I imag­ined Karen’s fax ma­chine. It was prob­a­bly an old, beige beast sit­ting in the cor­ner of a gray of­fice. It was likely low on pa­per. It was al­most cer­tainly low on pa­tience.

I up­loaded the file. The file size was mas­sive. The progress bar on my screen reader ticked up. Uploading… 20%… 50%… 80%…

And then, I sat back and lis­tened to the most beau­ti­ful sound in the world.

“Your fax has been sent,” my screen reader an­nounced.

I imag­ined the scene in that of­fice.

At first, it would just be a sin­gle page. Whirrr. Chunk. A stan­dard med­ical form. Karen would ig­nore it.

By page fifty, the ma­chine would be heat­ing up. The smell of hot toner would start to fill the cu­bi­cle. The rhyth­mic chunk-chunk-chunk of the print­ing would be­come a drone, a me­chan­i­cal chant of ma­li­cious com­pli­ance.

By page one hun­dred, the pa­per tray would run out. The ma­chine would start beep­ing. That high-pitched, in­sis­tent beep-beep-beep that de­mands at­ten­tion. Karen would have to get up. She would have to find a ream of pa­per. She would have to feed the beast.

And the beast would not stop.

Because I had set the retry limit to “Infinity.” If the line bus­ied out? It would call back. If the pa­per ran out? It would wait. It was a dig­i­tal siege en­gine.

I sent them every­thing. I sent them the eye charts that prove I can’t read eye charts. I sent them the phys­i­cal ther­apy logs. I sent them the blurry scans of notes writ­ten by doc­tors who are long since dead.

I sent them the Tsunami of Truth.

I wanted them to hold the weight of it. I wanted them to phys­i­cally feel the bur­den of proof they place on dis­abled bod­ies. They want us to doc­u­ment our ex­is­tence? Fine. Here is my ex­is­tence, one sheet of hot, curled pa­per at a time.

Two hours later, my phone rang.

It was Karen. She sounded breath­less. She sounded like she was stand­ing next to a ma­chine that was hy­per­ven­ti­lat­ing. In the back­ground, I could hear a rhyth­mic whir-chunk, whir-chunk.

“Yes?” I an­swered, my voice the pic­ture of in­no­cent help­ful­ness.

“Sir, please. You have to stop the fax. It’s… it’s been print­ing for an hour. It’s jam­ming the ma­chine. We’re out of toner.”

“Oh, you’re out of toner? It’s jammed? Oh my! Oh, I’m so sorry,” I said, putting ex­actly zero per­cent sin­cer­ity into the apol­ogy. “But you said you could­n’t ac­cept email. You said I had to pro­vide com­plete doc­u­men­ta­tion. I’m just fol­low­ing the rules, Karen. I would­n’t want my ben­e­fits to be sus­pended be­cause I missed doc­u­men­ta­tion, so here’s doc­u­men­ta­tion all the way back to when I’m five years old.”

“Jesus Christ, We have it!” she snapped. “We have enough! Please, just… can­cel the rest.”

“I’m afraid I can’t do that,” I lied. “It’s an au­to­mated process. Once it starts, it has to fin­ish. Security pro­to­cols, you un­der­stand.”

There was a long, stran­gled si­lence on the line. Then, a de­feated sigh.

“Fine! Fine,” she snapped. “We will mark your file as up­dated.”

“Thank you,” I said. “Have a won­der­ful day.”

I sat there in my quiet apart­ment, eat­ing a cookie. I imag­ined the pile of pa­per in that of­fice, a phys­i­cal moun­tain of ev­i­dence tes­ti­fy­ing to the fact that yes, I am blind, and yes, I am smarter than your bu­reau­cracy.

If you en­joyed this tiny vic­tory in a hos­tile world, you might en­joy, Seven Days in June by Tia Williams

learn how to fol­low the pod­cast or join my street team,

You can fol­low the main RSS feed, learn how to fol­low the pod­cast or join my street team, or fol­low via email with the form be­low.

I put an AI agent on a $7/month VPS, con­nected it to my own IRC server, and pointed it at my GitHub re­pos. Visitors can ask it about my work and get an­swers backed by ac­tual code, not rephrased re­sume text.

the prob­lem with “ask my re­sume”

Every port­fo­lio site with an AI chat­bot does the same thing: feed the re­sume into a model and let vis­i­tors rephrase it. It’s a par­lor trick. The model can’t tell you any­thing the re­sume does­n’t al­ready say.

I wanted some­thing dif­fer­ent. If a hir­ing man­ager asks “how does George han­dle test cov­er­age?” the an­swer should­n’t be “George val­ues com­pre­hen­sive test­ing.” It should clone the repo, count the tests, read the CI con­fig, and come back with specifics.

So I built the in­fra­struc­ture to make that work.

Two agents, two boxes, two se­cu­rity bound­aries.

vis­i­tor (browser)

└─ george­lar­son.me/​chat/

└─ gamja web IRC client

└─ wss://​null­claw.george­lar­son.me:443

└─ Cloudflare (proxy, TLS ter­mi­na­tion, bot pro­tec­tion)

└─ ergo IRC server (LarsonNet)

└─ #lobby

└─ nully (nullclaw agent)

├── reads pub­lic GitHub re­pos

├── pre­loaded port­fo­lio con­text

└── routes to iron­claw via #backoffice

└─ #backoffice (private IRC chan­nel)

└─ iron­claw (separate box, via Tailscale)

├── email ac­cess

├── cal­en­dar

└── pri­vate con­text

null­claw is the pub­lic-fac­ing door­man. It runs on a min­i­mal perime­ter box, a 678 KB Zig bi­nary us­ing about 1 MB of RAM. It han­dles greet­ings, an­swers ques­tions about my pro­jects, and can clone re­pos to sub­stan­ti­ate claims with real code.

iron­claw is the pri­vate agent on a sep­a­rate, more pow­er­ful sys­tem. It has ac­cess to email, deeper per­sonal con­text, and han­dles com­plex in­quiries routed from null­claw. That bound­ary is de­lib­er­ate: the pub­lic box has no ac­cess to pri­vate data.

This is where most peo­ple reach for the biggest model they can af­ford. That’s the wrong in­stinct for a door­man.

Greetings, triage, sim­ple ques­tions about my back­ground. Sub-second re­sponses. Pennies per con­ver­sa­tion. Speed mat­ters more than depth here.

When nully needs to clone a repo, read code, or syn­the­size find­ings across files, Sonnet steps in. You pay for rea­son­ing only when rea­son­ing is needed.

A pub­lic-fac­ing agent with­out a spend­ing limit is a li­a­bil­ity. The cap pre­vents both run­away con­ver­sa­tions and abuse. If some­one tries to burn through my in­fer­ence bud­get, they hit a wall.

Using Opus for a concierge would sig­nal the op­po­site of model un­der­stand­ing. If Haiku can han­dle it, don’t send it to Sonnet. Tiered in­fer­ence (cheap for the hot path, ca­pa­ble for the heavy lift­ing) is how I keep this un­der $2/day.

This box is a pub­lic-fac­ing perime­ter. It should be hard­ened like one.

Firewall: UFW with only three ports open: SSH, IRC (TLS), and HTTPS (WebSocket via Cloudflare).

Cloudflare proxy: Web vis­i­tors never hit the box di­rectly. WebSocket traf­fic goes through CF’s edge, which han­dles TLS ter­mi­na­tion, rate lim­it­ing, and bot fil­ter­ing.

Agent sand­box­ing: null­claw runs in su­per­vised mode with work­space-only file ac­cess, a re­stricted com­mand al­lowlist (read-only tools), and 10 ac­tions per hour max.

Cost con­trols: $2/day, $30/month hard caps. If the agent gets abused, the bud­get runs out be­fore the dam­age com­pounds.

The phi­los­o­phy is min­i­mal at­tack sur­face. The box runs two ser­vices (ergo and null­claw), serves no web con­tent di­rectly, and has no ac­cess to pri­vate data. If it gets com­pro­mised, the blast ra­dius is an IRC bot with a $2/day in­fer­ence bud­get.

what nully can ac­tu­ally do

This is the part that sep­a­rates it from a chat­bot:

“What lan­guages does George use?” Doesn’t par­rot the re­sume. Knows from pre­loaded con­text and can ver­ify by check­ing re­pos.

“How does he struc­ture tests?” Clones the repo, reads the test files, re­ports what it finds.

“Tell me about Fracture” Pulls from pre­loaded mem­ory about the pro­ject, can dig into the source for specifics.

“How do I reach him?” Provides con­tact info. Doesn’t hal­lu­ci­nate a phone num­ber.

“Can I sched­ule a call?” Nully calls iron­claw over Google’s A2A pro­to­col via Tailscale. Ironclaw processes the re­quest with its own LLM, sends back a struc­tured re­sponse, and nully re­lays the an­swer. The vis­i­tor never sees the hand­off.

It’s an IRC bot backed by Haiku, so it’s not per­fect. But it backs up what it says with code, and my re­sume can’t do that.

This is the part I’m most proud of.

null­claw al­ready serves Google’s A2A pro­to­col (v0.3.0): agent card dis­cov­ery, JSON-RPC dis­patch, task state ma­chine. What it did­n’t have was a client. It could re­ceive A2A calls but could­n’t make them. So I wrote one.

The a2a_­call tool sends mes­sage/​send JSON-RPC re­quests to re­mote agents, parses the task re­sponse (completed, failed, work­ing), ex­tracts the ar­ti­fact text, and re­turns it as a tool re­sult. It en­forces HTTPS for pub­lic end­points but al­lows plain­text HTTP for pri­vate net­works and Tailscale CGNAT ranges, be­cause when you’re de­bug­ging TLS be­tween two agents on a mesh VPN at 2am, the last thing you need is your own se­cu­rity pol­icy lock­ing you out.

But the re­ally slick part is on iron­claw’s side. The null­claw in­stance run­ning there does­n’t have its own API key. Instead, its LLM provider is pointed at iron­claw’s own gate­way as a passthrough:

nully (this box)

└─ a2a_­call tool → POST /a2a

└─ iron­claw’s null­claw (separate box, Tailscale)

├── re­ceives A2A task

├── needs to run in­fer­ence

└── provider con­fig: “ironclaw” → http://​127.0.0.1:3000/​v1

└─ iron­claw’s own gate­way

└─ routes to Kilo → ac­tual LLM

One API key. One billing re­la­tion­ship. The null­claw on iron­claw’s box is just an A2A bridge. It ac­cepts the pro­to­col, bor­rows iron­claw’s in­fer­ence pipeline, and re­sponds. No cre­den­tial du­pli­ca­tion, no sep­a­rate bud­get to track. The agent that owns the API key is the agent that pays for in­fer­ence, re­gard­less of who ini­ti­ated the re­quest.

This ar­ti­cle is both an in­tro­duc­tion to a tool I have been work­ing on called jsongrep, as well as a tech­ni­cal ex­pla­na­tion of the in­ter­nal search en­gine it uses. I also dis­cuss the bench­mark­ing strat­egy used to com­pare the per­for­mance of jsongrep against other JSON path-like query tools and im­ple­men­ta­tions.

In this post I’ll first show you the tool, then ex­plain why it’s fast (conceptually), then how it’s fast (the au­tomata the­ory), and fi­nally prove it (benchmarks).Upfront I would like to say that this ar­ti­cle is heav­ily in­spired by Andrew Gallant’s amaz­ing rip­grep tool, and his as­so­ci­ated blog post “ripgrep is faster than {grep, ag, git grep, ucg, pt, sift}”. jsongrep’s DFA-Based Query Engine

You can in­stall jsongrep from crates.io:cargo in­stall jsongrep

Like rip­grep, jsongrep is cross-plat­form (binaries avail­able here) and writ­ten in Rust.

jsongrep (jg bi­nary) takes a query and a JSON in­put and prints every value whose path through the doc­u­ment matches the query. Let’s build up the query lan­guage piece by piece us­ing this sam­ple doc­u­ment:

Dot paths se­lect nested fields by name. Dots (.) be­tween field names de­note con­cate­na­tion– “match this field, then that field”:$ cat sam­ple.json | jg ‘roommates[0].name’ room­mates.[0].name: “Alice”

Wildcards match any sin­gle key (*) or any ar­ray in­dex ([*]):$ cat sam­ple.json | jg ‘favorite_drinks[*]’ fa­vorite_­drinks.[0]: “coffee” fa­vorite_­drinks.[1]: “Dr. Pepper” fa­vorite_­drinks.[2]: “Monster Energy”

Alternation (|) matches ei­ther branch, like regex al­ter­na­tion:$ cat sam­ple.json | jg ‘name | room­mates’ name: “Micah” room­mates: [

{ “name”: “Alice”, “favorite_food”: “pizza” } ]

Recursive de­scent uses * and [*] in­side a Kleene star to walk ar­bi­trar­ily deep into the tree. For ex­am­ple, to find every name field at any depth:$ cat sam­ple.json | jg ‘(* | [*])*.name’ name: “Micah” room­mates.[0].name: “Alice”

The pat­tern (* | [*])* means “follow any key or any in­dex, zero or more times”, e.g., de­scend through every pos­si­ble path. The trail­ing .name then fil­ters for only those paths that end at a field called name.

Equivalently, jg ex­poses the -F (“fixed string”) flag as a short­hand for these re­cur­sive de­scent queries:$ cat sam­ple.json | jg -F name name: “Micah” room­mates.[0].name: “Alice”

Optional (?) matches zero or one oc­cur­rence:$ cat sam­ple.json | jg ‘roommates[0].favorite_food?’ room­mates.[0]: {

“name”: “Alice”, “favorite_food”: “pizza” }

room­mates.[0].fa­vorite_­food: “pizza”

Notice how the in­ner string “pizza” matches with the ?, in ad­di­tion to the par­ent zero-oc­cur­rence case.

Here’s a screen­shot show­ing sev­eral of these fea­tures in ac­tion:Ex­am­ple of some of jsongrep’s search query fea­tures in prac­tice. NOTE: jsongrep is smart about de­tect­ing if you are pip­ing to an­other com­mand like less or sort, in which case it will not dis­play the JSON paths. This can be over­rid­den though if de­sired with the –with-path op­tion.

JSON doc­u­ments are trees: ob­jects and ar­rays branch, scalars are leaves, and keys and in­dices la­bel the edges. Querying a JSON doc­u­ment is re­ally about de­scrib­ing paths through this tree. jsongrep takes this ob­ser­va­tion lit­er­ally: its query lan­guage is a reg­u­lar lan­guage over the al­pha­bet of keys and in­dices. Think reg­u­lar ex­pres­sions, but in­stead of match­ing char­ac­ters in a string, you’re match­ing edges in a tree.

Why does “regular” mat­ter? Because reg­u­lar lan­guages have a well-known, pow­er­ful prop­erty: they can be com­piled into a de­ter­min­is­tic fi­nite au­toma­ton (DFA). A DFA processes in­put in a sin­gle pass with $O(1)$ work per in­put sym­bol– no back­track­ing, no re­cur­sion stack, no ex­po­nen­tial blowup on patho­log­i­cal queries. The query is paid for once at com­pile time, then search is es­sen­tially free.

This is the key dif­fer­ence from tools like jq, jmes­path, or json­path-rust. Those tools in­ter­pret path ex­pres­sions: at each node in the JSON tree, they eval­u­ate the query, check pred­i­cates, and re­cur­sively de­scend into match­ing branches. If a query in­volves re­cur­sive de­scent (.. or $..), these tools may re­visit sub­trees or main­tain work­lists. jsongrep does some­thing fun­da­men­tally dif­fer­ent– it com­piles the query into a DFA be­fore it ever looks at the JSON, then walks the doc­u­ment tree ex­actly once, tak­ing a sin­gle $O(1)$ state tran­si­tion at each edge. No in­ter­pre­ta­tion, no back­track­ing, one pass.

As a con­se­quence, jsongrep is fast– like re­ally fast:

Again bor­row­ing from the rip­grep blog post, here’s an “anti-pitch” for jsongrep:jsongrep is not as ubiq­ui­tous (yet) as jq. jq is the go-to for JSON query­ing, fil­ter­ing, and trans­duc­tions. The query lan­guage is de­lib­er­ately less ex­pres­sive than jq’s. jsongrep is a search tool, not a trans­for­ma­tion tool– it finds val­ues but does­n’t com­pute new ones. There are no fil­ters, no arith­metic, no string in­ter­po­la­tion.jsongrep is new and has not been bat­tle-tested in the wild.Keep read­ing if in­ter­ested in the in­ter­nals of jsongrep!

With the tool overview and mo­ti­va­tion out of the way, let’s dive into the in­ter­nals. This sec­tion traces a sin­gle query through every stage of the en­gine.

The core of the search en­gine is a five-stage pipeline:Parse the JSON doc­u­ment into a tree via serde_j­son_bor­row (zero-copy).Construct an NFA from the query via Glushkov’s con­struc­tion al­go­rithm. Determinize the NFA into a DFA via sub­set con­struc­tion­Walk the JSON tree, tak­ing DFA tran­si­tions at each edge and col­lect­ing matches.

To make this con­crete, we’ll trace the query room­mates[*].name through every stage. Given our sam­ple doc­u­ment, this query should match “Alice” at path room­mates[0].name.

The query string room­mates[*].name is parsed into an AST. jsongrep uses a PEG gram­mar (via the pest li­brary) that maps the query DSL to a tree of Query enum vari­ants:

The gram­mar is in­ten­tion­ally sim­ple. Dots de­note con­cate­na­tion (sequencing), | de­notes al­ter­na­tion (disjunction), post­fix * de­notes Kleene star (zero or more rep­e­ti­tions), and post­fix ? de­notes op­tional (zero or one). Parentheses group subex­pres­sions. This maps di­rectly to the de­f­i­n­i­tion of a reg­u­lar lan­guage– and that’s the whole point. Because the query lan­guage is reg­u­lar, every­thing that fol­lows (NFA, DFA, sin­gle-pass search) is pos­si­ble.

The full Query AST sup­ports these vari­ants:

JSON val­ues form a tree. Object keys and ar­ray in­dices are the edges; the val­ues they point to are the nodes. Scalars (strings, num­bers, Booleans, null) are leaves.

Our sam­ple doc­u­ment forms this tree:

A query, then, de­scribes a set of paths from the root to match­ing nodes. The query room­mates[*].name de­scribes the path: take the room­mates edge, then any ar­ray in­dex, then the name edge.

With the query parsed into an AST, we need to con­vert it into an au­toma­ton that can match paths. The first step is build­ing a non­de­ter­min­is­tic fi­nite au­toma­ton (NFA).

jsongrep uses Glushkov’s con­struc­tion, which has a key ad­van­tage over the more com­mon Thompson’s con­struc­tion: it pro­duces an $\epsilon$-free NFA. Every tran­si­tion in the re­sult­ing NFA con­sumes a sym­bol– no ep­silon tran­si­tions to chase, which sim­pli­fies the down­stream de­ter­miniza­tion.

1. Linearize the query. Each sym­bol (field name, wild­card, in­dex range) in the query gets a unique po­si­tion num­ber. Our query room­mates[*].name has three sym­bols:

2. Compute the First and Last sets. The First set con­tains po­si­tions that can ap­pear at the start of a match; the Last set con­tains po­si­tions that can ap­pear at the end. For a sim­ple se­quence, First = {first el­e­ment} and Last = {last el­e­ment}:

3. Compute the Follows set. For each po­si­tion i, Follows(i) is the set of po­si­tions that can im­me­di­ately fol­low i in a valid match. For a sim­ple se­quence, each po­si­tion fol­lows the one be­fore it:

For queries with Kleene star or al­ter­na­tion, the $\textit{Follows}$ sets be­come more in­ter­est­ing– loops and branches ap­pear nat­u­rally.

4. Assemble the NFA. The NFA has $n + 1$ states (one start state plus one per po­si­tion). Transitions are wired up from the com­puted sets:From the start state $q_0$, add tran­si­tions to every po­si­tion in the $First$ set­For each po­si­tion $i$ and each $j \in \textit{Follows}(i)$, add a tran­si­tion from state $i$ to state $j$ on sym­bol $j$States cor­re­spond­ing to po­si­tions in the $\textit{Last}$ set are marked ac­cept­ing

For our query, the re­sult­ing NFA is:Con­structed NFA for `roommates[*].name`: NFA States: 4 Start State: 0 Accepting States: [3] First set: [“[0] Field(roommates)“] Last set: [“[2] Field(name)“] Factors set: [0] Field(roommates) can be fol­lowed by: [1] Range(0, 18446744073709551615) [1] Range(0, 18446744073709551615) can be fol­lowed by: [2] Field(name) [2] Field(name) can­not be fol­lowed Transitions: state 0: on [0] Field(roommates) -> [1] state 1: on [1] Range(0, 18446744073709551615) -> [2] state 2: on [2] Field(name) -> [3] state 3:The 18446744073709551615 value is the value of usize::MAX on my ma­chine (64 bit ad­dress space, equal to 2^64 - 1), which is the max­i­mum value of a 64-bit un­signed in­te­ger.

This is a sim­ple chain for our sim­ple query, but for queries with * or |, the NFA would have branch­ing and loop­ing edges. For ex­am­ple, (* | [*])*.name would pro­duce a state with self-loops on both FieldWildcard and ArrayWildcard, cap­tur­ing the “descend through any­thing” be­hav­ior.

An NFA can be in mul­ti­ple states si­mul­ta­ne­ously– on a given in­put, it may have sev­eral valid tran­si­tions. This is fine the­o­ret­i­cally but bad for per­for­mance: sim­u­lat­ing an NFA means track­ing a set of ac­tive states at each step. A DFA, by con­trast, is in ex­actly one state at all times, mean­ing each tran­si­tion is an O(1) table lookup. Importantly, Rabin and Scott showed that every NFA can be turned into an equiv­a­lent DFA.

The stan­dard al­go­rithm for con­vert­ing an NFA to a DFA is sub­set con­struc­tion (also called the pow­er­set con­struc­tion). The idea is sim­ple: each DFA state cor­re­sponds to a set of NFA states. The al­go­rithm ex­plores all reach­able sets via breadth-first search:Start with the DFA state cor­re­spond­ing to $q_0$ (just the NFA start state).For each DFA state and each sym­bol in the al­pha­bet, com­pute the set of NFA states reach­able by tak­ing that tran­si­tion from any NFA state in the cur­rent set. If this re­sult­ing set is new, cre­ate a new DFA state for it.A DFA state is ac­cept­ing if any of its con­stituent NFA states is ac­cept­ing.Re­peat un­til no new DFA states are dis­cov­ered.

For our ex­am­ple query room­mates[*].name, the NFA is al­ready de­ter­min­is­tic (a sim­ple chain with no branch­ing), so sub­set con­struc­tion pro­duces a DFA with the same shape:Con­structed DFA for query: `roommates[*].name` DFA States: 4 Start State: 0 Accepting States: [3] Alphabet (4 sym­bols): 0: Other 1: Field(“roommates”) 2: Field(“name”) 3: Range(0, 18446744073709551615) Transitions: state 0: on [Other] -> (dead) on [Field(“roommates”)] -> 1 on [Field(“name”)] -> (dead) on [Range(0, 18446744073709551615)] -> (dead) state 1: on [Other] -> (dead) on [Field(“roommates”)] -> (dead) on [Field(“name”)] -> (dead) on [Range(0, 18446744073709551615)] -> 2 state 2: on [Other] -> (dead) on [Field(“roommates”)] -> (dead) on [Field(“name”)] -> 3 on [Range(0, 18446744073709551615)] -> (dead) state 3: on [Other] -> (dead) on [Field(“roommates”)] -> (dead) on [Field(“name”)] -> (dead) on [Range(0, 18446744073709551615)] -> (dead)

So the DFA’s state di­a­gram looks like this:

In the im­ple­men­ta­tion, the al­pha­bet is­n’t just the lit­eral sym­bols from the query– jsongrep also adds an Other sym­bol to han­dle JSON keys that don’t ap­pear in the query. Any tran­si­tion on Other leads to a dead state (or stays in a state where that key is ir­rel­e­vant), en­sur­ing we skip non-match­ing branches ef­fi­ciently.

For more com­plex queries, sub­set con­struc­tion can pro­duce DFA states that com­bine mul­ti­ple NFA states. For in­stance, (* | [*])*.name would pro­duce DFA states rep­re­sent­ing sets like $\set{q_0, q_1}$ (both “at start” and “in the mid­dle of de­scend­ing”), which is what en­ables the sin­gle-pass be­hav­ior.

This is the pay­off. With the DFA built, search­ing the JSON doc­u­ment is a sim­ple depth-first tra­ver­sal of the tree, car­ry­ing the DFA state along:Start at the root of the JSON tree in DFA state $q_0$.At each node, it­er­ate over its chil­dren (object keys or ar­ray in­dices).For each child edge, look up the DFA tran­si­tion: given the cur­rent state and the edge la­bel (key name or in­dex), what’s the next state?If no tran­si­tion ex­ists for this edge, skip the sub­tree en­tirely. If the new state is ac­cept­ing, record the match (path + value).Re­curse into the child with the new DFA state.

Let’s trace our query room­mates[*].name against the sam­ple doc­u­ment:

1. Start at the root ob­ject in DFA state $q_0$. Iterate over its three keys:

2. At the room­mates ar­ray in state $q_1$. Iterate over its in­dices:

3. At the room­mates[0] ob­ject in state $q_2$. Iterate over its keys:Edge “name”: $\delta(q_2, \texttt{Field(“name”)}) \to q_3$. State $q_3$ is ac­cept­ing– record the match: room­mates.[0].name → “Alice”.

Notice how the DFA let us skip the “name” and “favorite_drinks” sub­trees at the root in step 1– we never even looked at their val­ues. On a large doc­u­ment, this prun­ing is what makes the search fast: en­tire branches of the JSON tree are dis­carded in $O(1)$ with­out re­curs­ing into them.

Every node is vis­ited at most once, and each tran­si­tion is an $O(1)$ table lookup. The to­tal search time is O(n) where n is the num­ber of nodes in the JSON tree. No back­track­ing, no in­ter­pre­ta­tion over­head.

As an im­ple­men­ta­tion bonus, jsongrep uses serde_j­son_bor­row for zero-copy JSON pars­ing. The parsed tree holds bor­rowed ref­er­ences (&str) into the orig­i­nal in­put buffer rather than al­lo­cat­ing new strings, which sig­nif­i­cantly re­duces mem­ory over­head on large doc­u­ments.

All bench­marks use Criterion.rs, a sta­tis­tics-dri­ven Rust bench­mark­ing frame­work that pro­vides con­fi­dence in­ter­vals, out­lier de­tec­tion, and change de­tec­tion across runs.

Four datasets of in­creas­ing size test scal­ing be­hav­ior:

The bench­marks are split into four groups to iso­late where time is spent:doc­u­men­t_­parse — JSON pars­ing cost only. Measures serde_j­son_bor­row (zero-copy) vs. serde_j­son::Value (allocating) vs. jmes­path::Vari­able. This iso­lates jsongrep’s zero-copy pars­ing ad­van­tage.query_­com­pile — Query com­pi­la­tion cost only. jsongrep must build an AST and con­struct a DFA up­front; other tools may have cheaper (or no) com­pile steps. This is the price jsongrep pays for fast search.query_search — Pre-compiled query, pre-parsed doc­u­ment, search only. Isolates the tra­ver­sal/​match­ing cost with­out parse or com­pile over­head.end_­to_end — The full pipeline: parse JSON + com­pile query + search. This is the re­al­is­tic CLI us­age sce­nario.

Each tool uses its own query syn­tax, but the bench­marks en­sure equiv­a­lent work across tools. For ex­am­ple:

* The zero-copy pars­ing ad­van­tage is ex­plic­itly iso­lated in the doc­u­men­t_­parse group, not hid­den.

* jsongrep’s up­front DFA com­pi­la­tion cost is mea­sured sep­a­rately in query_­com­pile, so read­ers can see the trade­off.

* Tools lack­ing cer­tain query fea­tures (e.g., jmes­path has no re­cur­sive de­scent) are skipped for those bench­marks rather than pe­nal­ized.

* Tools re­quir­ing own­er­ship of parsed JSON (jaq, jmes­path) use Criterion’s iter_­batched to fairly sep­a­rate cloning costs from search costs.

Let’s take a look at the re­sults from the bench­marks. We’ll use the xlarge dataset un­less oth­er­wise noted since it pro­vides the best demon­stra­tion of per­for­mance im­pacts, but the full re­sults are avail­able here.

No sur­prises here: serde_j­son_bor­row is the fastest, fol­lowed by serde_j­son::Value and jmes­path::Vari­able.

As ex­pected, jsongrep takes time to com­pile the dif­fer­ent queries and this is its largest cost:

Compare this to the com­pile time of jmes­path (an or­der of mag­ni­tude faster):

As shown at the be­gin­ning of the post, over the xlarge (~190 MB) dataset on the end-to-end bench­mark, it’s not even close:

The full, in­ter­ac­tive Criterion re­port is avail­able at the live bench­mark­ing site.

jsongrep also ex­poses its DFA-based query en­gine as a li­brary crate, so you can em­bed fast JSON search di­rectly in your own Rust pro­jects.

New York City’s pub­lic hos­pi­tal sys­tem an­nounced that it would not be re­new­ing its con­tract with Palantir as con­tro­versy mounts in the UK over the data an­a­lyt­ics and AI fir­m’s gov­ern­ment con­tract.

The pres­i­dent of the US’s largest mu­nic­i­pal pub­lic health­care sys­tem, Dr Mitchell Katz, tes­ti­fied last week be­fore the New York city coun­cil that the agree­ment with Palantir would ex­pire in October.

He said at the hear­ing that the con­tract, which fo­cused on re­cov­er­ing money for in­sur­ance claims, was al­ways meant to be short-term, and that there was an “absolute fire­wall” pre­vent­ing Palantir from shar­ing in­for­ma­tion with US Immigration and Customs Enforcement. He said that the agency had “not had any in­ci­dents”.

The con­tract and re­lated pay­ment doc­u­ments shared with the Guardian by the American Friends Service Committee and first re­ported by the Intercept, show that NYC Health + Hospitals has paid Palantir nearly $4m since November 2023. The con­tract noted that Palantir would be able to re­view notes about pa­tients’ health and help the hos­pi­tal claim more money in pub­lic ben­e­fits through pro­grams such as Medicaid. It also in­cludes a line stat­ing that with per­mis­sion from the city agency, Palantir can “de-identify” pa­tients’ pro­tected health in­for­ma­tion and use it for “purposes other than re­search”.

NYC Health + Hospitals said in an email to the Guardian that it will be tran­si­tion­ing to sys­tems that were made en­tirely in-house, and there will be no data shared with Palantir or use of the com­pa­ny’s ap­pli­ca­tions af­ter the con­tract ex­pires. “NYC Health + Hospitals’ use of Palantir tech­nol­ogy is strictly lim­ited to rev­enue cy­cle op­ti­miza­tion, help­ing the pub­lic health­care sys­tem close gaps be­tween ser­vices de­liv­ered and charges cap­tured, pro­tect crit­i­cal rev­enue, and re­duce avoid­able de­nials,” the agency said in an emailed state­ment.

A Palantir spokesper­son said in a state­ment: “Palantir, as a soft­ware com­pany, does not own or have any rights to cus­tomer data — and each cus­tomer en­vi­ron­ment is in­di­vid­u­ally pro­tected against unau­tho­rized ac­cess or mis­use via ro­bust se­cu­rity con­trols which can be fully ad­min­is­tered and au­dited by the cus­tomer.”

As New York City’s hos­pi­tal sys­tem pre­pares to part ways with Palantir, the com­pany is fac­ing sim­i­lar scrutiny over pri­vacy is­sues in its £330m agree­ment with the UK’s National Health Service (NHS). Health of­fi­cials in the UK are con­cerned that the con­tro­versy sur­round­ing Palantir may stop the na­tion­wide roll­out of the com­pa­ny’s data sys­tem, even though Keir Starmer is try­ing to speed up de­ploy­ment. As of last sum­mer, not even half of the coun­try’s health au­thor­i­ties had started us­ing Palantir’s tech­nol­ogy amid con­cerns from the com­mu­nity and doc­tors. A 12 March brief­ing by Medact, a health jus­tice char­ity, said Palantir’s soft­ware could en­able “data-driven state abuses of power”, in­clud­ing US-style ICE raids. Palantir has de­nied that the data could be used in this way, not­ing that it would be il­le­gal and a breach of con­tract.

Palantir, which also con­tracts with the British gov­ern­men­t’s Ministry of Defence, is ex­pand­ing its in­flu­ence in the coun­try — de­spite back­lash from ac­tivists and some law­mak­ers. The Guardian re­vealed last week that Palantir is try­ing to gain ac­cess to sen­si­tive na­tional fi­nan­cial reg­u­la­tion data.

The Financial Conduct Authority, a watch­dog for thou­sands of fi­nan­cial bod­ies from banks to hedge funds, awarded Palantir a con­tract to in­ves­ti­gate in­ter­nal in­tel­li­gence data to help root out fi­nan­cial crime. That has sparked out­cry from some MPs, who have urged the gov­ern­ment to halt this agree­ment. Liberal Democrats called on Monday for a gov­ern­ment in­ves­ti­ga­tion into the con­tract. Starmer has dis­missed sug­ges­tions that the UK has be­come “dangerously over-re­liant” on American tech com­pa­nies, in­clud­ing Palantir, but noted he pre­ferred to have more do­mes­tic ca­pa­bil­ity.

Medact has raised pri­vacy con­cerns in the UK about Palantir’s abil­ity to ac­cess de-iden­ti­fied pa­tient data. (De-identified data refers to data that has been stripped of char­ac­ter­is­tics that could in­di­cate who an in­di­vid­ual is, such as names and so­cial se­cu­rity num­bers.) In a 12 March brief­ing for health of­fi­cials, Medact ar­gued that the NHS’s data pri­vacy pro­tec­tions are in­suf­fi­cient; NHS England has said that data is de-iden­ti­fied as it moves through its na­tional soft­ware sys­tem, the NHS fed­er­ated data plat­form (FDP). But Medact cited con­cerns that this data can be eas­ily re-iden­ti­fied.

An NHS spokesper­son said in an emailed state­ment to the Guardian that the sup­plier of the FDP “was ap­pointed in line with pub­lic con­tract reg­u­la­tions and must only op­er­ate un­der the in­struc­tion of the NHS, with all ac­cess to data re­main­ing un­der NHS con­trol and strict con­trac­tual oblig­a­tions pro­tect­ing con­fi­den­tial­ity”.

Data pri­vacy ex­perts in­ter­viewed by the Guardian said that there are risks in Palantir ac­cess­ing New Yorkers’ de-iden­ti­fied data for pur­poses other than re­search, es­pe­cially given the com­pa­ny’s vast ac­cess to gov­ern­ment records, will­ing­ness to co­op­er­ate with the fed­eral gov­ern­ment and abil­ity to con­nect and an­a­lyze large datasets.

“De-identification is not the guar­an­tee it used to be, and it’s get­ting eas­ier with AI ca­pa­bil­i­ties to re-iden­tify in­for­ma­tion,” said Sharona Hoffman, a law pro­fes­sor at Case Western Reserve University.

Ari Ezra Waldman, a law pro­fes­sor at University of California, Irvine who has re­searched how gov­ern­ments and tech com­pa­nies use data about in­di­vid­u­als, says that we should be con­cerned “whenever a com­pany like Palantir or a hos­tile gov­ern­ment col­lects in­for­ma­tion on vul­ner­a­ble pop­u­la­tions”. He is par­tic­u­larly con­cerned about the con­trac­t’s pro­vi­sion to use the in­for­ma­tion for “purposes other than re­search”. That tells him the gov­ern­ment did­n’t have enough power to push back on Palantir when ne­go­ti­at­ing the con­tract, or did­n’t care or know the risk, he says.

Despite the hos­pi­tal sys­tem’s claims that the part­ner­ship had no real risks for pa­tients, ac­tivists liv­ing in New York City, and be­yond, are count­ing this as a win.

Nurses, pro-Pales­tin­ian ac­tivists and so­cial and cli­mate jus­tice groups ap­plied pres­sure on the city gov­ern­ment as part of a na­tion­wide cam­paign known as Purge Palantir to stop the com­pany from con­tract­ing with gov­ern­ment agen­cies, uni­ver­si­ties and cor­po­ra­tions.

“We don’t think that the same AI sys­tems that are tar­get­ing im­mi­grants here in the United States for ICE, as well as choos­ing places to bomb in Iran, should be the same AI sys­tems used in hos­pi­tals,” said Kenny Morris, an or­ga­nizer with the American Friends Service Committee. The group ob­tained the NYC Health + Hospitals con­tract with Palantir through a pub­lic records re­quest, and shared the doc­u­ment with the Intercept and the Guardian. The na­tional nurses union and the Boycott, Divestment, and Sanctions (BDS) move­ment were also in­volved in the cam­paign.

Groups with the “No Palantir in our NHS” cam­paign in the UK are hop­ing New York City’s pub­lic hos­pi­tal sys­tem’s de­ci­sion to let the Palantir con­tract ex­pire fu­els their own fight, too. Medact and Amnesty International UK told the Guardian in emailed state­ments that they are call­ing on the NHS to fol­low New York City’s ex­am­ple and ter­mi­nate its £330m con­tract with Palantir.

“As cam­paign­ers in New York have shown, work­ers and com­mu­ni­ties can hold our health in­sti­tu­tions ac­count­able and push them to make the right choice. We will do the same here, and force NHS England to can­cel this con­tract,” Dr Rhiannon Mihranian Osborne, cor­po­rate cam­paigns lead at Medact, which is in touch with Purge Palantir.

John Bradley, the long­time mem­ber of this com­mu­nity who was the founder, pro­ducer, and lead gui­tarist of Booster Patrol, died on March 20. He was 61.

I could­n’t think of a bet­ter way to pay trib­ute to the man who was both a band­mate and a friend than to write a song for him in the style of which he was a mas­ter. You can hear the first mix of the song here; when I fin­ish it prop­erly, I’ll put it up on Unauthorized in the Booster Patrol sec­tion.

Johnny B laid down his bur­den late on a Friday night

With the mu­sic of his band still ring­ing in the fad­ing light

Saint Peter met him at the gate, said Son, we heard you play

Leo Fender built this gold gui­tar and he saved it for this day

The choir’s been singing acapella ever since the world was new

They need some­one who knows the sad notes, they say that man is you

He wrapped his hands around that neck, felt the weight of holy gold

Every fret a year of sor­row, every string a story told

He hit a chord that shook the heav­ens, the an­gels stopped to hear

A tone so long and lone­some that Saint Matthew shed a tear

Peter said “We don’t need pretty, son, we’ve got harps here by the score

We want to hear that swampy sound that kept ’em com­ing back for more

Now every night in Heaven there’s a sound they never had

A solid gold Fender wail­ing every note both beau­ti­ful and sad

The choir hits the cho­rus, the Almighty taps His feet

And Johnny B is boost­ing live up on that golden street

He played the bro­ken-hearted blues from Beale Street to Monsignor

Now he’s jam­ming up in Heaven and he could­n’t ask for more.

Lay it down, Johnny B

Make that sound, Johnny B

Hit that chord

Lay it down, Johnny B

Make that sound, Johnny B

For the Lord

A few weeks ago, Cloudflare pub­lished “How we re­built Next.js with AI in one week.” One en­gi­neer and an AI model reim­ple­mented the Next.js API sur­face on Vite. Cost about $1,100 in to­kens.

The im­ple­men­ta­tion de­tails did­n’t in­ter­est me that much (I don’t work on fron­tend frame­works), but the method­ol­ogy did. They took the ex­ist­ing Next.js spec and test suite, then pointed AI at it and had it im­ple­ment code un­til every test passed. Midway through read­ing, I re­al­ized we had the ex­act same prob­lem - only in our case, it was with our JSON trans­for­ma­tion pipeline.

Long story short, we took the same ap­proach and ran with it. The re­sult is gnata — a pure-Go im­ple­men­ta­tion of JSONata 2.x. Seven hours, $400 in to­kens, a 1,000x speedup on com­mon ex­pres­sions, and the start of a chain of op­ti­miza­tions that ended up sav­ing us $500K/year.

At Reco, we have a pol­icy en­gine that eval­u­ates JSONata ex­pres­sions against every mes­sage in our data pipeline - bil­lions of events, on thou­sands of dis­tinct ex­pres­sions. JSONata is a query and trans­for­ma­tion lan­guage for JSON (think jq with lambda func­tions), which makes it ideal for en­abling our re­searchers to write de­tec­tion rules with­out hav­ing to di­rectly in­ter­act with the code­base.

The ref­er­ence im­ple­men­ta­tion is JavaScript, whereas our pipeline is in Go. So for years we’ve been run­ning a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go ser­vices call over RPC. That meant that for every event (and ex­pres­sion) we had to se­ri­al­ize, send over the net­work, eval­u­ate, se­ri­al­ize the re­sult, and fi­nally send it back.

This was cost­ing us ~$300K/year in com­pute, and the num­ber kept grow­ing as more cus­tomers and de­tec­tion rules were added. For ex­am­ple, one of our larger clus­ters had scaled out to well over 200 repli­cas just for JSONata ex­pres­sions, which re­sulted in some un­ex­pected Kubernetes trou­bles (like reach­ing IP al­lo­ca­tion lim­its).

In some re­spects, the RPC la­tency over­head was ac­tu­ally worse than the pure dol­lar cost. An RPC round-trip is ~150 mi­crosec­onds be­fore any eval­u­a­tion even starts. For a sim­ple field lookup like user.email = “ad­min@co.com” some­thing that should take nanosec­onds - we’re pay­ing mi­crosec­onds just for cross­ing a lan­guage bound­ary. At our scale, those mi­crosec­onds stack up quickly.

We’d tried a few things over the years - op­ti­miz­ing ex­pres­sions, out­put caching, and even em­bed­ding V8 di­rectly into Go (to avoid the net­work hop). They did their part, but it was mostly just in­cre­men­tal im­prove­ments. The clos­est we got was a lo­cal eval­u­a­tor we built us­ing GJSON that han­dled sim­ple ex­pres­sions di­rectly on raw bytes. It was fast for what it cov­ered, but any­thing com­plex had to fall back to jsonata-js. We were patch­ing around the prob­lem, but the root cause re­mained un­solved.

During the week­end I built out a plan (using AI) sep­a­rated into ‘waves’. The ap­proach was the same as Cloudflare’s vinext rewrite: port the of­fi­cial jsonata-js test suite to Go, then im­ple­ment the eval­u­a­tor un­til every test passes. The fol­low­ing day, I pressed play. The plan was straight­for­ward - build out the full JSONata 2.x spec in Go, with a fo­cus on per­for­mant stream­ing and some ex­tra fea­tures sprin­kled on (localized caching, WASM sup­port, met­rics, and fallthrough ca­pa­bil­i­ties back to the jsonata-js RPC).

A few it­er­a­tions and some 7 hours later - 13,000 lines of Go with 1,778 pass­ing test cases.

I shared the num­bers in­ter­nally and some­one asked about the ROI. Production cost for jsonata-js in the pre­vi­ous month was about $25K - now it was 0. That con­ver­sa­tion ended up be­ing pretty short.

gnata has a two-tier eval­u­a­tion ar­chi­tec­ture. At com­pile time, each ex­pres­sion is an­a­lyzed and clas­si­fied.

The fast path han­dles sim­ple ex­pres­sions - field lookups, com­par­isons, and a set of 21 built-in func­tions ap­plied to pure paths (things like $exists(a.b) or $lowercase(name)). These are eval­u­ated di­rectly against the raw JSON bytes with­out ever fully pars­ing the doc­u­ment. For some­thing like ac­count.sta­tus = “active” you get 0 heap al­lo­ca­tions.

Everything else goes through the full path - a com­plete parser and eval­u­a­tor with full JSONata 2.x se­man­tics. This does parse the JSON, but only the sub­trees it ac­tu­ally needs, not the en­tire doc­u­ment.

On top of this there’s a stream­ing layer (the StreamEvaluator) de­signed for our spe­cific work­load: eval­u­ate N com­piled ex­pres­sions against each event, where events are struc­turally sim­i­lar.

All field paths from all ex­pres­sions are merged into a sin­gle scan. The num­ber of ex­pres­sions does­n’t mat­ter - raw event bytes are only read once. After warm-up, the hot path is lock-free. Evaluation plans are com­puted once per event schema and cached im­mutably, so reads are a sin­gle atomic load with no syn­chro­niza­tion.Mem­ory is bounded. The cache has a con­fig­urable ca­pac­ity and evicts the old­est en­tries when full.

The fast-path de­sign took a lot of in­spi­ra­tion from the ex­ist­ing lo­cal eval­u­a­tor. For sim­ple ex­pres­sions it was ex­cel­lent — gnata won’t be faster on an ap­ples-to-ap­ples com­par­i­son for those. But the schema-aware caching and batch eval­u­a­tion is where the real gains come from.

Correctness: 1,778 test cases from the of­fi­cial jsonata-js test suite + 2,107 in­te­gra­tion tests in the pro­duc­tion wrap­per.

The speedup on sim­ple lookups is mostly from elim­i­nat­ing the RPC over­head en­tirely — gnata eval­u­ates di­rectly on raw bytes with no JSON pars­ing. Complex ex­pres­sions in­volve full pars­ing and AST eval­u­a­tion, so the gap nar­rows, but they’re still 25-90x faster than the RPC path.

In prac­tice, gnata runs as a li­brary in­side our ex­ist­ing Go ser­vices. The se­ri­al­iza­tion and RPC over­head goes away.

Building the li­brary was day one. The rest of the week was about mak­ing sure it was ac­tu­ally cor­rect.

We al­ready had mis­match de­tec­tion in­fra­struc­ture in the code­base - fea­ture flags, shadow eval­u­a­tion, com­par­i­son log­ging - built months ear­lier for the lo­cal eval­u­a­tor. Wiring gnata into the same sys­tem was straight­for­ward.

* Days 2-6: Code re­view, QA against real pro­duc­tion ex­pres­sions, de­ployed to pre­prod in shadow mode. gnata eval­u­ates every­thing, but jsonata-js re­sults are still used. Mismatches logged and alerted. Fixed edge cases as they came up.

* Day 7: Three con­sec­u­tive days of zero mis­matches. gnata pro­moted to pri­mary.

By the time we pro­moted gnata, it had al­ready been pro­cess­ing bil­lions of events and pro­duc­ing iden­ti­cal re­sults to jsonata-js. We also caught bugs in jsonata-js it­self. Cases where the ref­er­ence im­ple­men­ta­tion does­n’t fol­low its own spec. gnata han­dles them cor­rectly.

A side ef­fect we did­n’t ex­pect: gnata was one of the first large PRs where we had AI agents re­view­ing AI-generated code. The agents were flag­ging every­thing - real con­cur­rency is­sues along­side cos­metic nit­picks - and we had to teach them which is which. That work fed into how we han­dle AI code re­view more broadly now.

Eliminating the RPC fleet took care of $300K, but there was one more thing we wanted to tackle - batch­ing events end-to-end in our rule en­gine. JSONata - be­ing only able to do a sin­gle eval­u­a­tion at a time - forces the in­fra around it to con­tort it­self with workarounds in or­der to stay per­for­mant. For our rule en­gine, that meant we were spin­ning up tens of thou­sands of gor­ou­tines to max­i­mize con­cur­rency (with all the added re­sources that en­tailed) in what would oth­er­wise be a straight­for­ward pipeline of mi­cro-batches. As you might ex­pect, that re­sulted in ex­ces­sive mem­ory and high CPU con­tention. In other words, our rule en­gine was both ex­pen­sive and slow.

gnata has no such lim­i­ta­tions, so we were able to re­place the rule en­gine in­ter­nals with a far sim­pler and more ef­fi­cient im­ple­men­ta­tion. The de­tails of the refac­tor de­serve their own blog post, but they in­volved just-in-time batch­ing (based on the re­quest co­a­lesc­ing pat­tern), short-lived caches and grouped en­rich­ment queries (done right be­fore eval­u­a­tion). I was quite sur­prised my­self with the through­put in­crease the refac­tor brought - and with it, a sharp drop in re­source uti­liza­tion.

The re­sult: an­other ~$18K/month off the bill - around $200K/year. Combined with gnata, that’s $500K/year gone from the pipeline, all in un­der 2 weeks of work.

There’s an ac­tive de­bate over whether fully hands-off AI code be­longs in pro­duc­tion. I have some strong opin­ions on this (which I’ve been vo­cal about in­ter­nally). But gnata has been a good case study for when it works well.

Andrej Karpathy re­cently wrote that pro­gram­ming is be­com­ing un­rec­og­niz­able, and that at the top tiers, deep tech­ni­cal ex­per­tise is “even more of a mul­ti­plier than be­fore be­cause of the added lever­age.” Until re­cently, I was rather skep­ti­cal of agen­tic code. February 2026, how­ever, has been a sort of in­flec­tion point even stub­born de­vel­op­ers like my­self can’t ig­nore.

I be­lieve gnata is just the be­gin­ning. I sus­pect 2026 will be the year of sur­gi­cal refac­tors.

go get github.com/​reco­labs/​gnata

expr, _ := gnata.Com­pile(`user.role = “admin” and user.login­Count > 100`)

json := []byte(`{

“user”: {

“email”: “ad­min@ex­am­ple.com”,

“role”: “admin”,

“loginCount”: 247

re­sult, _ := expr.Eval­Bytes(ctx, json)

fmt.Println(re­sult) // true