Apple has filed a law­suit against OpenAI to­day, ac­cus­ing the com­pany of trade se­cret theft. Specifically, Apple al­leges that its for­mer em­ploy­ees have stolen trade se­crets “for the ben­e­fit of OpenAI.”

“This case is about Apple’s for­mer em­ploy­ees steal­ing Apple’s trade se­crets for the ben­e­fit of OpenAI. Apple brings this suit to put a stop to it,” the law­suit says.

Apple state­ment

In a state­ment to 9to5Mac, an Apple spokesper­son said:

“At Apple, our teams are con­stantly de­vel­op­ing break­through tech­nolo­gies to cre­ate the best prod­ucts and ser­vices in the world, and pro­tect­ing their work and in­tel­lec­tual prop­erty is some­thing we take very se­ri­ously. Recently, sig­nif­i­cant ev­i­dence has emerged sug­gest­ing in­di­vid­u­als em­ployed by OpenAI wrong­fully took Apple’s se­cret and con­fi­den­tial in­for­ma­tion re­gard­ing our un­re­leased tech­nolo­gies, processes, and prod­ucts. We will al­ways de­fend our teams’ hard work and in­no­va­tions, and we are tak­ing all ap­pro­pri­ate steps to do so.”

“At Apple, our teams are con­stantly de­vel­op­ing break­through tech­nolo­gies to cre­ate the best prod­ucts and ser­vices in the world, and pro­tect­ing their work and in­tel­lec­tual prop­erty is some­thing we take very se­ri­ously. Recently, sig­nif­i­cant ev­i­dence has emerged sug­gest­ing in­di­vid­u­als em­ployed by OpenAI wrong­fully took Apple’s se­cret and con­fi­den­tial in­for­ma­tion re­gard­ing our un­re­leased tech­nolo­gies, processes, and prod­ucts. We will al­ways de­fend our teams’ hard work and in­no­va­tions, and we are tak­ing all ap­pro­pri­ate steps to do so.”

Update: Read OpenAI’s re­sponse here.

Apple ac­cuses OpenAI of trade se­cret theft

The law­suit names Chang Liu and Tang Tan as two of the de­fen­dants. Tang Tan served as VP of prod­uct de­sign at Apple, lead­ing iPhone and Apple Watch prod­uct de­sign. He de­parted the com­pany in February 2024 to work with Jony Ive. Chang Liu, mean­while, worked at Apple for eight years and was a se­nior sys­tem elec­tri­cal en­gi­neer be­fore de­part­ing to join OpenAI in January 2026.

Apple’s law­suit also names OpenAI and io Products as de­fen­dants.

OpenAI’s hard­ware ef­forts are be­ing led by Jony Ive, Apple’s for­mer chief de­sign of­fi­cer. OpenAI ac­quired Ive’s startup io as part of a $6.5 bil­lion deal last year. OpenAI’s takeover of the com­pany in­cluded more than 50 en­gi­neers, de­vel­op­ers, and other em­ploy­ees. In its orig­i­nal an­nounce­ment, OpenAI touted that Ive founded io in col­lab­o­ra­tion with Scott Cannon, Evans Hankey, and Tan.

Hankey led Apple’s de­sign team for sev­eral years af­ter Ive de­parted the com­pany. She de­parted in 2022 be­fore re­unit­ing with Ive as part of io. Cannon also pre­vi­ously worked at Apple.

Ive, Hankey, and Cannon are not per­son­ally men­tioned any­where in Apple’s ini­tial fil­ing to­day.

The com­plaint

Apple says it first raised con­cerns with OpenAI di­rectly in February, ask­ing the com­pany to in­ves­ti­gate and ad­dress the is­sue. OpenAI, how­ever, never re­sponded. Apple says the con­duct de­tailed in the fil­ing is “the tip of the ice­berg.”

This is the tip of the ice­berg. Apple lacks vis­i­bil­ity into what’s been hap­pen­ing be­hind closed doors at OpenAI, where such mis­con­duct is nor­mal­ized and ex­em­pli­fied by lead­er­ship. This much is clear, how­ever: at every level, from mem­bers of its Technical Staff to its Chief Hardware Officer, and in co­or­di­na­tion with busi­ness part­ners, OpenAI has been steal­ing Apple’s trade se­crets and con­fi­den­tial in­for­ma­tion. As a nat­ural re­sult, OpenAI’s nascent hard­ware busi­ness now rests.

This is the tip of the ice­berg. Apple lacks vis­i­bil­ity into what’s been hap­pen­ing be­hind closed doors at OpenAI, where such mis­con­duct is nor­mal­ized and ex­em­pli­fied by lead­er­ship. This much is clear, how­ever: at every level, from mem­bers of its Technical Staff to its Chief Hardware Officer, and in co­or­di­na­tion with busi­ness part­ners, OpenAI has been steal­ing Apple’s trade se­crets and con­fi­den­tial in­for­ma­tion. As a nat­ural re­sult, OpenAI’s nascent hard­ware busi­ness now rests.

The com­plaint, filed in the U.S. District Court for the Northern District of California, al­leges that Tan used in­sider knowl­edge of Apple’s con­fi­den­tial pro­jects to grill job can­di­dates in in­ter­views and learn more con­fi­den­tial in­for­ma­tion. Additionally, Tan di­rected job can­di­dates still work­ing at Apple to bring ac­tual Apple hard­ware com­po­nents and sam­ples for “show and tell” ses­sions.

When in­ter­view­ing Apple em­ploy­ees for jobs at OpenAI, Mr. Tan uses Apple’s con­fi­den­tial in­for­ma­tion to gain ac­cess to even more in­sider knowl­edge. He has used an Apple in­ter­nal pro­ject co­de­name to ask, “What’s the plan[?]” for an unan­nounced Apple prod­uct.

He has di­rected job can­di­dates still work­ing for Apple to bring “Actual parts” from Apple to their in­ter­views for “show and tell” ses­sions in which he and his team at OpenAI can elicit still more Apple con­fi­den­tial in­for­ma­tion. These di­rec­tions to bring Apple’s parts to OpenAI job in­ter­views sur­prised at least one of the can­di­dates, who com­mented that he “didn’t even know we could take those from the of­fice.”

OpenAI has been in­struct­ing Apple em­ploy­ees to bring “CAD/design ar­ti­facts” and “prototypes” to their in­ter­views and to di­vulge de­tails about their work such as “subsystem and com­po­nent se­lec­tion,” the “tools or method­olo­gies you use for sys­tem in­te­gra­tion, such as CAD soft­ware, sim­u­la­tion tools,” and “Vendor se­lec­tion and com­mu­ni­ca­tion/​col­lab­o­ra­tion with ven­dors.”

When in­ter­view­ing Apple em­ploy­ees for jobs at OpenAI, Mr. Tan uses Apple’s con­fi­den­tial in­for­ma­tion to gain ac­cess to even more in­sider knowl­edge. He has used an Apple in­ter­nal pro­ject co­de­name to ask, “What’s the plan[?]” for an unan­nounced Apple prod­uct.

He has di­rected job can­di­dates still work­ing for Apple to bring “Actual parts” from Apple to their in­ter­views for “show and tell” ses­sions in which he and his team at OpenAI can elicit still more Apple con­fi­den­tial in­for­ma­tion. These di­rec­tions to bring Apple’s parts to OpenAI job in­ter­views sur­prised at least one of the can­di­dates, who com­mented that he “didn’t even know we could take those from the of­fice.”

OpenAI has been in­struct­ing Apple em­ploy­ees to bring “CAD/design ar­ti­facts” and “prototypes” to their in­ter­views and to di­vulge de­tails about their work such as “subsystem and com­po­nent se­lec­tion,” the “tools or method­olo­gies you use for sys­tem in­te­gra­tion, such as CAD soft­ware, sim­u­la­tion tools,” and “Vendor se­lec­tion and com­mu­ni­ca­tion/​col­lab­o­ra­tion with ven­dors.”

Furthermore, Apple says a can­di­date be­gan “screenshotting and down­load­ing files re­lat­ing to a highly con­fi­den­tial Apple pro­ject” hours be­fore in­ter­view­ing with Tan, who then “solicited more in­for­ma­tion about that same Apple pro­ject” once the in­ter­view started. This be­came an “established pat­tern,” Apple says.

Tan also al­legedly pos­sessed and dis­trib­uted an in­ter­nal Apple “Need to Know” doc­u­ment to new OpenAI hires be­fore they gave their no­tice to Apple. The doc­u­ment in­cluded Apple’s de­par­ture se­cu­rity pro­to­cols. As part of its in­ves­ti­ga­tion, Apple found a “pattern by em­ploy­ees who de­part for OpenAI of tak­ing steps to evade the se­cu­rity processes in­tended to pro­tect Apple’s con­fi­den­tial in­for­ma­tion.”

Meanwhile, Apple also claims for­mer en­gi­neer Liu ex­ploited a se­cu­rity bug to down­load con­fi­den­tial en­gi­neer­ing files af­ter leav­ing the com­pany. Rather than re­port the ex­ploit, Liu al­legedly joked about it in mes­sages (“LOL,” “so funny”). Liu also failed to re­turn an Apple-issued lap­top af­ter his de­par­ture.

Apple al­leges that Liu down­loaded a “compilation of tech­ni­cal files with over a thou­sand pages” with de­tails of work he did at Apple. This in­cluded de­tailed man­u­fac­tur­ing doc­u­ments cov­er­ing the com­plex cir­cuit boards used in Apple hard­ware prod­ucts.

Liu also al­legedly coached an­other Apple em­ployee at the time, whom he was re­cruit­ing to OpenAI, on which con­fi­den­tial ma­te­ri­als to study be­fore her own OpenAI in­ter­view.

Finally, Apple al­leges that OpenAI had a trusted Apple part­ner carry out Apple’s pro­pri­etary metal-fin­ish­ing tech­nique, mis­lead­ing the part­ner into be­liev­ing it had Apple’s per­mis­sion to do so. Apple also says OpenAI ap­proached a sec­ond long­time Apple sup­plier that works on power and bat­tery man­u­fac­tur­ing, us­ing in­sider ter­mi­nol­ogy to ask “targeted ques­tions” about spe­cific Apple com­po­nents.

The suit seeks in­junc­tive re­lief and dam­ages, and comes as OpenAI works to bring its first con­sumer hard­ware de­vice to mar­ket.

Apple’s law­suit also comes af­ter Bloomberg re­ported that OpenAI was prepar­ing “legal ac­tion” against Apple over how its part­ner­ship to in­te­grate ChatGPT into Siri played out. Today’s law­suit from Apple, how­ever, says that agree­ment is not at is­sue here.

Tan and Liu are just two of many Apple em­ploy­ees who have de­parted for OpenAI. Today’s fil­ing says that there are over 400 for­mer Apple em­ploy­ees now work­ing at OpenAI.

There have been var­i­ous ru­mors about OpenAI’s hard­ware ef­forts so far. In April, Ming-Chi Kuo re­ported that OpenAI is de­vel­op­ing its own smart­phone, which could launch in 2028. The Information has also re­ported on OpenAI’s work on a HomePod-style smart speaker.

You can read the full fil­ing be­low and find the PDF linked here.

Chance’s fa­vorites:

Bring wire­less CarPlay to any car

“Apple: The First 50 Years” by David Pogue

Logitech MX Master 4

Belkin 3-in-1 MagSafe Charger

Beats Woven USB-C Charging Cables

AirPods Pro 3: $222 (Reg. $249)

Follow Chance: Threads, Bluesky, Instagram, and Mastodon.

FTC: We use in­come earn­ing auto af­fil­i­ate links. More.

Today, the European Parliament al­lowed the sus­pi­cion­less mass scan­ning of pri­vate com­mu­ni­ca­tions (“Chat Control 1.0”) to pass, a mea­sure it had re­jected twice in March. Although a ma­jor­ity of vot­ing Members of the European Parliament (MEPs) ac­tu­ally op­posed the reg­u­la­tion (314 against, 276 in fa­vor, 17 ab­sten­tions), the mo­tion to re­ject it failed to se­cure the re­quired ab­solute ma­jor­ity of 361 votes. As a re­sult, mass scan­ning is now per­mit­ted again un­til 2028.

A sym­bolic ex­emp­tion was adopted for en­crypted com­mu­ni­ca­tions—though in prac­tice, ser­vice providers do not scan these any­way. Furthermore, while a ma­jor­ity of vot­ing MEPs wanted to re­strict the scan­ning of pri­vate com­mu­ni­ca­tions strictly to sus­pects iden­ti­fied by the ju­di­ciary (322 to 255 votes), this amend­ment like­wise fell short of the re­quired ab­solute ma­jor­ity.

Dr. Patrick Breyer, civil rights ac­tivist and for­mer Member of the European Parliament (MEP), warns of the con­se­quences:

“The fact that Chat Control is mov­ing for­ward against the will of the ma­jor­ity of vot­ing MEPs is a farce and dam­ages democ­racy. Our chil­dren are the real losers in this un­de­mo­c­ra­tic process. The pas­sage of a gen­uine, per­ma­nent child pro­tec­tion reg­u­la­tion is now in se­ri­ous jeop­ardy. The Council will never agree to a des­per­ately needed par­a­digm shift as long as they can sim­ply stick to the old ap­proach of sus­pi­cion­less scan­ning at the whim of the tech in­dus­try.”

Despite the leg­isla­tive de­feat, Breyer re­mains de­fi­ant re­gard­ing the up­com­ing ne­go­ti­a­tions:

“Today’s vote on the in­terim reg­u­la­tion was a set­back, but the po­lit­i­cal bat­tle over the per­ma­nent ‘Chat Control 2.0’ is just get­ting started. The re­sis­tance we saw in Parliament to­day was so strong that find­ing a ma­jor­ity for per­ma­nent, sus­pi­cion­less mass scan­ning in fu­ture ne­go­ti­a­tions is a com­plete pipe dream.”

Breyer fun­da­men­tally re­jects the mass sur­veil­lance ap­proach:

“Trying to pro­tect chil­dren with sus­pi­cion­less mass sur­veil­lance is like fran­ti­cally mop­ping the floor while the faucet is still run­ning. Blanket chat con­trol is just as un­ac­cept­able as in­dis­crim­i­nately open­ing every­one’s phys­i­cal mail. For five years, this failed sys­tem has served as a smoke­screen to de­lay real ac­tion, all while over­whelm­ing the po­lice with false alarms. We need more child pro­tec­tion, not less—but we need ef­fec­tive pro­tec­tion, not the il­lu­sion of se­cu­rity.”

What hap­pens next?The in­terim reg­u­la­tion passed to­day will re­main in ef­fect un­til 2028, or un­til an agree­ment on a per­ma­nent reg­u­la­tion is reached. Negotiations for the per­ma­nent law will re­sume in September. The core dis­pute be­tween the EU Parliament, mem­ber state gov­ern­ments, and the EU Commission re­mains the scan­ning of pri­vate chats: should it be in­dis­crim­i­nate, or tar­geted at crim­i­nal sus­pects?

What changes with the re­turn of Chat Control 1.0—and what stays the same:

What is com­ing back: US tech com­pa­nies are once again al­lowed to scan pri­vate mes­sages with­out a war­rant or prior sus­pi­cion. This af­fects di­rect mes­sages on plat­forms like Instagram, Discord, Snapchat, Skype, and Xbox, as well as emails via Google’s Gmail and Apple’s iCloud.

What re­mains un­changed: Public so­cial me­dia posts and files hosted in cloud stor­age could al­ready be scanned with­out this law. Furthermore, pri­vate mes­sages can al­ways be re­ported by users, or mon­i­tored by au­thor­i­ties us­ing tar­geted, court-or­dered wire­tap­ping.

What is still NOT be­ing scanned: End-to-end en­crypted chats, such as those on WhatsApp, have al­ways been ex­empt from these scans. Additionally, European providers of mes­sag­ing and email ser­vices have never im­ple­mented chat con­trol mea­sures.

Why Chat Control is the wrong ap­proach:

Since 2022, the vol­ume of sus­pected abuse re­ports from the US has al­ready dropped by 50 per­cent due to the grow­ing use of mes­sage en­cryp­tion.

According to EU Commission fig­ures, mass scan­ning of pri­vate chats ac­counted for only 36 per­cent of all abuse re­ports in 2024 (the ma­jor­ity came from pub­lic posts and cloud stor­age).

The German Federal Criminal Police Office (BKA) re­ports that 48 per­cent of all in­com­ing alerts are not crim­i­nally rel­e­vant in the first place.

Crime sta­tis­tics re­veal that 40 per­cent of the re­sult­ing in­ves­ti­ga­tions ac­tu­ally tar­get mi­nors them­selves.

Under the chat con­trol sys­tem, an es­ti­mated 99 per­cent of re­ports gen­er­ated by Meta con­sist of pre­vi­ously known ma­te­r­ial, which gen­er­ally does lit­tle to stop on­go­ing, ac­tive abuse.

The EU Commission ad­mits there is no ev­i­dence that sus­pi­cion­less scan­ning of pri­vate com­mu­ni­ca­tions has led to an in­crease in crim­i­nal con­vic­tions or in res­cued chil­dren.

Talk of avert­ing a “protection gap” is there­fore highly mis­lead­ing. The most ef­fec­tive law en­force­ment tools—court-or­dered wire­taps, user re­ports, and the scan­ning of pub­lic plat­forms and cloud stor­age—were never at risk and re­main fully in­tact. The only prac­tice that was tem­porar­ily banned since April was the in­dis­crim­i­nate, war­rant­less search­ing of pri­vate, un­en­crypted mes­sages of in­no­cent peo­ple on a hand­ful of US plat­forms.

Background: The dead­lock over a per­ma­nent so­lu­tionIn par­al­lel, ne­go­ti­a­tions are on­go­ing for a per­ma­nent reg­u­la­tion to pro­tect chil­dren from sex­u­al­ized on­line vi­o­lence (the “CSAM Regulation” or “Chat Control 2.0”). In these talks, the EU Parliament is push­ing for a par­a­digm shift in how we ap­proach on­line child safety, de­mand­ing:

Mandatory, tar­geted de­tec­tion or­ders against ac­tual crim­i­nal sus­pects, rather than blan­ket mass scan­ning left to the tech in­dus­try’s dis­cre­tion.

An EU Child Protection Centre tasked with the sys­tem­atic re­moval of known abuse ma­te­r­ial from the pub­lic in­ter­net.

Strict se­cu­rity stan­dards for mes­sag­ing apps (“Security by Design”) to pre­vent cy­ber groom­ing.

This per­ma­nent leg­is­la­tion has stalled be­cause EU mem­ber states in­sist on main­tain­ing the out­dated ap­proach of vol­un­tary, sus­pi­cion­less scan­ning of pri­vate com­mu­ni­ca­tions. Critics warn that re­peat­edly ex­tend­ing the in­terim rules re­moves the po­lit­i­cal pres­sure needed to reach a vi­able, per­ma­nent agree­ment. Ultimately, cling­ing to the sta­tus quo threat­ens to de­rail real progress on child pro­tec­tion.

Patrick Breyer sums up the prob­lem:“As long as EU gov­ern­ments can use pro­ce­dural loop­holes to con­tin­u­ally ex­tend their com­fort­able sta­tus quo of vol­un­tary, in­dis­crim­i­nate mass scan­ning, they have zero in­cen­tive to en­gage with the Parliament’s tar­geted, legally sound, and far more ef­fec­tive child pro­tec­tion strat­egy.

“The Voices of Survivors: “We need pri­vacy to bring abusers to jus­tice”

Survivors of sex­ual vi­o­lence ex­plic­itly em­pha­size that un­tar­geted Chat Control did not help vic­tims:

Alexander Hanff, sur­vivor of child sex­ual abuse and pri­vacy ad­vo­cate, clar­i­fies:“As a sur­vivor I re­lied on con­fi­den­tial com­mu­ni­ca­tions to tell my story and find jus­tice for 28 school­boys—my­self in­cluded—re­sult­ing in the con­vic­tion of mul­ti­ple of­fend­ers. We sur­vivors need pri­vacy, be­cause with­out it we lose our voice. Chat Control was not cre­ated to pro­tect chil­dren. It was about Big Tech com­pa­nies like Meta or Google want­ing ac­cess to our data for prof­i­teer­ing, and states at­tempt­ing to ex­pand mass sur­veil­lance. The EU Commission has wasted five years and mil­lions of eu­ros on al­go­rithms that can­not pro­tect chil­dren and were never meant to. This money should have been di­verted to real polic­ing, causal re­search, and sup­port for sur­vivors, mil­lions of whom have never re­ceived any sup­port at all.”

Marcel Schneider* (name changed), a sur­vivor who has been su­ing Meta in court over its vol­un­tary Chat Control, adds:“Any­one mourn­ing the end of Chat Control has not un­der­stood what ac­tu­ally helps sur­vivors of sex­ual vi­o­lence. Mass sur­veil­lance by cor­po­ra­tions like Meta does not pre­vent abuse. Genuine pro­tec­tion means: delet­ing ma­te­r­ial at the source, proac­tive po­lice work on the Darknet, and apps that are safe by de­sign for chil­dren from the very start.”

Dorothée Hahne, found­ing mem­ber and vice-chair of the sur­vivors’ ini­tia­tive MOGiS e.V. (A Voice for Survivors), em­pha­sizes the dan­ger mass sur­veil­lance poses to vic­tims them­selves:“As sur­vivors, we see our ‘safe spaces’, our pro­tected ar­eas and com­mu­ni­ca­tion chan­nels, en­dan­gered or de­stroyed by this. For sur­vivors, this need is ex­is­ten­tial.“

When my wife said to me “Let me show you a t-shirt I saw…”, I was­n’t sure what to ex­pect, but it def­i­nitely was­n’t an ob­fus­cated bash script printed on the back de­signed to print a happy Easter egg mes­sage.

I’m not in the habit of click­baity head­li­ne­sI’ve no idea at all how many views this site gets, but I’m will­ing to bet it’s not even dou­ble-digit hu­mans per month. but I can see why sube­d­i­tors have such fun with them. The ti­tle above is, strictly speak­ing, en­tirely ac­cu­rate, but prob­a­bly not what you think. The ob­fus­cated code in ques­tion is ac­tu­ally an easter egg, it’s be­ing sup­plied via Uniqlo stores on an ex­cel­lent t-shirt de­signed by Akamai in sup­port of their Peace for All cam­paign.

And it’s very cool! The front has a heart in curly braces:

While the back has a big al­phanu­meric block:

Is that … a she­bang?!

My wife was right that I’d want to see it. Was that… a she­bang?

Take a closer look at the text block:

Yes, a she­bang! On a t-shirt sold in a high street store, no less. And it is clearly a base64 en­coded Here string be­ing fed to eval via base64 –decode.

Interesting. I told my wife “that’s ba­si­cally how peo­ple ship virus­es’ and bought it.

OCR was cum­ber­some

There was good news and bad news:

The bad news was that base64 has­n’t got er­ror cor­rec­tion, mean­ing that the tran­scrip­tion would need to be per­fect. Sigh.

The good news was that the string seemed to be in­tact - at least, it ter­mi­nated with the ex­pected padding and had match­ing quotes and braces. This is a good thing be­cause Uniqlo x Akamai sells an­other de­sign of shirt in the same range which is plainly in­com­plete­For ex­am­ple, its im­ports are trun­cated and it ends “retu” in­stead of “return”. This is a pity, be­cause it’s a re­ally nice colour com­bi­na­tion and con­tains the highly id­iomatic in­struc­tion go doStuff(msg, work… which any­one can re­late to., a trun­cated crop from a wider text block which could never com­pile.

I ran OCR in a few ways: First, us­ing the built-in OCR of the cir­cle-to-search fea­ture on Android, which is of­ten very good. Second, by us­ing Tesseract with a few op­tions and tweaks. And third by run­ning it through Claude. After diff­ing the three to look for mis­matches and get­ting Claude to out­put a table of lo­ca­tions for quick scan­ning, it be­came triv­ial but time-con­suimg to tidy up the re­main­der. The re­sult­ing string was:

IyEvYmluL2Jhc2gKCiMgQ29uZ3JhdHVsYXRpb25zISBZb3UgZm91bmQgdGhlIGVhc3RlciBlZ2chIOKdpO+4jwojIOOBiuOCgeOBp+OBqOOBhuOBlOOBluOBhOOBvuOBme+8gemaoOOBleOCjOOBn+OCteODl+ODqeOCpOOCuuOCkuimi+OBpOOBkeOBvuOBl+OBn++8geKdpO+4jwoKIyBEZWZpbmUgdGhlIHRleHQgdG8gYW5pbWF0ZQp0ZXh0PSLimaVQRUFDReKZpUZPUuKZpUFMTOKZpVBFQUNF4pmlRk9S4pmlQUxM4pmlUEVBQ0XimaVGT1LimaVBTEzimaVQRUFDReKZpUZPUuKZpUFMTOKZpVBFQUNF4pmlRk9S4pmlQUxM4pmlIgoKIyBHZXQgdGVybWluYWwgZGltZW5zaW9ucwpjb2xzPSQodHB1dCBjb2xzKQpsaW5lcz0kKHRwdXQgbGluZXMpCgojIENhbGN1bGF0ZSB0aGUgbGVuZ3RoIG9mIHRoZSB0ZXh0CnRleHRfbGVuZ3RoPSR7I3RleHR9CgojIEhpZGUgdGhlIGN1cnNvcgp0cHV0IGNpdmlzCgojIFRyYXAgQ1RSTCtDIHRvIHNob3cgdGhlIGN1cnNvciBiZWZvcmUgZXhpdGluZwp0cmFwICJ0cHV0IGNub3JtOyBleGl0IiBTSUdJTlQKCiMgU2V0IGZyZXF1ZW5jeSBzY2FsaW5nIGZhY3RvcgpmcmVxPTAuMgoKIyBJbmZpbml0ZSBsb29wIGZvciBjb250aW51b3VzIGFuaW1hdGlvbgpmb3IgKCggdD0wOyA7IHQrPTEgKSk7IGRvCiAgICAjIEV4dHJhY3Qgb25lIGNoYXJhY3RlciBhdCBhIHRpbWUKICAgIGNoYXI9IiR7dGV4dDp0ICUgdGV4dF9sZW5ndGg6MX0iCiAgICAKICAgICMgQ2FsY3VsYXRlIHRoZSBhbmdsZSBpbiByYWRpYW5zCiAgICBhbmdsZT0kKGVjaG8gIigkdCkgKiAkZnJlcSIgfCBiYyAtbCkKCiAgICAjIENhbGN1bGF0ZSB0aGUgc2luZSBvZiB0aGUgYW5nbGUKICAgIHNpbmVfdmFsdWU9JChlY2hvICJzKCRhbmdsZSkiIHwgYmMgLWwpCgogICAgIyBDYWxjdWxhdGUgeCBwb3NpdGlvbiB1c2luZyB0aGUgc2luZSB2YWx1ZQogICAgeD0kKGVjaG8gIigkY29scyAvIDIpICsgKCRjb2xzIC8gNCkgKiAkc2luZV92YWx1ZSIgfCBiYyAtbCkKICAgIHg9JChwcmludGYgIiUuMGYiICIkeCIpCgogICAgIyBFbnN1cmUgeCBpcyB3aXRoaW4gdGVybWluYWwgYm91bmRzCiAgICBpZiAoKCB4IDwgMCApKTsgdGhlbiB4PTA7IGZpCiAgICBpZiAoKCB4ID49IGNvbHMgKSk7IHRoZW4geD0kKChjb2xzIC0gMSkpOyBmaQoKICAgICMgQ2FsY3VsYXRlIGNvbG9yIGdyYWRpZW50IGJldHdlZW4gMTIgKGN5YW4pIGFuZCAyMDggKG9yYW5nZSkKICAgIGNvbG9yX3N0YXJ0PTEyCiAgICBjb2xvcl9lbmQ9MjA4CiAgICBjb2xvcl9yYW5nZT0kKChjb2xvcl9lbmQgLSBjb2xvcl9zdGFydCkpCiAgICBjb2xvcj0kKChjb2xvcl9zdGFydCArIChjb2xvcl9yYW5nZSAqIHQgLyBsaW5lcykgJSBjb2xvcl9yYW5nZSkpCgogICAgIyBQcmludCB0aGUgY2hhcmFjdGVyIHdpdGggMjU2LWNvbG9yIHN1cHBvcnQKICAgIGVjaG8gLW5lICJcMDMzWzM4OzU7JHtjb2xvcn1tIiQodHB1dCBjdXAgJHQgJHgpIiRjaGFyXDAzM1swbSIKCiAgICAjIExpbmUgZmVlZCB0byBtb3ZlIGRvd253YXJkCiAgICBlY2hvICIiCgpkb25lCgo=

The de­coded script

After Base64 de­cod­ing, the re­sult­ing script is a wel­com­ing and nicely com­mented Easter egg:

#!/bin/bash

# Congratulations! You found the easter egg! ❤️ # おめでとうございます！隠されたサプライズを見つけました！❤️

# Define the text to an­i­mate text=“♥PEACE♥FOR♥ALL♥PEACE♥FOR♥ALL♥PEACE♥FOR♥ALL♥PEACE♥FOR♥ALL♥PEACE♥FOR♥ALL♥”

# Get ter­mi­nal di­men­sions cols=$(tput cols) lines=$(tput lines)

# Calculate the length of the text tex­t_length=${#text}

# Hide the cur­sor tput civis

# Trap CTRL+C to show the cur­sor be­fore ex­it­ing trap “tput cnorm; exit” SIGINT

# Set fre­quency scal­ing fac­tor freq=0.2

# Infinite loop for con­tin­u­ous an­i­ma­tion for (( t=0; ; t+=1 )); do # Extract one char­ac­ter at a time char=“${text:t % tex­t_length:1}”

# Calculate the an­gle in ra­di­ans an­gle=$(echo “($t) * $freq” | bc -l)

# Calculate the sine of the an­gle sine_­value=$(echo “s($angle)” | bc -l)

# Calculate x po­si­tion us­ing the sine value x=$(echo “($cols / 2) + ($cols / 4) * $sine_value” | bc -l) x=$(printf “%.0f” “$x”)

# Ensure x is within ter­mi­nal bounds if (( x < 0 )); then x=0; fi if (( x >= cols )); then x=$((cols - 1)); fi

# Calculate color gra­di­ent be­tween 12 (cyan) and 208 (orange) col­or_s­tart=12 col­or_end=208 col­or_range=$((col­or_end - col­or_s­tart)) color=$((col­or_s­tart + (color_range * t / lines) % col­or_range))

# Print the char­ac­ter with 256-color sup­port echo -ne “\033[38;5;${color}m”$(tput cup $t $x)“$char\033[0m”

# Line feed to move down­ward echo “”

done

The re­sult is a con­tin­u­ous happy sine-wave loop of the cam­paign mes­sage, Peace for All:

Detail: The font choice

Edit: The fol­low­ing font ID is wrong! User ral­phi­nus on Hacker News pointed out that the font is Roboto Mono. I don’t know how I over­looked the very dif­fer­ent g.

I guess Uniqlo is run through Windows though: one thing that struck me was the font, which I’m I was pre­vi­ously al­most cer­tain is ConsolasI was for­tu­nate enough to cor­re­spond with the de­signer, Lucas de Groot, once in re­la­tion to a le­gal case in which some­one had used one of his fonts to forge a doc­u­ment. He was very help­ful and kind enough to con­firm the nec­es­sary facts in writ­ing, even though he owed noth­ing to us. , which I’m fond of. Note the very shal­lowly-slashed 0, the lack of serif on the 1 and the rounded curves of let­ters like BDyg and num­ber 2. It’s strik­ing be­cause it’s pri­mar­ily a Windows font, so not the sort of thing I’d ex­pect to see call­ing Bash.

Linux, the lan­guage of the Internet

Akamai put out a press re­lease about the shirt when it was re­leased, which is an­other sort of in­ter­est­ing due to the blend of tech and mar­ket­ing:

Design mes­sage More than 25 years ago, Akamai helped make the in­ter­net we know to­day pos­si­ble. This shirt’s de­sign is a call­back to those early days of life on­line. The light tan color is a ref­er­ence to the “beige box” plas­tic cas­ings that housed the early in­ter­net com­put­ers, and the heart on the front rep­re­sents how the in­ter­net has been used for good all over the world. On the back of the T-shirt is real code. It’s a ref­er­ence to Linux, the open-source lan­guage of the in­ter­net. This com­mon lan­guage unites Akamai with the world’s top brands and the peo­ple they serve, as we work to­gether to­ward a vi­sion of a safer and more con­nected world.

Design mes­sage

More than 25 years ago, Akamai helped make the in­ter­net we know to­day pos­si­ble. This shirt’s de­sign is a call­back to those early days of life on­line. The light tan color is a ref­er­ence to the “beige box” plas­tic cas­ings that housed the early in­ter­net com­put­ers, and the heart on the front rep­re­sents how the in­ter­net has been used for good all over the world. On the back of the T-shirt is real code. It’s a ref­er­ence to Linux, the open-source lan­guage of the in­ter­net. This com­mon lan­guage unites Akamai with the world’s top brands and the peo­ple they serve, as we work to­gether to­ward a vi­sion of a safer and more con­nected world.

Not the first

I de­lib­er­ately did­n’t search for spoil­ers at first, but I see that I am of course not the first per­son to get nerd-sniped by this. Wen Chuan Lee and that post also links to an­other (against which I’ve cross-checked my tran­scrip­tion above). I’m happy to carry on the chain.

Read the dis­cus­sion of this post on Hacker News, which in­cludes links to more info from the de­signer and other in­ter­est­ing ob­ser­va­tions

It looks like John Deere own­ers can soon feel free to fix their own ma­chines.

The Federal Trade Commission and at­tor­neys gen­eral from sev­eral states se­cured a right-to-re­pair set­tle­ment Wednesday with agri­cul­ture equip­ment gi­ant Deere & Co. — com­monly known as John Deere — that re­quires the com­pany to let farm­ers and in­de­pen­dent shops fix their own equip­ment.

The Illinois-based man­u­fac­turer has faced com­plaints for years for with­hold­ing the soft­ware needed for re­pairs and forc­ing cus­tomers to use au­tho­rized deal­ers in­stead of in­de­pen­dent ones.

This marks the sec­ond right-to-re­pair set­tle­ment Deere has reached this year, fol­low­ing a sep­a­rate $99 mil­lion class-ac­tion set­tle­ment with farm­ers in April. Though the class-ac­tion com­pen­sated con­sumers, the FTC’s set­tle­ment in­stead re­quires Deere to make its re­pair ser­vices avail­able to equip­ment own­ers and in­de­pen­dent shops.

The FTC and at­tor­neys gen­eral from Arizona, Illinois, Michigan, Minnesota and Wisconsin brought the an­titrust law­suit in January 2025, ar­gu­ing that Deere had il­le­gally re­stricted farm­ers and in­de­pen­dent shops that might oth­er­wise ser­vice them from re­pair­ing farm equip­ment such as trac­tors. Deere also makes en­gines and equip­ment for forestry, land­scap­ing and con­struc­tion.

Under the or­der filed in Illinois, Deere will now be re­quired to make di­ag­nos­tic and re­pair tools avail­able to equip­ment own­ers and in­de­pen­dent re­pair shops, not only its own net­work of au­tho­rized deal­ers. It also pre­vents Deere deal­ers from re­tal­i­at­ing against equip­ment own­ers or re­pair shops who choose to fix their own equip­ment in­stead of pay­ing for Deere’s ser­vices. The or­der is headed to Judge Iain D. Johnston for his ap­proval.

“For too long, Arizona farm­ers and in­de­pen­dent me­chan­ics have been at the mercy of Deere’s mo­nop­oly over re­pair tools, forced to wait — and pay — for au­tho­rized deal­ers just to fix bro­ken trac­tors and other equip­ment,” Arizona Attorney General Kris Mayes said in a state­ment Wednesday.

Deere must pay $1 mil­lion col­lec­tively to the five states for an­titrust en­force­ment costs and will be sub­ject to strict com­pli­ance over­sight for the next 10 years.

In the com­plaint, the FTC ar­gued that Deere pro­vides a ser­vice soft­ware tool to au­tho­rized deal­ers but does not pro­vide the full ver­sion to equip­ment own­ers or in­de­pen­dent shops. Deere had said the law­suit was base­less, de­nied that its dis­tri­b­u­tion of ser­vice tools was an­ti­com­pet­i­tive and ar­gued that it could not mo­nop­o­lize ser­vices since it does not di­rectly pro­vide them.

Sign up for Morning Wire: Our flag­ship newslet­ter breaks down the biggest head­lines of the day.

Deere main­tained its com­mit­ment to in­de­pen­dent re­pair in a state­ment Wednesday, adding that the agree­ment with the FTC re­in­forces its in­no­va­tion of more flex­i­ble re­pair op­tions.

“This is good news for our cus­tomers and for the fu­ture of how Deere equip­ment is sup­ported,” said Denver Caldwell, vice pres­i­dent of af­ter­mar­ket and cus­tomer sup­port.

Right-to-repair has be­come an in­creas­ingly com­mon is­sue over the years, es­pe­cially for tech prod­ucts, with con­sumers com­plain­ing that even sim­ple re­pairs can only be done by com­pany-au­tho­rized deal­ers.

Hot damn. This is the big one.

I’m happy to an­nounce that Chatto, the group and team chat ap­pli­ca­tion that I’ve been work­ing on for the past year or so, is now of­fi­cially Open Source, and avail­able for any­one to self-host.

The fastest way to give it a try is through Homebrew:

brew in­stall chat­to­corp/​tap/​chatto chatto init chatto run

See Chatto’s Getting Started Guide for de­tails. Or stick around to hear more!

Chat Just Got Real

Chatto aims to be the group chat ap­pli­ca­tion that you ac­tu­ally en­joy us­ing. You’re prob­a­bly fa­mil­iar with the one that rhymes with “knack”, or the one that rhymes with “beams”, or the one that rhymes with “this gourd”.

Chatto is just like those. Except you’re go­ing to love how com­pact and snappy it is. And that it’s Open Source. And you can just self-host it. For free, too! (A weird thing to write, but the OSS chat app space has be­come very weird in many ways!)

This is what it looks like:

If you want to see it in ac­tion, drop by the Chatto HQ Community!

It’s de­signed to be ex­tremely easy to self-host on your own in­fra­struc­ture. In its most ba­sic shape, you just run the ex­e­cutable, and that’s it. It even serves its own fron­tend!

It’s very light on re­sources, and prob­a­bly has the snap­pi­est fron­tend that you’ve ever used in an app like this. It puts data pro­tec­tion and pri­vacy first, with all per­sonal and chat data fully en­crypted at rest with per-user keys that get shred­ded when a user de­cides to delete their ac­count.

Each Chatto server pow­ers a sin­gle com­mu­nity, with no fed­er­a­tion of data be­tween servers, nor any third-party track­ing or an­a­lyt­ics. If you want to hang out in mul­ti­ple servers at once, the client will sim­ply con­nect to all of them di­rectly. If you want to host mul­ti­ple com­mu­ni­ties, just spin up mul­ti­ple Chatto processes. Easy!

Chatto comes with full sup­port for voice and video calls, with screen-shar­ing, built in. Calls are fully end-to-end en­crypted and will scale to as many par­tic­i­pants as your in­fra­struc­ture can han­dle.

And you can use it to­day, for free, by self-host­ing it on your own server. Binaries are avail­able for Linux (x86_64 and ARM64), ma­cOS, and Windows; head over to the Chatto Self-Hosting Documentation site to get started.

Chatto Cloud

If you pre­fer some­one else to take care of the host­ing, I’m also happy to an­nounce that Chatto Cloud will soon en­ter pub­lic beta. Chatto Cloud’s of­fer­ing is very sim­ple: it pro­vides paid host­ing for Chatto servers — and that’s it. No pre­mium sub­scrip­tions, no ads, no icky bits. Just host­ing.

And it’s re­ally good host­ing! Chatto Cloud is launch­ing with fully European and European-owned in­fra­struc­ture, with more re­gions slated for launch in early 2027. Every Chatto server on Chatto Cloud ben­e­fits from au­to­matic scal­ing, nightly back­ups of all data, and zero-down­time ver­sion up­grades.

There’s no lock-in; servers hosted through Chatto Cloud are 100% com­pat­i­ble with self-hosted ones, and you can pack up your data and move into or out of Chatto Cloud at any time.

If you want to get no­ti­fied about the start of the beta, please see the end of this post for a low-vol­ume newslet­ter you can sub­scribe to.

What’s Next for Chatto

Chatto is now at ver­sion 0.4. I con­sider it sta­ble enough for pro­duc­tion use, but there are a few im­por­tant fea­tures still miss­ing — head over to the Chatto Roadmap if you want an overview.

The fo­cus for Chatto 0.5 will be on ad­di­tional safety fea­tures (content re­port­ing and mod­er­a­tion) as well as pol­ish­ing the client, par­tic­u­larly its multi-server func­tion­al­ity. I have some fun stuff planned for this that I can’t wait to put into peo­ple’s hands.

I ex­pect Chatto to hit 1.0.0 in about 6 – 12 months. Until then, there may still be break­ing changes, even though I’ll be try­ing to keep them to a min­i­mum. If you do de­cide to self-host, please be ready to up­date to new ver­sions as they are re­leased.

Get in Touch

It’s been an ex­cit­ing jour­ney so far and I’m look­ing for­ward to find­ing out what’s ahead. If you’re self-host­ing Chatto, I’m su­per ea­ger to hear from you about your ex­pe­ri­ence — please don’t hes­i­tate to head over to the Chatto HQ com­mu­nity and get in touch.

Also please feel free to drop by and say hello if you’re in­ter­ested in Chatto for your com­pany, Open Source pro­ject, or sim­i­lar. I’d love to learn more about your re­quire­ments, and help you get set up.

Links

Chatto HQ Community - we have a #self-hosting sup­port chan­nel!

Chatto Self-Hosting Documentation

GitHub Repository

Chatto on Bluesky

Newsletter

If you want to be no­ti­fied about new re­leases or the start of Chatto Cloud’s beta, you’re in­vited to sub­scribe to the Chatto an­nounce­ments newslet­ter. It’s su­per low-vol­ume (~1 email per month), and is only used for no­ti­fy­ing you when ex­cit­ing new stuff be­comes avail­able.

Thanks for play­ing! You can send me feed­back or try my other game Zanagrams.

The tem­po­rary, vol­un­tary scan­ning regime — adopted in 2021, re­jected by Parliament in March 2026, ex­pired in April 2026, and now the sub­ject of an un­prece­dented re­vival at­tempt.

Jul 14, 2021

Temporary dero­ga­tion adopted

Regulation (EU) 2021/1232 cre­ates a tem­po­rary ex­cep­tion to the ePri­vacy Directive, giv­ing providers a le­gal ba­sis to vol­un­tar­ily scan pri­vate mes­sages for child sex­ual abuse ma­te­r­ial. Originally set to ex­pire 3 August 2024.

Apr 29, 2024

First ex­ten­sion

With the per­ma­nent reg­u­la­tion (Chat Control 2.0) nowhere near agree­ment, the dero­ga­tion is ex­tended un­til 3 April 2026.

Dec 18, 2025

Commission pro­poses sec­ond ex­ten­sion

The Commission pro­poses ex­tend­ing the dero­ga­tion by an­other two years, to April 2028.

Mar 2, 2026

LIBE com­mit­tee re­jects the ex­ten­sion

In a sur­prise vote, the Parliament’s civil lib­er­ties com­mit­tee re­jects the draft ex­ten­sion by 38 votes to 28.

Mar 11, 2026

Parliament adopts a pro­tec­tive po­si­tion

The ple­nary votes 458 – 103 for a com­pro­mise: ex­tend to 2027, but only with tar­geted and pro­por­tion­ate de­tec­tion of known con­tent, no end-to-end en­crypted com­mu­ni­ca­tions, and lim­it­ing scan­ning to sus­pected users or groups iden­ti­fied by the com­pe­tent ju­di­cial au­thor­ity.

Mid-Mar 2026

Trilogue on the ex­ten­sion col­lapses

The Council re­jects Parliament’s con­di­tions and shows no flex­i­bil­ity in ne­go­ti­a­tions; talks on the ex­ten­sion break down.

Mar 26, 2026

Parliament re­jects the ex­ten­sion out­right

311 MEPs vote against ex­tend­ing the dero­ga­tion (228 in favour, 92 ab­sten­tions). The crit­i­cal Amendment 34, re­ject­ing au­to­mated as­sess­ment of un­known pho­tos and texts, passes by a sin­gle vote (307 – 306).

Apr 4, 2026

Chat Control 1.0 ex­pires

The le­gal ground for vol­un­tary, in­dis­crim­i­nate scan­ning ends. Google, Meta, Microsoft, and Snap state they will con­tinue scan­ning pri­vate mes­sages re­gard­less.

Jun 26, 2026

Council moves to res­ur­rect the ex­pired law

EU am­bas­sadors agree to push a tem­po­rary re­vival — un­prece­dented, as Parliament’s re­jec­tion was con­sid­ered fi­nal. Because an ex­pired reg­u­la­tion can­not be ex­tended, the Council pro­poses a for­mally new law with iden­ti­cal con­tent via an ex­pe­dited pro­ce­dure.

Jul 2, 2026

Council adopts its po­si­tion

The Council adopts its po­si­tion on the “new” reg­u­la­tion via writ­ten pro­ce­dure.

Jul 7, 2026

Urgency pro­ce­dure ap­proved

Parliament voted 331 – 303 (11 ab­sten­tions) to fast-track the ex­pired dero­ga­tion, skip­ping the re­spon­si­ble Committee. A bind­ing vote fol­lows on Thursday, 9 July, where an ab­solute ma­jor­ity of 361 MEPs is needed to stop it.

The per­ma­nent CSA Regulation — pro­posed in 2022, dead­locked for years, and still un­a­greed af­ter five rounds of tri­logue ne­go­ti­a­tions. Encryption re­mains the red line.

May 11, 2022

Commission pro­poses the CSA Regulation

Home Affairs Commissioner Ylva Johansson un­veils a pro­posal for a per­ma­nent reg­u­la­tion mak­ing de­tec­tion and re­port­ing of child sex­ual abuse ma­te­r­ial a le­gal re­quire­ment for plat­forms — in­clud­ing a re­quire­ment to by­pass end-to-end en­cryp­tion.

Nov 2023

Parliament adopts a pro­tec­tive man­date

No scan­ning of end-to-end en­crypted ser­vices, de­tec­tion lim­ited to vi­sual ma­te­r­ial, ju­di­cial war­rants tar­geted at spe­cific sus­pects, and no manda­tory age ver­i­fi­ca­tion.

Oct 2025

Germany breaks the Council dead­lock

After years of Council dead­lock, Germany an­nounces it will vote against manda­tory sus­pi­cion­less scan­ning. The Danish pres­i­dency drops de­tec­tion or­ders and shifts to risk as­sess­ment and mit­i­ga­tion oblig­a­tions for providers, while propos­ing to make the vol­un­tary sus­pi­cion­less scan­ning (interim reg­u­la­tion) per­ma­nent.

Nov 26, 2025

Council en­dorses its po­si­tion

The Council adopts the soft­ened Danish com­pro­mise, open­ing tri­logue ne­go­ti­a­tions. Critics note the text still al­lows “voluntary” sus­pi­cion­less de­tec­tion and im­poses broad risk-mit­i­ga­tion du­ties, in­clud­ing manda­tory age ver­i­fi­ca­tion, that could re­shape pri­vate mes­sag­ing in prac­tice.

Dec 2025 — May 2026

Four tri­logue rounds

Negotiations be­tween Parliament, Council, and Commission take place on 9 December 2025, 26 February, 16 April, and 11 May 2026 — with­out agree­ment on the core is­sues.

Jun 10, 2026

Council’s own lawyers raise the alarm

The Council Legal Service states that the “voluntary” scan­ning pro­posal still con­sti­tutes gen­er­alised scan­ning of com­mu­ni­ca­tions — in­com­pat­i­ble with Article 7 of the EU Charter ab­sent rea­son­able sus­pi­cion and prior ju­di­cial au­tho­ri­sa­tion.

Jun 29, 2026

“Final” tri­logue fails

The fifth tri­logue, billed as the last with adop­tion tar­geted for July, pro­duces no deal. Negotiators can­not agree on mak­ing sus­pi­cion­less scan­ning per­ma­nent, as re­quested by Council. Progress is re­ported on ex­clud­ing manda­tory age ver­i­fi­ca­tion, but agree­ment is post­poned and talks con­tinue un­der the in­com­ing Irish pres­i­dency.

Jul 14, 2021

Chat Control 1.0

Temporary dero­ga­tion adopted

Regulation (EU) 2021/1232 cre­ates a tem­po­rary ex­cep­tion to the ePri­vacy Directive, giv­ing providers a le­gal ba­sis to vol­un­tar­ily scan pri­vate mes­sages for child sex­ual abuse ma­te­r­ial. Originally set to ex­pire 3 August 2024.

May 11, 2022

Chat Control 2.0

Commission pro­poses the CSA Regulation

Home Affairs Commissioner Ylva Johansson un­veils a pro­posal for a per­ma­nent reg­u­la­tion mak­ing de­tec­tion and re­port­ing of child sex­ual abuse ma­te­r­ial a le­gal re­quire­ment for plat­forms — in­clud­ing a re­quire­ment to by­pass end-to-end en­cryp­tion.

Nov 2023

Chat Control 2.0

Parliament adopts a pro­tec­tive man­date

No scan­ning of end-to-end en­crypted ser­vices, de­tec­tion lim­ited to vi­sual ma­te­r­ial, ju­di­cial war­rants tar­geted at spe­cific sus­pects, and no manda­tory age ver­i­fi­ca­tion.

Apr 29, 2024

Chat Control 1.0

First ex­ten­sion

With the per­ma­nent reg­u­la­tion (Chat Control 2.0) nowhere near agree­ment, the dero­ga­tion is ex­tended un­til 3 April 2026.

Oct 2025

Chat Control 2.0

Germany breaks the Council dead­lock

After years of Council dead­lock, Germany an­nounces it will vote against manda­tory sus­pi­cion­less scan­ning. The Danish pres­i­dency drops de­tec­tion or­ders and shifts to risk as­sess­ment and mit­i­ga­tion oblig­a­tions for providers, while propos­ing to make the vol­un­tary sus­pi­cion­less scan­ning (interim reg­u­la­tion) per­ma­nent.

Nov 26, 2025

Chat Control 2.0

Council en­dorses its po­si­tion

The Council adopts the soft­ened Danish com­pro­mise, open­ing tri­logue ne­go­ti­a­tions. Critics note the text still al­lows “voluntary” sus­pi­cion­less de­tec­tion and im­poses broad risk-mit­i­ga­tion du­ties, in­clud­ing manda­tory age ver­i­fi­ca­tion, that could re­shape pri­vate mes­sag­ing in prac­tice.

Dec 18, 2025

Chat Control 1.0

Commission pro­poses sec­ond ex­ten­sion

The Commission pro­poses ex­tend­ing the dero­ga­tion by an­other two years, to April 2028.

Dec 2025 — May 2026

Chat Control 2.0

Four tri­logue rounds

Negotiations be­tween Parliament, Council, and Commission take place on 9 December 2025, 26 February, 16 April, and 11 May 2026 — with­out agree­ment on the core is­sues.

Mar 2, 2026

Chat Control 1.0

LIBE com­mit­tee re­jects the ex­ten­sion

In a sur­prise vote, the Parliament’s civil lib­er­ties com­mit­tee re­jects the draft ex­ten­sion by 38 votes to 28.

Mar 11, 2026

Chat Control 1.0

Parliament adopts a pro­tec­tive po­si­tion

The ple­nary votes 458 – 103 for a com­pro­mise: ex­tend to 2027, but only with tar­geted and pro­por­tion­ate de­tec­tion of known con­tent, no end-to-end en­crypted com­mu­ni­ca­tions, and lim­it­ing scan­ning to sus­pected users or groups iden­ti­fied by the com­pe­tent ju­di­cial au­thor­ity.

Mid-Mar 2026

Chat Control 1.0

Trilogue on the ex­ten­sion col­lapses

The Council re­jects Parliament’s con­di­tions and shows no flex­i­bil­ity in ne­go­ti­a­tions; talks on the ex­ten­sion break down.

Tiny en­gine, im­mense model. Run GLM-5.2 (744B-parameter MoE) on a con­sumer ma­chine with ~25 GB of RAM — in pure C, with zero de­pen­den­cies, by stream­ing ex­perts from disk.

$ ./coli chat 🐦 col­i­brì v1.0 — GLM-5.2 · 744B MoE · int4 · stream­ing CPU ✓ pronto in 32s · res­i­dente 9.9 GB › ciao! ◆ Ciao! 😊 Come posso aiu­tarti oggi?

The idea

A 744B Mixture-of-Experts model ac­ti­vates only ~40B pa­ra­me­ters per to­ken — and only ~11 GB of those change from to­ken to to­ken (the routed ex­perts). So:

the dense part (attention, shared ex­perts, em­bed­dings — ~17B params) stays res­i­dent in RAM at int4 (~9.9 GB);

the 21,504 routed ex­perts (75 MoE lay­ers × 256 ex­perts + the MTP head, ~19 MB each at int4) live on disk (~370 GB) and are streamed on de­mand, with a per-layer LRU cache, an op­tional pinned hot-store, and the OS page cache as a free L2.

The en­gine is a sin­gle C file (c/glm.c, ~2,400 lines) plus small head­ers. No BLAS, no Python at run­time, no GPU re­quired (an opt-in CUDA tier for pinned ex­perts ex­ists — see be­low).

What’s im­ple­mented

Faithful GLM-5.2 (glm_moe_dsa) for­ward — val­i­dated to­ken-ex­act against a trans­form­ers or­a­cle (teacher-forcing 32/32, greedy 20/20 on a tiny-ran­dom model with the real ar­chi­tec­ture).

MLA at­ten­tion (q/kv-LoRA, in­ter­leaved par­tial RoPE) with com­pressed KV-cache: 576 floats/​to­ken in­stead of 32,768 (57× smaller — GLM-5.2 has 64 heads and no GQA).

DeepSeek-V3-style sig­moid router (noaux_tc, rout­ed_s­cal­ing_­fac­tor), shared ex­pert, first-3-dense lay­ers.

Native MTP spec­u­la­tive de­cod­ing — GLM-5.2′s own multi-to­ken-pre­dic­tion head (layer 78) drafts to­kens that the main model ver­i­fies in one batched for­ward. The head must be int8 (the con­verter does this by de­fault): at int4 draft ac­cep­tance col­lapses to 0 – 4% and spec­u­la­tion never en­gages; at int8 it’s 39 – 59% ac­cep­tance, 2.2 – 2.8 to­kens/​for­ward (community-measured, #8). Lossless — and stays loss­less un­der sam­pling via re­jec­tion sam­pling. Honest caveat from the same mea­sure­ment: on a cold cache each ver­i­fied draft routes to ex­tra ex­perts (~660 → ~1100 ex­pert-loads/​to­ken), so spec­u­la­tion can be a net time loss un­til the cache/​pin warms up — the adap­tive guard and DRAFT=0 are there for that.

True sam­pling — tem­per­a­ture + nu­cleus, de­faults tuned for int4 re­al­ity (0.7 / 0.90; the of­fi­cial 1.0 / 0.95 sam­ples quan­ti­za­tion noise from the tail).

Integer-dot ker­nels (Q8_0-style int8 ac­ti­va­tions, AVX2 mad­dubs): int8 mat­muls 1.4 – 2.5× faster (119 GFLOP/s mea­sured), int4 1.8× in batch — rout­ing de­cided per shape by mea­sure­ment (int4 sin­gle-row stays f32: it mea­sured slower).

MLA weight ab­sorp­tion (DeepSeek trick) for de­code: no per-to­ken k/​v re­con­struc­tion — the query ab­sorbs kv_b, con­text is pro­jected af­ter at­ten­tion. Validated ex­act: TF 32/32 and gen­er­a­tion 20/20 with ab­sorp­tion forced every­where.

Async ex­pert reada­head: while one block of ex­perts is be­ing mul­ti­plied, the ker­nel is al­ready read­ing the next (WILLNEED).

Quantization ker­nels: int8 / packed int4 / packed int2, per-row scales, AVX2, de­quant-on-use. Packing val­i­dated bit-iden­ti­cal to the int8 con­tainer.

DSA sparse at­ten­tion — GLM-5.2′s light­ning in­dexer, faith­ful to the ref­er­ence glm_­moe_dsa mod­el­ing: per-layer top-2048 causal key se­lec­tion (full/shared in­dexer lay­ers), auto-de­tected from the out-idx-* weights (–indexer con­verter mode, ~189 MB ex­tracted from the FP8 repo). Validated ex­act: forc­ing the se­lec­tion to keep every key re­pro­duces dense at­ten­tion to­ken-for-to­ken. DSA=0 dis­ables, DSA_TOPK over­rides.

KV-cache per­sis­tence — con­ver­sa­tions re­open warm across en­gine restarts: serve mode ap­pends the com­pressed MLA KV to .coli_kv af­ter every turn (~182 KB/token, crash-safe) and re­sumes it at startup with zero re-pre­fill. Validated byte-iden­ti­cal to an un­in­ter­rupted ses­sion. KVSAVE=0 dis­ables.

Router-lookahead prefetch (PILOT=1, ex­per­i­men­tal) — the next lay­er’s rout­ing is 71.6% pre­dictable from the cur­rent lay­er’s post-at­ten­tion state (measured); a ded­i­cated I/O thread prefetches those ex­perts while the cur­rent layer com­putes.

Batch-union MoE: in pre­fill (and MTP ver­i­fi­ca­tion), each unique ex­pert of the batch is read once and ap­plied to every po­si­tion that routes to it.

Byte-level BPE to­k­enizer in C (GPT-2-style with Unicode-property regex, 320k merges).

RAM safety: the ex­pert cache is auto-sized from MemAvailable at startup — an hon­est peak pro­jec­tion (working set, KV, MTP row, re­con­struc­tion buffers) so the ker­nel OOM-killer never fires.

Offline FP8→int4 con­verter (c/tools/convert_fp8_to_int4.py): down­loads one shard at a time (~5 GB), de­quants (128×128 block scales), re­quan­tizes to the en­gine’s con­tainer, deletes the shard — the 756 GB FP8 check­point never needs to ex­ist on disk at once. Resumable.

Honest num­bers (WSL2, 12 cores, 25 GB RAM, NVMe via VHDX)

This is not fast. It is a 744B fron­tier-class model an­swer­ing cor­rectly on a ma­chine that costs less than one H100 fan. Warm cache, pinned hot ex­perts and MTP push the use­ful-re­sponse la­tency down con­sid­er­ably; the physics of the disk does the rest.

SSD note

Cold starts are heavy on ran­dom reads (~11 GB/token), but reads don’t mean­ing­fully wear an SSD — col­i­brì’s stream­ing is read-only. The real con­cerns un­der heavy use are (1) swap traf­fic if the sys­tem runs out of RAM (writes do wear the drive — keep a sane –ram bud­get; col­i­brì’s auto-bud­get is de­signed to stay clear of swap) and (2) sus­tained ther­mals: hours at full read duty cy­cle will heat cheaper dri­ves. Monitor drive tem­per­a­ture and health.

Download the model

A pre-con­verted GLM-5.2 int4 model for col­i­brì is avail­able on Hugging Face:

https://​hug­ging­face.co/​jlnsrk/​GLM-5.2-col­ibri-int4

If the MTP files there are still the int4 head (see #8 — sizes 1765523544/2686077736/536747200 = int4, un­us­able), grab the int8 MTP heads from the com­mu­nity clone by matey-0: https://​hug­ging­face.co/​ma­teogr­gic/​GLM-5.2-col­ibri-int4-with-int8-mtp

Download the repos­i­tory and point COLI_MODEL to its di­rec­tory:

COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat

This skips the FP8 → int4 con­ver­sion step en­tirely.

Thanks DatPat for your help!

Quick start

cd c ./setup.sh # checks gcc/​OpenMP, builds, self-tests

# ONE com­mand does every­thing model-side: down­loads GLM-5.2-FP8 shard by shard # (never needs the full 756 GB at once), con­verts to the int4 con­tainer, then # con­verts the MTP head for spec­u­la­tive de­cod­ing. Resumable at any point. # Conversion (only) needs python with: pip in­stall torch safeten­sors hug­ging­face_hub numpy ./coli con­vert –model /nvme/glm52_i4 # ~400 GB free on a real ext4/​NVMe path

# chat — RAM bud­get, ex­pert cache and MTP are all de­tected au­to­mat­i­cally: COLI_MODEL=/nvme/glm52_i4 ./coli chat

Inspect the planned stor­age hi­er­ar­chy be­fore load­ing the model:

COLI_MODEL=/nvme/glm52_i4 ./coli plan COLI_MODEL=/nvme/glm52_i4 ./coli plan –gpu 0,1 –ram 128 –vram 48 –json

# ap­ply the bounded plan to the nor­mal run­ner COLI_MODEL=/nvme/glm52_i4 ./coli chat –auto-tier

coli plan reads only safeten­sors head­ers and re­ports the mod­el’s ex­act dense/​ex­pert foot­print, run­time RAM re­serve, safe ex­pert-cache cap, and bounded VRAM hot tier. Its ver­sioned JSON out­put is in­tended to be shared by the CLI, API server, Web UI, and desk­top shell; it does not al­lo­cate model ten­sors or start in­fer­ence. –auto-tier ap­plies the same plan to chat, run, serve, and bench­marks. It sets the RAM bud­get and con­text im­me­di­ately; the VRAM tier is en­abled only when the cur­rent glm bi­nary is linked with CUDA. Explicit flags and en­vi­ron­ment vari­ables keep prece­dence over au­to­matic val­ues.

The en­gine at run­time is pure C — python is only used by the one-time con­verter.

Windows 11 (native, no WSL)

col­i­brì builds and runs na­tively on Windows 11 x86 – 64 with MinGW-w64. The port adds a _WIN32 com­pat­i­bil­ity layer in c/​com­pat.h that maps POSIX I/O to the Windows API (pread → ReadFile+OVERLAPPED, posix_­fad­vise no-op, aligned al­lo­ca­tion, MoveFileEx re­name, GlobalMemoryStatusEx RAM de­tec­tion). All plat­form dif­fer­ences stay in com­pat.h; the en­gine source is un­changed.

Toolchain: GCC via win­libs or MSYS2 MinGW-w64. Tested with GCC 16.1.0 (x86_64-ucrt-posix-seh).

# One-time tool­chain in­stall (pick one): scoop in­stall mingw-win­libs # portable, no shell needed # or: pac­man -S mingw-w64-x86_64-gcc make # via MSYS2

# Build (from c/ di­rec­tory): make glm.exe # GLM-5.2 en­gine (static, no DLL de­pen­den­cies) make ol­moe.exe # OLMoE en­gine (same shims) make iobench.exe # disk I/O bench­mark make test-c # run C tests make test-python # run Python tests (requires python)

# Verify (tiny model, 2.4 MB): pip in­stall torch trans­form­ers safeten­sors hug­ging­face_hub python tools/​make_glm_o­r­a­cle.py # gen­er­ate tiny or­a­cle SNAP=./glm_tiny TF=1 ./glm.exe 64 16 16 # ex­pect “32/32 po­sizioni”

# Run with real model: SNAP=D:\glm52_i4 ./glm.exe 64 4 16 # batch in­fer­ence python coli chat –model D:\glm52_i4 # in­ter­ac­tive chat python coli serve –model D:\glm52_i4 # OpenAI-compatible API

Status: Phase 1 com­plete (compiles, cor­rect, sta­tic-linked). O_DIRECT (Phase 2), GPU via LoadLibrary on col­i_cuda.dll (Phases G0–G2), and full-model val­i­da­tion are sep­a­rate work­streams. See PORT_WINDOWS_PLAN.md for the full plan.

OpenAI-compatible API

coli serve keeps one model process loaded and ex­poses a text-only OpenAI-compatible HTTP API. The gate­way uses only the Python stan­dard li­brary; in­fer­ence still runs in the same de­pen­dency-free C en­gine.

cd c COLI_MODEL=/nvme/glm52_i4 COLI_API_KEY=local-secret ./coli serve \ –host 127.0.0.1 –port 8000 –model-id glm-5.2-col­ibri

curl http://​127.0.0.1:8000/​v1/​chat/​com­ple­tions \ -H ‘Authorization: Bearer lo­cal-se­cret’ \ -H ‘Content-Type: ap­pli­ca­tion/​json’ \ -d ‘{ “model”: “glm-5.2-colibri”, “messages”: [{“role”: “user”, “content”: “Hello”}], “stream”: true }’

Implemented end­points are GET /v1/models, GET /v1/models/{model}, POST /v1/chat/completions, and legacy POST /v1/completions. Chat and com­ple­tion re­quests sup­port JSON re­sponses, SSE stream­ing, us­age counts, max_­to­kens/​max_­com­ple­tion_­to­kens, tem­per­a­ture, and top_p. The ex­ten­sion en­able_­think­ing: true en­ables GLM-5.2′s rea­son­ing block; the stan­dard rea­son­ing_­ef­fort field also en­ables it un­less set to none.

The first ver­sion is de­lib­er­ately text-only and serves one gen­er­a­tion at a time: the 744B model stays in one per­sis­tent process, so con­cur­rent HTTP re­quests queue in­stead of load­ing du­pli­cate model copies. Tools, im­age/​au­dio in­put, cus­tom stop se­quences, log prob­a­bil­i­ties, and to­ken penal­ties re­turn an ex­plicit er­ror rather than be­ing silently ig­nored. The de­fault bind ad­dress is lo­cal­host; set COLI_API_KEY be­fore ex­pos­ing the server be­yond the ma­chine.

Browser ac­cess from the Vite de­vel­op­ment server and Tauri lo­cal ori­gins is en­abled by de­fault. Repeat –cors-origin https://​your-ui.ex­am­ple to al­low an­other ex­act ori­gin, or use –cors-origin ‘*’ only on a trusted lo­cal net­work.

The en­gine owns one mu­ta­ble KV con­text, so HTTP gen­er­a­tion uses a bounded FIFO ad­mis­sion queue in­stead of pre­tend­ing to run un­safe par­al­lel se­quences. Configure it with –max-queue N (default 8) and –queue-timeout SECONDS (default 300), or the COLI_MAX_QUEUE / COLI_QUEUE_TIMEOUT en­vi­ron­ment vari­ables. Saturated and timed-out re­quests re­ceive OpenAI-shaped HTTP 429 er­rors be­fore stream­ing head­ers are sent. GET /health ex­poses ac­tive/​queued/​com­pleted/​re­jected coun­ters, and suc­cess­ful gen­er­a­tion re­sponses in­clude x-col­ibri-queue-wait-ms.

Isolated KV con­texts

coli serve –kv-slots N al­lo­cates up to 16 in­de­pen­dent se­quence con­texts. Requests se­lect one with the op­tional in­te­ger cache_s­lot field; or­di­nary OpenAI clients omit it and keep the orig­i­nal slot 0 be­hav­ior.

{ “model”: “glm-5.2-colibri”, “messages”: [{“role”: “user”, “content”: “Continue this con­ver­sa­tion”}], “cache_slot”: 1 }

Each slot owns its to­ken his­tory, com­pressed MLA/DSA KV mem­ory, MTP win­dow, and crash-safe per­sis­tence file (.coli_kv, .coli_kv.1, …). The en­gine still ex­e­cutes one se­quence at a time; this es­tab­lishes ex­plicit KV own­er­ship with­out pre­tend­ing that threaded HTTP is con­tin­u­ous batch­ing. RAM ad­mis­sion ac­counts for every con­fig­ured slot. Use COLI_KV_SLOTS=N as the en­vi­ron­ment equiv­a­lent. Start with a small value: at the de­fault 4096-token con­text, every slot costs hun­dreds of MB.

Experimental res­i­dent CUDA back­end

col­i­brì in­cludes an opt-in CUDA back­end for model-res­i­dent ten­sors. Streaming ex­perts de­lib­er­ately re­main on the orig­i­nal CPU path for now: copy­ing an ex­pert from NVMe to the GPU on every use would only re­place the disk bot­tle­neck with a PCIe bot­tle­neck. Resident quan­tized ten­sors are up­loaded lazily once and reused.

cd c make cuda-test CUDA=1 # q8/​q4/​q2/​f32 ker­nel cor­rect­ness make CUDA=1 # op­tional dense-path ex­per­i­ment (hot ex­perts are con­fig­ured be­low) COLI_CUDA=1 COLI_GPU=0 CUDA_DENSE=1 SNAP=/nvme/glm52_i4 ./glm 64 4 4

Requirements: Linux, an NVIDIA dri­ver, and a CUDA Toolkit un­der /usr/local/cuda (override with CUDA_HOME=/path/to/cuda). CUDA_ARCH=native builds for the GPU in the cur­rent ma­chine; set an ex­plicit ar­chi­tec­ture when cross-com­pil­ing. Requesting CUDA with a CPU-only bi­nary, an in­valid de­vice, or an un­avail­able run­time fails at startup in­stead of silently falling back.

The nor­mal make build and run­time be­hav­ior are un­changed. CUDA de­faults to an ex­pert-only ac­cel­er­a­tor: res­i­dent dense/​at­ten­tion ten­sors stay on CPU be­cause fix­ture mea­sure­ments show that mov­ing them does not help while ex­pert I/O is the bot­tle­neck. CUDA_DENSE=1 keeps the ear­lier all-res­i­dent ex­per­i­men­tal path. A mea­sured PIN pro­file can pro­mote its hottest ex­perts into the per­sis­tent VRAM tier while keep­ing the rest in RAM:

STATS=stats.txt SNAP=/nvme/glm52_i4 ./glm 64 4 4 # col­lect rout­ing fre­quen­cies first COLI_CUDA=1 COLI_GPU=0 CUDA_EXPERT_GB=16 \ PIN=stats.txt PIN_GB=160 SNAP=/nvme/glm52_i4 ./glm 64 4 4 # multi-GPU ex­pert tier, 96 GB to­tal bud­get across six de­vices COLI_CUDA=1 COLI_GPUS=0,1,2,3,4,5 CUDA_EXPERT_GB=96 \ PIN=stats.txt PIN_GB=160 SNAP=/nvme/glm52_i4 ./glm 64 4 4

Selected ex­perts are up­loaded dur­ing startup, so ca­pac­ity fail­ures oc­cur be­fore in­fer­ence and the log re­ports their ex­act ten­sor foot­print. The bud­get is clamped against free VRAM af­ter re­serv­ing the pro­jected dense res­i­dent set and 2 GB of run­time head­room per se­lected de­vice. With COLI_GPUS, CUDA_EXPERT_GB is a to­tal bud­get across the de­vice set; ex­perts are as­signed whole to the least-loaded de­vice that can hold them. A NUMA-local RAM back­ing store is not im­ple­mented yet.

Current lim­i­ta­tions: de­vices use in­de­pen­dent con­texts and syn­chro­nous host-staged ac­ti­va­tion copies—there is no P2P/NCCL de­pen­dency yet. The ker­nels are cor­rect­ness-first cus­tom ker­nels rather than cuBLAS/​Ten­sor Core ker­nels. This draft in­ten­tion­ally makes no end-to-end speedup claim be­fore the full model is bench­marked.

For a re­pro­ducible back­end A/B with­out the full check­point, gen­er­ate the de­ter­min­is­tic 313M-parameter glm_­moe_dsa fix­ture and run fixed-to­ken re­play:

cd c python tools/​make_glm_bench_­model.py –output /nvme/colibri-bench-medium –device cuda python tools/​bench­mark_cu­d­a_­fix­ture.py –model /nvme/colibri-bench-medium –gpu 0

The fix­ture has ran­dom weights and is not a lan­guage model. It ex­ists only to pre­serve the real MLA/MoE/streaming shapes and com­pare CPU stream­ing, dense-only CUDA, CPU hot-store, and CUDA hot-ex­pert ex­e­cu­tion with iden­ti­cal re­play to­kens.

Web in­ter­face

web/ con­tains a com­mu­nity-con­tributed browser UI (React + TypeScript, ~390 lines of source, a pure API client — it never touches the en­gine di­rectly):

cd web npm ci && npm run dev # then point it at an OpenAI-compatible end­point

It speaks the stan­dard OpenAI Chat Completions pro­to­col with SSE stream­ing, so it works against the col­i­brì OpenAI-compatible server (in re­view, #21) or any other com­pat­i­ble end­point. Nothing leaves the end­point you con­fig­ure. The ter­mi­nal coli chat re­mains the first-class in­ter­face.

Useful knobs (env or flags): –temp T to­ken sam­pling tem­per­a­ture (default 0.7 + nu­cleus 0.90 — tuned for int4; 0 = greedy), –topp 0.7 adap­tive ex­pert top-p (30 – 40% less disk), –ngen N max to­kens per an­swer (:piu in chat con­tin­ues a trun­cated one), –repin N adapt RAM/VRAM hot ex­perts every N emit­ted to­kens, AUTOPIN=0 dis­able the learn­ing cache’s auto-pin, THINK=1 en­able GLM-5.2′s rea­son­ing block, DRAFT=n MTP draft depth, TF=1 teacher-forc­ing val­i­da­tion, PILOT=1 router-looka­head disk prefetch (experimental — see be­low), CAP_RAISE=0 don’t auto-grow the ex­pert cache.

The ex­pert cache auto-sizes to your RAM (since 2026 – 07-10): the en­gine now raises the LRU cap to fill your –ram bud­get in­stead of only low­er­ing it. Before this fix a 128 GB ma­chine ran with the same 8-experts/layer cache as a 16 GB one (issue #12) — if you bench­marked col­i­brì be­fore this date, re­run: your num­bers were capped.

Router-lookahead prefetch (PILOT=1, ex­per­i­men­tal): GLM-5.2′s ex­pert rout­ing is mea­sur­ably pre­dictable ahead of time — ap­ply­ing layer L+1′s router to layer L’s post-at­ten­tion state re­calls 71.6% of the true top-8 (vs 41.3% for “same ex­perts as last to­ken”). PILOT=1 uses this to is­sue next-layer ex­pert reada­head from a ded­i­cated I/O thread while the cur­rent layer com­putes. On our dev box the disk is al­ready ~80% sat­u­rated, so it mea­sures neu­tral; on ma­chines where com­pute and disk are bal­anced (like the Ryzen AI 9 in is­sue #12: 43% disk / 46% mat­mul) it should over­lap real work — mea­sure­ments wel­come.

The learn­ing cache: the en­gine records which ex­perts your us­age ac­tu­ally routes to (.coli_usage next to the model, up­dated every turn) and at startup au­to­mat­i­cally pins the hottest ones in spare RAM. col­i­brì lit­er­ally gets faster the more you use it.

Live tier adap­ta­tion (–repin N, opt-in): at safe turn bound­aries, a de­cay­ing ses­sion heat map re­places cold pinned ex­perts with hot­ter streamed ex­perts. Replacement loads the ex­pert from disk into the ex­ist­ing RAM slot; GPU-backed slots im­me­di­ately re­fresh the same VRAM tier bud­get. A 25% hys­tere­sis and a four-swap limit pre­vent tier thrash­ing. Persistent .coli_usage re­mains the long-term sig­nal and is not de­cayed.

Conversations re­open warm (.coli_kv, since 2026 – 07-10): coli chat per­sists the com­pressed MLA KV-cache to disk af­ter every turn (~182 KB/token, ap­pended in­cre­men­tally, crash-safe). Close the chat, re­open it to­mor­row — the model still re­mem­bers the whole con­ver­sa­tion and zero re-pre­fill hap­pens: val­i­dated byte-iden­ti­cal to an un­in­ter­rupted ses­sion. :reset clears it, KVSAVE=0 dis­ables it.

Got a bet­ter ma­chine? Try it — here’s what to ex­pect

col­i­brì was built on de­lib­er­ately hum­ble hard­ware (12 cores, 25 GB RAM, NVMe be­hind a WSL2 VHDX that caps ran­dom reads at ~1 GB/s). Every one of those con­straints is a knob your ma­chine can turn up. The en­gine needs: Linux (or WSL2), ma­cOS, or Windows 11 na­tively (MinGW-w64); gcc with OpenMP, AVX2, ≥16 GB RAM, and the ~370 GB int4 model on a lo­cal NVMe (ext4/NTFS — never a net­work/​9p mount).

How to test it, in or­der:

cd c && ./setup.sh # build + ar­chi­tec­ture self-test (expects 32/32)

# 1) mea­sure YOUR disk the way the en­gine uses it (parallel 19 MB ran­dom reads): gcc -O2 -fopenmp iobench.c -o iobench ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 0 # buffered, 8 threads ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 1 # O_DIRECT

# 2) chat; watch the per-turn stats line (tok/s, ex­pert hit-rate, RSS): COLI_MODEL=/path/to/glm52_i4 ./coli chat

# 3) record ex­pert us­age, then pin the hottest ex­perts in your spare RAM: STATS=stats.txt ./coli chat PIN=stats.txt PIN_GB=20 ./coli chat # scale PIN_GB to your free RAM

# 4) qual­ity bench­marks (MMLU/HellaSwag/ARC): ./coli bench

Back-of-envelope pre­dic­tions (decode is disk-bound: a cold to­ken costs ~11.4 GB of ex­pert reads; MTP spec­u­la­tion roughly halves the ef­fec­tive cost once the cache is warm; RAM turns cold reads into free cache hits):

These are es­ti­mates, not mea­sure­ments — if you run col­i­brì on se­ri­ous hard­ware, please open an is­sue with your num­bers: real dat­a­points from bet­ter ma­chines are ex­actly what this pro­ject needs next.

Community bench­marks (measured)

Real num­bers from real ma­chines, stock build (setup.sh, gcc 13), greedy de­cod­ing, –ngen 32, MTP ac­tive:

Takeaways: with 24 GB of RAM the en­gine auto-caps the ex­pert cache to 2 slots/​layer, so de­code stays cold even on a disk 2 – 2.7× faster than the dev box — on small-RAM ma­chines the RAM cap, not the disk, is the bind­ing con­straint, ex­actly as the table above pre­dicts; –topp 0.7 alone bought a clean 1.6× end-to-end speedup. The M5 Max dat­a­point lands right on the table’s sec­ond row: ~1 tok/​s of a 744B model on a lap­top SSD — and its 14 GB/s disk shifts the bot­tle­neck back to RAM bud­get and ker­nels. The Framework 13 rows are the cache the­sis proven end-to-end on one ma­chine: 0.29 → 0.37 tok/​s (hit 28% → 66%, spec­u­la­tion fi­nally en­gag­ing at 52% ac­cep­tance) just by giv­ing the cache its RAM — int8 MTP head + a big­ger cap + the learned pin. The cap part is now au­to­matic (cap auto-raise, 2026 – 07-10). The 9950X pair is the clean­est bot­tle­neck ex­per­i­ment yet — same ma­chine, same his­tory, only the disk swapped: ×5.8 disk band­width bought ×2.9 to­kens, and the pro­file flipped from 66% disk to 57% mat­mul. Past ~5 GB/s the disk stops be­ing the story and the CPU (or the CUDA ex­pert tier) be­comes it.

Quality bench­mark — help wanted

I spent a rather em­bar­rass­ing amount of time try­ing to match up Run­ning Train‘s hy­per-re­al­is­tic train lines and Japanese ter­rain with the real world. And in do­ing so, I paid the game the high­est pos­si­ble com­pli­ment. This ex­tra­or­di­nar­ily re­al­is­tic sim made by one-per­son de­vel­op­ment team Novatetsu Games is in fact set in a fic­tional re­gion of Japan, but is cre­ated so lov­ingly that you’ll be­lieve it’s real life.

I’m not ex­actly a train en­thu­si­ast, nor in­deed par­tic­u­larly au fait with the range of train sim games pre­vi­ously avail­able, but in Running Train I’ve found some­thing ab­solutely cap­ti­vat­ing. And most bizarrely, I’ve found that qual­ity not by ac­tu­ally play­ing it, but rather by let­ting it play it­self. While the game en­cour­ages you to mas­ter the rea­son­ably sim­ple con­trols of its range of per­fectly crafted en­gines, you can also just set it to play it­self and then take over the free cam­era as it does. Doing so has brought me so much plea­sure.

Played prop­erly, Run­ning Train asks you to care­fully con­trol your speed, brak­ing, and prompt, safe ar­rival at train sta­tions, and re­wards or pe­nal­izes you ac­cord­ingly. By turn­ing off in-game guides and even the UI, you can earn higher scores and more credit, con­tribut­ing to your over­all rat­ing for each of the 42 dif­fer­ent routes it cur­rently fea­tures. These routes fea­ture ten 12-minute routes on the fic­tional Fukugawa Line, and a fur­ther 32 of hugely vary­ing length on the equally made up Sankai Main Line. They can be as short as six min­utes, or as long as 44, each set at dif­fer­ent times of day.

And oh my good­ness, it’s so pretty. Vast stretches of imag­ined Japanese towns and coun­try­side have been cre­ated (40 kilo­me­ters of track, ap­par­ently), and it’s not just ran­domly placed as­sets. Jumping into that free cam­era, I could­n’t be­lieve it when I no­ticed that even pow­er­lines are log­i­cally placed, with wires be­gin­ning at sub­sta­tions, then stretch­ing across py­lon net­works. Roads are filled with traf­fic, cars are parked in bays out­side apart­ment build­ings, Shinto tem­ples sit on hill­sides, fer­ries bob on the sea while waves lap onto shores.

The key thing about all these de­tails is that…you don’t see most of them from the train! If you stuck with the dri­ver cam, you’d miss al­most all of it. It’s so much ef­fort that the de­vel­op­ers could eas­ily have got­ten away with­out, but it adds so much by be­ing in­cluded. It’s also pos­si­ble to play any of the routes in dif­fer­ent weather con­di­tions, from sunny days to tor­ren­tial rain, or in­deed in ei­ther spring or win­ter, with op­tional bliz­zards cov­er­ing the en­tire game in snow.

Zoom out far enough—and for some rea­son it will let you—and you see the tiles, the roads that don’t line up, and the var­i­ous tricks and tech­niques that al­low it to look so re­al­is­tic from low down. But don’t do that! That’s silly. This is a train sim, not a plane sim, you’ve no busi­ness in the sky.

From those who know what they’re do­ing, Steam re­views could not be more glow­ing. “Honestly, I re­ally, re­ally do not know what to say,” be­gins one, be­fore adding, “Hands down the most beau­ti­ful train sim that has been re­leased on the mar­ket thus far. The mod­el­ing is top tier. The en­vi­ron­ment de­tails, the clouds, the light­ing, the weather ef­fects all of it is just ab­solutely in­sane!”

Another says, “Best train sim­u­la­tor game so far!” while a third com­pli­ments the solo dev for in­clud­ing sup­port for the Zuiki MASCON, a be­spoke pe­riph­eral for train dri­ving sims.

This is all for the Early Access re­lease, and there are still big plans to make the game far more de­tailed. The de­vel­oper wants to add a pas­sen­ger sys­tem (currently the trains run empty) and a con­duc­tor mode, and the ul­ti­mate goal is up to 100 km of track. The hope is to have that all done by the end of next year.

As it is, you can ab­solutely en­joy it as a top-notch train sim, but for me the ex­pe­ri­ence has been about let­ting the model rail­way run it­self as I swoop about in the cam­era. It’s a rare plea­sure.

Running Train is out now in Early Access on Steam for $18.