To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

Here we go again, the tech press is hav­ing an­other AI doom cy­cle.

I’ve pri­mar­ily writ­ten this as a re­sponse to an NYT an­a­lyst paint­ing a com­pletely un­sub­stan­ti­ated, base­less, spec­u­la­tive, out­ra­geous, EGREGIOUS, pre­pos­ter­ous “grim pic­ture” on OpenAI go­ing bust.

Mate come on. OpenAI is not dy­ing, they’re not run­ning out of money. Yes, they’re cre­at­ing pos­si­bly the cra­zi­est cir­cu­lar econ­omy and de­fy­ing every eco­nom­ics law since Adam Smith pub­lished ‘The Wealth of Nations’. $1T in com­mit­ments is gen­uinely in­sane. But I doubt they’re look­ing to be ac­quired; hon­estly by who? you don’t raise $40 BILLION at $260 BILLION VALUATION to get ac­quired. It’s all for the $1T IPO.

But it seems that the pin­na­cle of hu­man in­tel­li­gence: the great­est, smartest, bright­est minds have all come to­gether to… build us an­other ad en­gine. What hap­pened to su­per­in­tel­li­gence and AGI?

See if OpenAI was not a di­rect threat to the cur­rent ad gi­ants would Google be ad­ver­tis­ing Gemini every chance they get? Don’t for­get they’re also cap­i­tal­is­ing on their brand new high-in­tent ad fun­nel by launch­ing ads on Gemini and AI overview.

March: Closed $40B fund­ing round at $260B val­u­a­tion, the largest raise by a pri­vate tech com­pany on record.

July: First $1B rev­enue month, dou­bled from $500M monthly in January.

January 2026: “Both our Weekly Active User (WAU) and Daily Active User (DAU) fig­ures con­tinue to pro­duce all-time-highs (Jan 14 was the high­est, Jan 13 was the sec­ond high­est, etc.)”

January 16, 2026: Announced ads in ChatGPT free and Go tiers.

Yes, OpenAI is burn­ing $8-12B in 2025. Compute in­fra­struc­ture is ob­vi­ously not cheap when serv­ing 190M peo­ple daily.

So let’s try to model their ex­pected ARPU (annual rev­enue per user) by un­der­stand­ing what OpenAI is ac­tu­ally build­ing and how it com­pares to ex­ist­ing ad plat­forms.

The ad prod­ucts they’ve con­firmed thus far:

* Ads at bot­tom of an­swers when there’s a rel­e­vant spon­sored prod­uct or ser­vice based on your cur­rent con­ver­sa­tion

Testing starts “in the com­ing weeks” for logged-in adults in the U. S. on free and Go tiers. Ads will be “clearly la­beled and sep­a­rated from the or­ganic an­swer.” Users can learn why they’re see­ing an ad or dis­miss it.

* Choice and con­trol: Users can turn off per­son­al­iza­tion and clear ad data

* Plus, Pro, Business, and Enterprise tiers won’t have ads

They also men­tioned a pos­si­bil­ity of con­ver­sa­tional ads where you can ask fol­low-up ques­tions about prod­ucts di­rectly.

Revenue tar­gets: Reports sug­gest OpenAI is tar­get­ing $1B in ad rev­enue for 2026, scal­ing to $25B by 2029, though OpenAI has­n’t con­firmed these num­bers pub­licly. We can use these as the con­ser­v­a­tive bench­mark, but know­ing the sheer prod­uct tal­ent at OpenAI, the fund­ing and hunger. I think they’re blow past this.

* Self-serve plat­form: Advertisers bid for place­ments, su­per su­per su­per likely, ex­actly what Google does, prob­a­bly their biggest rev­enue stream.

* Affiliate com­mis­sions: Built-in check­outs so users can buy prod­ucts in­side ChatGPT, OpenAI takes com­mis­sion, sim­i­lar to their Shopify col­lab.

* Sidebar spon­sored con­tent: When users ask about top­ics with mar­ket po­ten­tial, spon­sored info ap­pears in a side­bar marked “Sponsored”

Now let’s com­pare this to ex­ist­ing ad plat­forms:

* How it works: Auction-based sys­tem where ad­ver­tis­ers bid on key­words. Ads ap­pear in search re­sults based on bid + qual­ity score.

* Why it works: High in­tent (search queries) + owns the en­tire ver­ti­cal stack (ad tech, auc­tion sys­tem, tar­get­ing, decades of op­ti­miza­tion)

* Ad rev­enue: [$212.4B in ad rev­enue in the first 3 quar­ters of 2025]https://​www.de­mand­sage.com/​google-ads-sta­tis­tics/ (8.4% growth from 2024′s $273.4B)

* Google does­n’t re­port ARPU so we need to cal­cu­late it: ARPU = $296.2B (projected) ÷ 5.01B = $59.12 per user an­nu­ally.

* How it works: Auction-based pro­moted tweets in time­line. Advertisers only pay when users com­plete ac­tions (click, fol­low, en­gage).

* Why it works: Timeline en­gage­ment, CPC ~$0.18, but does­n’t own ver­ti­cal stack and does it on a smaller scale

* Intent level: High. 2.5B prompts daily in­cludes prod­uct re­search, rec­om­men­da­tions, com­par­isons. More in­tent than Meta’s pas­sive scrolling, com­pa­ra­ble to Google search.

* Scale: 1B WAU by Feb 2026, but free users only (~950M at 95% free tier).

So where should ChatGPT’s ARPU sit?

It sits with Search, not Social.

Which puts it be­tween X ($5.54) and Meta ($49.63). OpenAI has bet­ter in­tent than Meta but worse in­fra­struc­ture. They have more scale than X but no ver­ti­cal in­te­gra­tion. When a user asks ChatGPT “Help me plan a 5-day trip to Kyoto” or “Best CRM for small busi­ness,” that is High Intent. That is a Google-level query, not a Facebook-level scroll.

We al­ready have a bench­mark for this: Perplexity.

In late 2024/2025, re­ports con­firmed Perplexity was charg­ing CPMs ex­ceed­ing $50. This is com­pa­ra­ble to pre­mium video or high-end search, and miles above the ~$2-6 CPMs seen on so­cial feeds.

If Perplexity can com­mand $50+ CPMs with a smaller user base, OpenAI’s “High Agency” prod­uct team will likely floor their pric­ing there.

* 2026: $5.50 (The “Perplexity Floor”) - Even with a clumsy beta and low fill rate, high-in­tent queries com­mand pre­mium pric­ing. If they serve just one ad every 20 queries at a Perplexity-level CPM, they hit this num­ber ef­fort­lessly.

* 2027: $18.00 - The launch of a self-serve ad man­ager (like Meta/Google) al­lows mil­lions of SMBs to bid. Competition dri­ves price.

* 2028: $30.00 - This is where “Ads” be­come “Actions.” OpenAI won’t just show an ad for a flight; they will book it. Taking a cut of the trans­ac­tion (CPA model) yields 10x the rev­enue of show­ing a ban­ner.

* 2029: $50.00 (Suuuuuuuper bull­ish case) - Approaching Google’s ~$60 ARPU. By now, the in­fra­struc­ture is ma­ture, and “Conversational Commerce” is the stan­dard. This is what Softbank is pray­ing will hap­pen.

And we’re for­get­ting that OpenAI have a se­ri­ous se­ri­ous prod­uct team, I don’t doubt for once they’ll be fully ca­pa­ble of build­ing out the stack and in­te­grat­ing ads til they oc­cupy your en­tire sub­con­scious.

In fact they hired Fidji Simo as their “CEO of Applications”, a newly cre­ated role that puts her in charge of their en­tire rev­enue en­gine. Fidji is a Meta pow­er­house who spent a decade at Facebook work­ing on the Facebook App and… ads:

Leading Monetization of the Facebook App, with a fo­cus on mo­bile ad­ver­tis­ing that rep­re­sents the vast ma­jor­ity of Facebook’s rev­enue. Launched new ad prod­ucts such as Video Ads, Lead Ads, Instant Experiences, Carousel ads, etc.

Launched and grew video ad­ver­tis­ing to be a large por­tion of Facebook’s rev­enue.

But 1.5-1.8B free users by 2028? That as­sumes zero com­pe­ti­tion im­pact from any­one, cer­tainly not the loom­ing gi­ant Gemini. Unrealistic.

The main rev­enue growth comes from ARPU scal­ing not just user growth.

Crunching all the num­bers from “High Intent” model, 2026 looks dif­fer­ent.

* 35M pay­ing sub­scribers: $8.4B min­i­mum (conservatively as­sum­ing all at $20/mo Plus tier)

* Definitely higher with Pro ($200/mo) and Enterprise (custom pric­ing)

* ChatGPT does 2.5B prompts daily this is what ad­ver­tis­ers would class as both higher en­gage­ment and higher in­tent than pas­sive scrolling (although you can fit more ads in a scroll than a chat)

* Reality Check: This as­sumes they mon­e­tise typ­i­cal search queries at rates Perplexity has al­ready proven pos­si­ble.

These pro­jec­tions use fu­ture­search.ai’s base fore­cast ($39B me­dian for mid-2027, no ads) + ad­ver­tis­ing over­lay from in­ter­nal OpenAI docs + con­ser­v­a­tive user growth.

Ads were the key to un­lock­ing prof­itabil­ity, you must’ve seen it com­ing, thanks to you not skip­ping that 3 minute health in­sur­ance ad - you, yes you helped us achieve AGI!

Mission align­ment: Our mis­sion is to en­sure AGI ben­e­fits all of hu­man­ity; our pur­suit of ad­ver­tis­ing is al­ways in sup­port of that mis­sion and mak­ing AI more ac­ces­si­ble.

The A in AGI stands for Ads! It’s all ads!! Ads that you can’t even block be­cause they are BAKED into the streamed prob­a­bilis­tic word se­lec­tor pur­pose­fully skewed to out­put the high­est bid­der’s mar­ket­ing copy.

Look on the bright side, if they’re turn­ing to ads it likely means AGI is not on the hori­zon. Your job is safe!

It’s 4:41AM in London, I’m knack­ered. Idek if I’m gonna post this be­cause I love AI and do agree that some things are a nec­es­sary evil to achieve a greater goal (AGI).

Nevertheless, if you have any ques­tions or com­ments, shout me -> os­samachaib.cs@gmail.com.

Believe it or not, A$AP Rocky is a huge fan of ra­di­ance fields.

Yesterday, when A$AP Rocky re­leased the mu­sic video for Helicopter, many view­ers fo­cused on the chaos, the mo­tion, and the un­mis­tak­able early MTV en­ergy of the piece. What’s eas­ier to miss, un­less you know what you’re look­ing at, is that nearly every hu­man per­for­mance in the video was cap­tured vol­u­met­ri­cally and ren­dered as dy­namic splats.

I spoke with Evercoast, the team re­spon­si­ble for cap­tur­ing the per­for­mances, as well as Chris Rutledge, the pro­jec­t’s CG Supervisor at Grin Machine, and Wilfred Driscoll of WildCapture and Fitsū.ai, to un­der­stand how Helicopter came to­gether and why this pro­ject rep­re­sents one of the most am­bi­tious real world de­ploy­ments of dy­namic gauss­ian splat­ting in a ma­jor mu­sic re­lease to date.

The de­ci­sion to shoot Helicopter vol­u­met­ri­cally was­n’t dri­ven by tech­nol­ogy for tech­nol­o­gy’s sake. According to the team, the di­rec­tor Dan Strait ap­proached the pro­ject in July with a clear cre­ative goal to cap­ture hu­man per­for­mance in a way that would al­low rad­i­cal free­dom in post-pro­duc­tion. This would have been ei­ther im­prac­ti­cal or pro­hib­i­tively ex­pen­sive us­ing con­ven­tional film­ing and VFX pipelines.

Chris told me he’d been track­ing vol­u­met­ric per­for­mance cap­ture for years, fas­ci­nated by emerg­ing tech­niques that could en­able vi­su­als that sim­ply weren’t pos­si­ble be­fore. Two years ago, he be­gan pitch­ing the idea to di­rec­tors in his cir­cle, in­clud­ing Dan, as a “someday” work­flow. When Dan came back this sum­mer and said he wanted to use vol­u­met­ric cap­ture for the en­tire video, the pro­lif­er­a­tion of gauss­ian splat­ting en­abled them to take it on.

The aes­thetic leans heav­ily into ki­netic mo­tion. Dancers col­lid­ing, bod­ies sus­pended in midair, chaotic fight scenes, and per­form­ers in­ter­act­ing with props that later dis­solve into some­thing else en­tirely. Every punch, slam, pull-up, and fall you see was phys­i­cally per­formed and cap­tured in 3D.

Almost every hu­man fig­ure in the video, in­clud­ing Rocky him­self, was recorded vol­u­met­ri­cally us­ing Evercoast’s sys­tem. It’s all real per­for­mance, pre­served spa­tially.

This is not the first time that A$AP Rocky has fea­tured a ra­di­ance field in one of his mu­sic videos. The 2023 mu­sic video for Shittin’ Me fea­tured sev­eral NeRFs and even the GUI for Instant-NGP, which you can spot through­out the piece.

The pri­mary shoot for Helicopter took place in August in Los Angeles. Evercoast de­ployed a 56 cam­era RGB-D ar­ray, syn­chro­nized across two Dell work­sta­tions. Performers were sus­pended from wires, hang­ing up­side down, do­ing pull-ups on ceil­ing-mounted bars, swing­ing props, and per­form­ing stunts, all in­side the cap­ture vol­ume.

Scenes that ap­pear sur­real in the fi­nal video were, in re­al­ity, grounded in very phys­i­cal se­tups, such as wooden planks stand­ing in for he­li­copter blades, real wire rigs, and real props. The vol­u­met­ric data al­lowed those el­e­ments to be re­moved, re­com­posed, or en­tirely re­con­tex­tu­al­ized later with­out los­ing the au­then­tic­ity of the hu­man mo­tion.

Over the course of the shoot, Evercoast recorded more than 10 ter­abytes of raw data, ul­ti­mately ren­der­ing roughly 30 min­utes of fi­nal splat­ted footage, ex­ported as PLY se­quences to­tal­ing around one ter­abyte.

That data was then brought into Houdini, where the post pro­duc­tion team used CG Nomads GSOPs for ma­nip­u­la­tion and se­quenc­ing, and OTOY’s OctaneRender for fi­nal ren­der­ing. Thanks to this com­bi­na­tion, the pro­duc­tion team was also able to re­light the splats.

One of the more pow­er­ful as­pects of the work­flow was Evercoast’s abil­ity to pre­view vol­u­met­ric cap­tures at mul­ti­ple stages. The di­rec­tor could see live spa­tial feed­back on set, gen­er­ate quick mesh based pre­views sec­onds af­ter a take, and later re­view fully ren­dered splats through Evercoast’s web player be­fore down­load­ing mas­sive PLY se­quences for Houdini.

In prac­tice, this meant cre­ative de­ci­sions could be made rapidly and cheaply, with­out com­mit­ting to heavy down­stream pro­cess­ing un­til the team knew ex­actly what they wanted. It’s a work­flow that more closely re­sem­bles sim­u­la­tion than tra­di­tional film­ing.

Chris also dis­cov­ered that Octane’s Houdini in­te­gra­tion had ma­tured, and that Octane’s early splat sup­port was far enough along to en­able re­light­ing. According to the team, the abil­ity to re­light splats, in­tro­duce shad­ow­ing, and achieve a more di­men­sional “3D video” look was a ma­jor rea­son the fi­nal aes­thetic lands the way it does.

The team also used Blender heav­ily for lay­out and pre­vis, con­vert­ing splat se­quences into light­weight proxy caches for scene plan­ning. Wilfred de­scribed how WildCapture’s in­ter­nal tool­ing was used se­lec­tively to in­tro­duce tem­po­ral con­sis­tency. In his words, the team de­rived prim­i­tive pose es­ti­ma­tion skele­tons that could be used to trans­fer mo­tion, sup­port col­li­sion se­tups, and al­low Houdini’s sim­u­la­tion toolset to han­dle rigid body, soft body, and more phys­i­cally grounded in­ter­ac­tions.

One re­cur­ring re­ac­tion to the video has been con­fu­sion. Viewers as­sume the im­agery is AI-generated. According to Evercoast, that could­n’t be fur­ther from the truth. Every stunt, every swing, every fall was phys­i­cally per­formed and cap­tured in real space. What makes it feel syn­thetic is the free­dom vol­u­met­ric cap­ture af­fords. You aren’t lim­ited by the cam­er­a’s com­po­si­tion. You have free rein to ex­plore, repo­si­tion cam­eras af­ter the fact, break spa­tial con­ti­nu­ity, and re­com­bine per­for­mances in ways that 2D sim­ply can’t.

In other words, ra­di­ance field tech­nol­ogy is­n’t re­plac­ing re­al­ity. It’s pre­serv­ing every­thing.

A Nobel Peace Prize lau­re­ate re­ceives two cen­tral sym­bols of the prize: a gold medal and a diploma. In ad­di­tion, the prize money is awarded sep­a­rately. Regardless of what may hap­pen to the medal, the diploma, or the prize money, it is and re­mains the orig­i­nal lau­re­ate who is recorded in his­tory as the re­cip­i­ent of the prize. Even if the medal or diploma later comes into some­one else’s pos­ses­sion, this does not al­ter who was awarded the Nobel Peace Prize.

A lau­re­ate can­not share the prize with oth­ers, nor trans­fer it once it has been an­nounced. A Nobel Peace Prize can also never be re­voked. The de­ci­sion is fi­nal and ap­plies for all time.

The Norwegian Nobel Committee does not see it as their role to en­gage in day-to-day com­men­tary on Peace Prize lau­re­ates or the po­lit­i­cal processes that they are en­gaged in. The prize is awarded on the ba­sis of the lau­re­ate’ con­tri­bu­tions by the time that the com­mit­tee’s de­ci­sion is taken.

The Committee does not com­ment on lau­re­ates’ sub­se­quent state­ments, de­ci­sions, or ac­tions. Any on­go­ing as­sess­ments or choices made by lau­re­ates must be un­der­stood as their own re­spon­si­bil­ity.

There are no re­stric­tions in the statutes of the Nobel Foundation on what a lau­re­ate may do with the medal, the diploma, or the prize money. This means that a lau­re­ate is free to keep, give away, sell, or do­nate these items.

A num­ber of Nobel medals are dis­played in mu­se­ums around the world. Several Nobel lau­re­ates have also cho­sen to give away or sell their medals:

* Kofi Annan (Peace Prize 2001): In February 2024, his widow, Nane Annan, do­nated both the medal and the diploma to the United Nations Office in Geneva, where they are now per­ma­nently on dis­play. She stated that she wished his legacy to con­tinue in­spir­ing fu­ture gen­er­a­tions.

* Christian Lous Lange (Peace Prize 1921): The medal of Norway’s first Nobel Peace Prize lau­re­ate has been on long-term loan from the Lange fam­ily to the Nobel Peace Center in Oslo since 2005. It is now dis­played in the Medal Chamber and is the only orig­i­nal Peace Prize medal per­ma­nently ex­hib­ited to the pub­lic in Norway.

* Dmitry Muratov (Peace Prize 2021): The Russian jour­nal­ist sold his medal for USD 103.5 mil­lion in June 2022. The en­tire sum was do­nated to UNICEF’s fund for Ukrainian refugee chil­dren. This is the high­est price ever paid for a Nobel Prize medal.

* David Thouless (Physics Prize 2016): His fam­ily do­nated the medal to Trinity Hall, University of Cambridge, where it is dis­played to in­spire stu­dents.

* James Watson (Medicine Prize 1962): In 2014, his medal was sold for USD 4.76 mil­lion. The con­tro­ver­sial DNA re­searcher stated that parts of the pro­ceeds would be used for re­search pur­poses. The medal was pur­chased by Russian bil­lion­aire Alisher Usmanov, who later re­turned it to Watson.

* Leon Lederman (Physics Prize 1988): He sold his medal in 2015 for USD 765,002 to cover med­ical ex­penses re­lated to de­men­tia.

* Knut Hamsun (Literature Prize 1920): In 1943, the Norwegian au­thor Knut Hamsun trav­elled to Germany and met with Propaganda Minister Joseph Goebbels. After re­turn­ing to Norway, he sent his Nobel medal to Goebbels as a ges­ture of thanks for the meet­ing. Goebbels was ho­n­oured by the gift. The pre­sent where­abouts of the medal are un­known.

Pay what you like

You write a doc­u­ment, hit save, and the file is on your com­puter. It’s yours. You can in­spect it, you can send it to a friend, and you can open it with other apps.

Files come from the par­a­digm of per­sonal com­put­ing.

This post, how­ever, is­n’t about per­sonal com­put­ing. What I want to talk about is so­cial com­put­ing—apps like Instagram, Reddit, Tumblr, GitHub, and TikTok.

What do files have to do with so­cial com­put­ing?

But first, a shoutout to files.

Files, as orig­i­nally in­vented, were not meant to live in­side the apps.

Since files rep­re­sent your cre­ations, they should live some­where that you con­trol. Apps cre­ate and read your files on your be­half, but files don’t be­long to the apps.

Files be­long to you—the per­son us­ing those apps.

Apps (and their de­vel­op­ers) may not own your files, but they do need to be able to read and write them. To do that re­li­ably, apps need your files to be struc­tured. This is why app de­vel­op­ers, as part of cre­at­ing apps, may in­vent and evolve file for­mats.

A file for­mat is like a lan­guage. An app might “speak” sev­eral for­mats. A sin­gle for­mat can be un­der­stood by many apps. Apps and for­mats are many-to-many. File for­mats let dif­fer­ent apps work to­gether with­out know­ing about each other.

SVG is an open spec­i­fi­ca­tion. This means that dif­fer­ent de­vel­op­ers agree on how to read and write SVG. I cre­ated this SVG file in Excalidraw, but I could have used Adobe Illustrator or Inkscape in­stead. Your browser al­ready knew how to dis­play this SVG. It did­n’t need to hit any Excalidraw APIs or to ask per­mis­sions from Excalidraw to dis­play this SVG. It does­n’t mat­ter which app has cre­ated this SVG.

The file for­mat is the API.

Of course, not all file for­mats are open or doc­u­mented.

Some file for­mats are ap­pli­ca­tion-spe­cific or even pro­pri­etary like .doc. And yet, al­though .doc was un­doc­u­mented, it did­n’t stop mo­ti­vated de­vel­op­ers from re­verse-en­gi­neer­ing it and cre­at­ing more soft­ware that reads and writes .doc:

Another win for the files par­a­digm.

The files par­a­digm cap­tures a real-world in­tu­ition about tools: what we make with a tool does not be­long to the tool. A man­u­script does­n’t stay in­side the type­writer, a photo does­n’t stay in­side the cam­era, and a song does­n’t stay in the mi­cro­phone.

Our mem­o­ries, our thoughts, our de­signs should out­live the soft­ware we used to cre­ate them. An app-ag­nos­tic stor­age (the filesys­tem) en­forces this sep­a­ra­tion.

You may cre­ate a file in one app, but some­one else can read it us­ing an­other app. You may switch the apps you use, or use them to­gether. You may con­vert a file from one for­mat to an­other. As long as two apps cor­rectly “speak” the same file for­mat, they can work in tan­dem even if their de­vel­op­ers hate each oth­ers’ guts.

And if the app sucks?

Someone could al­ways cre­ate “the next app” for the files you al­ready have:

Apps may come and go, but files stay—at least, as long as our apps think in files.

See also: File over app

When you think of so­cial apps—In­sta­gram, Reddit, Tumblr, GitHub, TikTok—you prob­a­bly don’t think about files. Files are for per­sonal com­put­ing only, right?

But what if they be­haved as files—at least, in all the im­por­tant ways? Suppose you had a folder that con­tained all of the things ever POSTed by your on­line per­sona:

It would in­clude every­thing you’ve cre­ated across dif­fer­ent so­cial apps—your posts, likes, scrob­bles, recipes, etc. Maybe we can call it your “everything folder”.

Of course, closed apps like Instagram aren’t built this way. But imag­ine they were. In that world, a “Tumblr post” or an “Instagram fol­low” are so­cial file for­mats:

* You post­ing on Tumblr would cre­ate a “Tumblr post” file in your folder.

* You fol­low­ing on Instagram would put an “Instagram fol­low” file into your folder.

* You up­vot­ing on Hacker News would add an “HN up­vote” file to your folder.

Note this folder is not some kind of an archive. It’s where your data ac­tu­ally lives:

Files are the source of truth—the apps would re­flect what­ev­er’s in your folder.

Any writes to your folder would be synced to the in­ter­ested apps. For ex­am­ple, delet­ing an “Instagram fol­low” file would work just as well as un­fol­low­ing through the app. Crossposting to three Tumblr com­mu­ni­ties could be done by cre­at­ing three “Tumblr post” files. Under the hood, each app man­ages files in your folder.

In this par­a­digm, apps are re­ac­tive to files. Every ap­p’s data­base mostly be­comes de­rived data—an app-spe­cific cached ma­te­ri­al­ized view of every­body’s fold­ers.

This might sound very hy­po­thet­i­cal, but it’s not. What I’ve de­scribed so far is the premise be­hind the AT pro­to­col. It works in pro­duc­tion at scale. Bluesky, Leaflet, Tangled, Semble, and Wisp are some of the new open so­cial apps built this way.

It does­n’t feel dif­fer­ent to use those apps. But by lift­ing user data out of the apps, we force the same sep­a­ra­tion as we’ve had in per­sonal com­put­ing: apps don’t trap what you make with them. Someone can al­ways make a new app for old data:

Like be­fore, app de­vel­op­ers evolve their file for­mats. However, they can’t gate­keep who reads and writes files in those for­mats. Which apps to use is up to you.

Together, every­one’s fold­ers form some­thing like a dis­trib­uted so­cial filesys­tem:

I’ve pre­vi­ously writ­ten about the AT pro­to­col in Open Social, look­ing at its model from a web-cen­tric per­spec­tive. But I think that look­ing at it from the filesys­tem per­spec­tive is just as in­trigu­ing, so I in­vite you to take a tour of how it works.

What does a so­cial filesys­tem start with?

How would you rep­re­sent it as a file?

It’s nat­ural to con­sider JSON as a for­mat. After all, that’s what you’d re­turn if you were build­ing an API. So let’s fully de­scribe this post as a piece of JSON:

However, if we want to store this post as a file, it does­n’t make sense to em­bed the au­thor in­for­ma­tion there. After all, if the au­thor later changes their dis­play name or avatar, we would­n’t want to go through their every post and change them there.

So let’s as­sume their avatar and name live some­where else—per­haps, in an­other file. We could leave au­thor: ‘dril’ in the JSON but this is un­nec­es­sary too. Since this file lives in­side the cre­ator’s folder—it’s their post, af­ter all—we can al­ways fig­ure out the au­thor based on whose folder we’re cur­rently look­ing at.

This seems like a good way to de­scribe this post:

But wait, no, this is still wrong.

You see, re­ply­Count, re­post­Count, and like­Count are not re­ally some­thing that the post’s au­thor has cre­ated. These val­ues are de­rived from the data cre­ated by other peo­ple—their replies, their re­posts, their likes. The app that dis­plays this post will have to keep track of those some­how, but they aren’t this user’s data.

So re­ally, we’re left with just this:

Notice how it took some trim­ming to iden­tify which parts of the data ac­tu­ally be­long in this file. This is some­thing that you have to be in­ten­tional about when cre­at­ing apps with the AT pro­to­col. My men­tal model for this is to think about the POST re­quest. When the user cre­ated this thing, what data did they send? That’s likely close to what we’ll want to store. That’s the stuff the user has just cre­ated.

Our so­cial filesys­tem will be struc­tured more rigidly than a tra­di­tional filesys­tem. For ex­am­ple, it will only con­sist of JSON files. To make this more ex­plicit, we’ll start in­tro­duc­ing our new ter­mi­nol­ogy. We’ll call this kind of file a record.

Now we need to give our record a name. There are no nat­ural names for posts. Could we use se­quen­tial num­bers? Our names need only be unique within a folder:

One down­side is that we’d have to keep track of the lat­est one so there’s a risk of col­li­sions when cre­at­ing many files from dif­fer­ent de­vices at the same time.

Instead, let’s use time­stamps with some per-clock ran­dom­ness mixed in:

This is nicer be­cause these can be gen­er­ated lo­cally and will al­most never col­lide.

We’ll use these names in URLs so let’s en­code them more com­pactly. We’ll pick our en­cod­ing care­fully so that sort­ing al­pha­bet­i­cally goes in the chrono­log­i­cal or­der:

Now ls -r gives us a re­verse chrono­log­i­cal time­line of posts! That’s neat. Also, since we’re stick­ing with JSON as our lin­gua franca, we don’t need file ex­ten­sions.

Not all records ac­cu­mu­late over time. For ex­am­ple, you can write many posts, but you only have one copy of pro­file in­for­ma­tion—your avatar and dis­play name. For “singleton” records, it makes sense to use a pre­de­fined name, like me or self:

By the way, let’s save this pro­file record to pro­files/​self:

Note how, taken to­gether, posts/​34qye3­wows2c5 and pro­files/​self let us re­con­struct more of the UI we started with, al­though some parts are still miss­ing:

Before we fill them in, though, we need to make our sys­tem stur­dier.

This was the shape of our post record:

And this was the shape of our pro­file record:

Since these are stored as files, it’s im­por­tant for the for­mat not to drift.

TypeScript seems con­ve­nient for this but it is­n’t suf­fi­cient. For ex­am­ple, we can’t ex­press con­straints like “the text string should have at most 300 Unicode graphemes”, or “the cre­ate­dAt string should be for­mat­ted as date­time”.

We need a richer way to de­fine so­cial file for­mats.

We might shop around for ex­ist­ing op­tions (RDF? JSON Schema?) but if noth­ing quite fits, we might as well de­sign our own schema lan­guage ex­plic­itly geared to­wards the needs of our so­cial filesys­tem. This is what our Post looks like:

We’ll call this the Post lex­i­con be­cause it’s like a lan­guage our app wants to speak.

My first re­ac­tion was also “ouch” but it helped to think that con­cep­tu­ally it’s this:

I used to yearn for a bet­ter syn­tax but I’ve ac­tu­ally come around to hes­i­tantly ap­pre­ci­ate the JSON. It be­ing triv­ial to parse makes it su­per easy to build tool­ing around it (more on that in the end). And of course, we can make bind­ings turn­ing these into type de­f­i­n­i­tions and val­i­da­tion code for any pro­gram­ming lan­guage.

Our so­cial filesys­tem looks like this so far:

The posts/ folder has records that sat­isfy the Post lex­i­con, and the pro­files/ folder con­tains records (a sin­gle record, re­ally) that sat­isfy the Profile lex­i­con.

This can be made to work well for a sin­gle app. But here’s a prob­lem. What if there’s an­other app with its own no­tion of “posts” and “profiles”?

Recall, each user has an “everything folder” with data from every app:

Different apps will likely dis­agree on what the for­mat of a “post” is! For ex­am­ple, a mi­croblog post might have a 300 char­ac­ter limit, but a proper blog post might not.

Can we get the apps to agree with each other?

We could try to put every app de­vel­oper in the same room un­til they all agree on a per­fect lex­i­con for a post. That would be an in­ter­est­ing use of every­one’s time.

For some use cases, like cross-site syn­di­ca­tion, a stan­dard-ish jointly gov­erned lex­i­con makes sense. For other cases, you re­ally want the app to be in charge. It’s ac­tu­ally good that dif­fer­ent prod­ucts can dis­agree about what a post is! Different prod­ucts, dif­fer­ent vibes. We’d want to sup­port that, not to fight it.

Really, we’ve been ask­ing the wrong ques­tion. We don’t need every app de­vel­oper to agree on what a post is; we just need to let any­one “define” their own post.

We could try name­spacing types of records by the app name:

But then, app names can also clash. Luckily, we al­ready have a way to avoid con­flicts—do­main names. A do­main name is unique and im­plies own­er­ship.

Why don’t we take some in­spi­ra­tion from Java?

This gives us col­lec­tions.

A col­lec­tion is a folder with records of a cer­tain lex­i­con type. Twitter’s lex­i­con for posts might dif­fer from Tumblr’s, and that’s fine—they’re in sep­a­rate col­lec­tions. The col­lec­tion is al­ways named like .

For ex­am­ple, you could imag­ine these col­lec­tion names:

You could also imag­ine these slightly whack­ier col­lec­tion names:

* fm.last.scrob­ble_v2 (breaking changes = new lex­i­con, just like file for­mats)

It’s like hav­ing a ded­i­cated folder for every file ex­ten­sion.

To see some real lex­i­con names, check out UFOs and Lexicon Garden.

If you’re an ap­pli­ca­tion au­thor, you might be think­ing:

Who en­forces that the records match their lex­i­cons? If any app can (with the user’s ex­plicit con­sent) write into any other ap­p’s col­lec­tion, how do we not end up with a lot of in­valid data? What if some other app puts junk into “my” col­lec­tion?

The an­swer is that records could be junk, but it still works out any­way.

It helps to draw a par­al­lel to file ex­ten­sions. Nothing stops some­one from re­nam­ing cat.jpg to cat.pdf. A PDF reader would just refuse to open it.

Lexicon val­i­da­tion works the same way. The com.tum­blr in com.tum­blr.post sig­nals who de­signed the lex­i­con, but the records them­selves could have been cre­ated by any app at all. This is why apps al­ways treat records as un­trusted in­put, sim­i­lar to POST re­quest bod­ies. When you gen­er­ate type de­f­i­n­i­tions from a lex­i­con, you also get a func­tion that will do the val­i­da­tion for you. If some record passes the check, great—you get a typed ob­ject. If not, fine, ig­nore that record.

So, val­i­date on read, just like files.

Some care is re­quired when evolv­ing lex­i­cons. From the mo­ment some lex­i­con is used in the wild, you should never change which records it would con­sider valid. For ex­am­ple, you can add new op­tional fields, but you can’t change whether some field is op­tional. This en­sures that the new code can still read old records and that the old code will be able to read any new records. There’s a lin­ter to check for this. (For break­ing changes, make a new lex­i­con, as you would do with a file for­mat.)

Although this is not re­quired, you can pub­lish your lex­i­cons for doc­u­men­ta­tion and dis­tri­b­u­tion. It’s like pub­lish­ing type de­f­i­n­i­tions. There’s no sep­a­rate reg­istry for those; you just put them into a com.at­proto.lex­i­con.schema col­lec­tion of some ac­count, and then prove the lex­i­con’s do­main is owned by you. For ex­am­ple, if I wanted to pub­lish an io.over­re­acted.com­ment lex­i­con, I could place it here:

Then I’d need to do some DNS setup to prove over­re­acted.io is mine. This would make my lex­i­con show up in pdsls, Lexicon Garden, and other tools.

We’ve al­ready de­cided that the pro­file should live in the com.twit­ter.pro­file col­lec­tion, and the post it­self should live in the com.twit­ter.post col­lec­tion:

But what about the likes?

Actually, what is a like?

Design is far more than form or func­tion. It’s the tan­gi­ble ex­pres­sion of a brand’s iden­tity, val­ues, and promise. While a brand de­fines what a com­pany stands for, de­sign gives those as­pi­ra­tions form and sub­stance. Design uniquely de­liv­ers value: vi­su­ally, phys­i­cally, and ex­pe­ri­en­tially.

At ThinkNext Design, every cre­ation be­gins with em­pa­thy and seeks pur­pose. We look to un­der­stand not just what peo­ple need, but what they de­sire. Whether craft­ing some­thing en­tirely new or reimag­in­ing the fa­mil­iar, our work blends aes­thetic re­straint with pur­pose­ful clar­ity.

The re­sult is in­no­v­a­tive de­sign that res­onates emo­tion­ally, per­forms beau­ti­fully, and en­dures as a re­flec­tion of the brand be­hind it. More than 200,000,000 ThinkPads have been sold since 1992, and still count­ing. That did­n’t hap­pen by ac­ci­dent.

By the early 1990′s, the orig­i­nal IBM AS/400 prod­uct line was rapidly los­ing mar­ket share due to a grow­ing per­cep­tion that the prod­uct fam­ily em­ployed out­dated tech­nol­ogy, and was highly over­priced. David led a strate­gic de­sign ini­tia­tive to re­cast that im­age via a sweep­ing change that would for­ever repo­si­tion the sta­tus quo.

The re­sult­ing award win­ning de­sign fea­tured stark black en­clo­sures, dra­matic air in­lets, and sim­ple yet pow­er­ful forms. This was a strik­ing con­trast to the putty col­ored neu­tral ap­pear­ance that had come to dom­i­nate not only the IBM server prod­ucts, but the en­tire in­dus­try. Following the se­ries in­tro­duc­tion, AS/400 Division rev­enues jumped by a dou­ble-digit per­cent­age. Comments of yes­ter­day’s tech­nol­ogy were quickly re­placed by as­so­ci­a­tions with ob­jects such as the in­no­v­a­tive F117a stealth fighter.

AS/400 sys­tems had a con­trol panel that in­cluded spe­cial func­tions that were de­signed to only be ac­cessed by au­tho­rized op­er­a­tors. Restricted ac­cess was achieved us­ing a tra­di­tional stain­less steel key­lock mated to a ro­tat­ing elec­tric switch. Without the key only ba­sic func­tions could be op­er­ated. Unfortunately the as­sem­bly was very costly and the metal key/​lock was a source of po­ten­tial elec­tro­sta­tic dis­charge. The se­cu­rity key­stick elim­i­nated the dated and flawed as­sem­bly en­tirely. Inserting the asym­met­ri­cal key en­abled ac­cess to the re­stricted func­tions, cost a frac­tion of the pre­vi­ous so­lu­tion and elim­i­nated the ESD is­sue al­to­gether.

The soft rim and soft dome caps were added in 1997 cre­at­ing a suite of Trackpoint cap op­tions. The in­tro­duc­tion fol­lowed an ex­haus­tive de­sign-led ini­tia­tive to im­prove the ex­ist­ing cat tongue cap’s com­fort and util­ity. The ef­fort re­vealed that three caps were bet­ter than one, giv­ing the user choice. All three were shipped with every ThinkPad for many years. Only the soft dome cap re­mains in pro­duc­tion.

Prior to the in­tro­duc­tion of the Netfinity 7000, IBM’s PC servers were tower based of­fer­ings that of­ten found them­selves awk­wardly placed on shelves in generic com­puter racks. The Netfinity de­sign elim­i­nated this makeshift ap­proach with a “rack and stack” so­lu­tion. The sys­tem could truly rack mount us­ing in­dus­try stan­dard rails, or stand alone as a tower. The de­sign also in­cluded a stack­ing NetBay with pro­vi­sion for mount­ing rack mounted OEM de­vices with­out pur­chas­ing a full blown rack. Many of the sys­tem com­po­nents, in­clud­ing hard­files, were re­mov­able from the front with­out tools.

The ThinkPad ThinkLight was first in­tro­duced on the ThinkPad i Series 1400. Observing a fel­low air­line pas­sen­ger read­ing us­ing a small light clipped to the top edge of their book, David im­me­di­ately thought this idea could be adapted for use on a lap­top. The fi­nal de­sign used a white LED to il­lu­mi­nate the key­board from the top bezel. It was the in­dus­try’s first, and ar­guably most ef­fec­tive method, of il­lu­mi­nat­ing a lap­top key­board.

The in­tro­duc­tion of the IBM Personal Computer in 1981 was a tech­nol­ogy mile­stone that for­ever changed the world. Subsequent in­no­va­tion, how­ever, was pri­mar­ily lim­ited to tech­nol­ogy ad­vance­ments and im­proved af­ford­abil­ity. In nearly 20 years, lit­tle had been done to dra­mat­i­cally change the de­sign par­a­digm of metal box, chunky mon­i­tor, and key­board. David ini­ti­ated and led a de­sign pro­ject to rein­vent the stan­dard.

Working in close col­lab­o­ra­tion with noted de­signer Richard Sapper, David and his team cre­ated an in­dus­try-lead­ing all-in-one com­puter that cap­i­tal­ized on emerg­ing flat-panel dis­play tech­nol­ogy. The fi­nal, award-win­ning de­sign in­te­grated the mon­i­tor, CPU, and op­ti­cal drive into a re­mark­ably slim pro­file. The op­ti­cal drive was dis­creetly con­cealed within the base struc­ture, drop­ping down smoothly at the touch of a but­ton.

Bucking the trend for bloated, friv­o­lous de­signs, the Aptiva S Series speak­ers were con­ceived to match the unique an­gu­lar de­sign lan­guage of the flat panel based com­puter de­sign. The so­phis­ti­cated desk­top speak­ers could be cus­tomized with brightly col­ored fab­ric grills adding to the pre­mium im­age. The de­sign was se­lected by Dieter Rams for a Best of Category award at the an­nual IF Design Exhibition in Germany.

The ThinkPad X300 stands as a land­mark in in­dus­trial de­sign, prov­ing how dis­ci­plined en­gi­neer­ing and pur­pose­ful aes­thet­ics can re­de­fine an en­tire prod­uct cat­e­gory. Its car­bon-fiber and mag­ne­sium con­struc­tion, metic­u­lously re­fined form, and for­ward-look­ing adop­tion of SSD stor­age and LED back­light­ing po­si­tioned it as a break­through ul­tra­portable long be­fore such fea­tures be­came com­mon­place. Its de­vel­op­ment earned wide­spread at­ten­tion, most no­tably in BusinessWeek’s cover story “The Making of the ThinkPad X300,” which show­cased the in­tense, de­sign-dri­ven ef­fort be­hind the ma­chine. The pro­ject was ex­plored even more deeply in Steve Hamm’s book The Race for Perfect, which chron­i­cled the X300’s cre­ation as an ex­am­ple of am­bi­tious, high-stakes in­no­va­tion. Together, these ac­counts ce­ment the X300’s legacy as one of the most in­flu­en­tial and thought­fully crafted ThinkPads ever made.

Skylight was an early “smartbook” prod­uct de­signed as a light­weight, al­ways-con­nected de­vice that blended el­e­ments of a smart­phone and lap­top. The imag­i­na­tive over­all prod­uct de­sign was cre­ated by Richard Sapper, but the key­board was the work of David and his team. Although the prod­uct was short-lived, the sculpted is­land style key­board was even­tu­ally adopted for use on fu­ture ThinkPad and con­sumer lap­tops. The sculpted key sur­face and unique D-shape aid sub­stan­tially in en­hanc­ing com­fort and im­prov­ing typ­ing ac­cu­racy.

Shortly fol­low­ing the Lenovo ac­qui­si­tion of IBM’s PC busi­ness, the IBM logo was re­moved from ThinkPad. David was a strong pro­po­nent of es­tab­lish­ing ThinkPad as the pri­mary badge on the prod­uct due to the brand’s high recog­ni­tion and sub­se­quent value. He pro­posed us­ing the sub-brand font, nor­mally ap­pear­ing be­low the IBM logo, as ThinkPad’s new word­mark. He en­hanced it with a bright red dot over the let­ter i which was de­rived from the TrackPoint cap. His now iconic con­cept was uni­ver­sally adopted as the new ThinkPad prod­uct badge world­wide in 2007.

In 2010 the dot was en­hanced with a glow­ing red LED that is still in use to­day. The dot glows solid if the ThinkPad is pow­ered on and slowly pulses like a heart­beat when in a sus­pended sleep state. The de­sign draws at­ten­tion and adds life to the brand.

The first-gen­er­a­tion ThinkPad X1 Carbon in­tro­duced a bold new in­ter­pre­ta­tion of clas­sic ThinkPad de­sign. It’s car­bon-fiber re­in­forced chas­sis de­liv­ered ex­cep­tional strength with a re­mark­ably low weight. The sculpted is­land-style key­board, sub­tle red ac­cents, and gen­tly ta­pered edges gave it a mod­ern pre­ci­sion ap­pear­ance with­out sac­ri­fic­ing the brand’s renowned us­abil­ity & iconic vi­sual im­pres­sion.

The scaled-down travel mouse shares it’s es­sen­tial geom­e­try with a mouse orig­i­nally cre­ated for IBM’s Aptiva lineup in the late 1990′s. The char­ac­ter­is­ti­cally low front, gen­er­ously sculpted tail and in­wardly in­clined side sur­faces en­hance er­gonom­ics and daily use. These de­sign con­cepts have been nearly uni­ver­sally adopted by other com­puter/​ac­ces­sory man­u­fac­tur­ers.

When us­ing a tablet as a cam­era the screen cover typ­i­cally flops around since fold­ing it all the way around would block the cam­era. The quick­shot cover elim­i­nates this in­con­ve­nience thanks to a patented fold­ing cor­ner. When folded back, it au­to­mat­i­cally launched the cam­era app to let you take a pic­ture in­stantly. The flop­ping cover an­noy­ance was elim­i­nated.

The rev­o­lu­tion­ary de­sign re­placed the bezel/​box par­a­digm with a form that re­sem­bles a rec­tan­gu­lar tube through which large vol­umes of air pass. The unique ap­pear­ance telegraphs raw power. The de­sign, how­ever, is much more than skin deep. The ma­chine’s in­no­v­a­tive in­te­rior is highly mod­u­lar and elim­i­nates the need for tools to re­place or up­grade key com­po­nents. Flush han­dles are thought­fully in­cor­po­rated in the shell for mov­ing the work­sta­tion.

The pi­o­neer­ing ThinkPad X1 Tablet de­sign fea­tured a uniquely hinged kick­stand that en­abled cus­tomiz­ing the user ex­pe­ri­ence with a sys­tem of snap-on mod­ules. Modules of­fered were the Productivity Module, which added ex­tra bat­tery life and ad­di­tional ports; the Presenter Module, fea­tur­ing a built-in pico pro­jec­tor for crit­i­cal pre­sen­ta­tions; and the 3D Imaging Module, equipped with an Intel RealSense cam­era for depth sens­ing and 3D scan­ning. Together, these mod­ules pro­vided flex­i­ble, on-de­mand func­tion­al­ity while pre­serv­ing the tablet’s porta­bil­ity.

ThinkPad 25 was cre­ated and launched to cel­e­brate the 25th an­niver­sary of the iconic brand. It art­fully blended retro de­sign el­e­ments with mod­ern en­gi­neer­ing. Inspired heav­ily by years of pas­sion­ate cus­tomer feed­back and so­cial-me­dia cam­paigns call­ing for a “classic ThinkPad” re­vival, the pro­ject brought back beloved fea­tures such as the 7-row key­board with blue ac­cents, a tra­di­tion-in­spired ThinkPad logo, and TrackPoint cap op­tions. Wrapped in a soft-touch black chas­sis and pow­ered by con­tem­po­rary hard­ware, the ThinkPad 25 stood as a col­lab­o­ra­tive trib­ute—shaped not only by Lenovo’s de­sign­ers but also by a global com­mu­nity of fans.

Originally writ­ten and de­signed for the 20th an­niver­sary cel­e­bra­tion held at the MoMA. The highly col­lec­table work was up­dated in 2025 for the 25th an­niver­sary lim­ited edi­tion ThinkPad T25. Both book­lets doc­u­ment and il­lu­mi­nate David Hill’s be­liefs and philoso­phies that have shaped the de­sign of ThinkPad for decades.

The ThinkPad ThinkShutter is a sim­ple, built-in me­chan­i­cal pri­vacy cover de­signed to give users in­stant con­trol over their we­b­cam. Sliding smoothly across the lens, it pro­vides a clear vi­sual in­di­ca­tion when the cam­era is phys­i­cally blocked, elim­i­nat­ing re­liance on ques­tion­able soft­ware con­trols or LED in­di­ca­tors. It in­te­grates cleanly into the dis­play bezel adding neg­li­gi­ble thick­ness. Achieving peace of mind with makeshift so­lu­tions such as mask­ing tape, Post-it notes, and even clothes­pins are a thing of the past.

This pro­gram gen­er­ates im­ages from text prompts (and op­tion­ally from other im­ages) us­ing the FLUX.2-klein-4B model from Black Forest Labs. It can be used as a li­brary as well, and is im­ple­mented en­tirely in C, with zero ex­ter­nal de­pen­den­cies be­yond the C stan­dard li­brary. MPS and BLAS ac­cel­er­a­tion are op­tional but rec­om­mended.

I (the hu­man here, Salvatore) wanted to test code gen­er­a­tion with a more am­bi­tious task, over the week­end. This is the re­sult. It is my first open source pro­ject where I wrote zero lines of code. I be­lieve that in­fer­ence sys­tems not us­ing the Python stack (which I do not ap­pre­ci­ate) are a way to free open mod­els us­age and make AI more ac­ces­si­ble. There is al­ready a pro­ject do­ing the in­fer­ence of dif­fu­sion mod­els in C / C++ that sup­ports mul­ti­ple mod­els, and is based on GGML. I wanted to see if, with the as­sis­tance of mod­ern AI, I could re­pro­duce this work in a more con­cise way, from scratch, in a week­end. Looks like it is pos­si­ble.

This code base was writ­ten with Claude Code, us­ing the Claude Max plan, the small one of ~80 eu­ros per month. I al­most reached the lim­its but this plan was def­i­nitely suf­fi­cient for such a large task, which was sur­pris­ing. In or­der to sim­plify the us­age of this soft­ware, no quan­ti­za­tion is used, nor do you need to con­vert the model. It runs di­rectly with the safeten­sors model as in­put, us­ing floats.

Even if the code was gen­er­ated us­ing AI, my help in steer­ing to­wards the right de­sign, im­ple­men­ta­tion choices, and cor­rect­ness has been vi­tal dur­ing the de­vel­op­ment. I learned quite a few things about work­ing with non triv­ial pro­jects and AI.

# Build (choose your back­end)

make mps # Apple Silicon (fastest)

# or: make blas # Intel Mac / Linux with OpenBLAS

# or: make generic # Pure C, no de­pen­den­cies

# Download the model (~16GB)

pip in­stall hug­ging­face_hub

python down­load­_­model.py

# Generate an im­age

./flux -d flux-klein-model -p “A woman wear­ing sun­glasses” -o out­put.png

That’s it. No Python run­time, no PyTorch, no CUDA toolkit re­quired at in­fer­ence time.

Generated with: ./flux -d flux-klein-model -p “A pic­ture of a woman in 1960 America. Sunglasses. ASA 400 film. Black and White.” -W 250 -H 250 -o /tmp/woman.png, and later processed with im­age to im­age gen­er­a­tion via ./flux -d flux-klein-model -i /tmp/woman.png -o /tmp/woman2.png -p “oil paint­ing of woman with sun­glasses” -v -H 256 -W 256

* Zero de­pen­den­cies: Pure C im­ple­men­ta­tion, works stand­alone. BLAS op­tional for ~30x speedup (Apple Accelerate on ma­cOS, OpenBLAS on Linux)

./flux -d flux-klein-model -p “A fluffy or­ange cat sit­ting on a win­dowsill” -o cat.png

./flux -d flux-klein-model -p “oil paint­ing style” -i photo.png -o paint­ing.png -t 0.7

The -t (strength) pa­ra­me­ter con­trols how much the im­age changes:

The seed is al­ways printed to stderr, even when ran­dom:

To re­pro­duce the same im­age, use the printed seed:

make # Show avail­able back­ends

make generic # Pure C, no de­pen­den­cies (slow)

make blas # BLAS ac­cel­er­a­tion (~30x faster)

make mps # Apple Silicon Metal GPU (fastest, ma­cOS only)

For make blas on Linux, in­stall OpenBLAS first:

# Ubuntu/Debian

sudo apt in­stall li­bopen­blas-dev

# Fedora

sudo dnf in­stall open­blas-de­vel

make clean # Clean build ar­ti­facts

make info # Show avail­able back­ends for this plat­form

make test # Run ref­er­ence im­age test

The model weights are down­loaded from HuggingFace:

pip in­stall hug­ging­face_hub

python down­load­_­model.py

Inference steps: This is a dis­tilled model that pro­duces good re­sults with ex­actly 4 sam­pling steps.

The text en­coder is au­to­mat­i­cally re­leased af­ter en­cod­ing, re­duc­ing peak mem­ory dur­ing dif­fu­sion. If you gen­er­ate mul­ti­ple im­ages with dif­fer­ent prompts, the en­coder re­loads au­to­mat­i­cally.

* The C im­ple­men­ta­tion uses float32 through­out, while PyTorch uses bfloat16 with highly op­ti­mized MPS ker­nels. The next step of this pro­ject is likely to im­ple­ment such an op­ti­miza­tion, in or­der to reach sim­i­lar speed, or at least try to ap­proach it.

* The generic (pure C) back­end is ex­tremely slow and only prac­ti­cal for test­ing at small sizes.

Dimensions should be mul­ti­ples of 16 (the VAE down­sam­pling fac­tor).

The li­brary can be in­te­grated into your own C/C++ pro­jects. Link against libflux.a and in­clude flux.h.

Here’s a com­plete pro­gram that gen­er­ates an im­age from a text prompt:

#include “flux.h”

#include

gcc -o myapp myapp.c -L. -lflux -lm -framework Accelerate # ma­cOS

gcc -o myapp myapp.c -L. -lflux -lm -lopenblas # Linux

Transform an ex­ist­ing im­age guided by a text prompt. The strength pa­ra­me­ter con­trols how much the im­age changes:

#include “flux.h”

#include

* 0.9 - Almost com­plete re­gen­er­a­tion, keeps only com­po­si­tion

When gen­er­at­ing mul­ti­ple im­ages with dif­fer­ent seeds but the same prompt, you can avoid re­load­ing the text en­coder:

flux_ctx *ctx = flux_load­_dir(“flux-klein-model”);

flux_­params params = FLUX_PARAMS_DEFAULT;

params.width = 256;

params.height = 256;

/* Generate 5 vari­a­tions with dif­fer­ent seeds */

for (int i = 0; i < 5; i++) {

flux_set_seed(1000 + i);

flux_im­age *img = flux_­gen­er­ate(ctx, “A moun­tain land­scape at sun­set”, ¶ms);

char file­name[64];

snprintf(file­name, sizeof(file­name), “landscape_%d.png”, i);

flux_im­age_save(img, file­name);

flux_im­age_free(img);

flux_free(ctx);

Note: The text en­coder (~8GB) is au­to­mat­i­cally re­leased af­ter the first gen­er­a­tion to save mem­ory. It re­loads au­to­mat­i­cally if you use a dif­fer­ent prompt.

All func­tions that can fail re­turn NULL on er­ror. Use flux_get_er­ror() to get a de­scrip­tion:

flux_ctx *ctx = flux_load­_dir(“nonex­is­tent-model”);

if (!ctx) {

fprintf(stderr, “Error: %s\n”, flux_get_er­ror());

/* Prints some­thing like: “Failed to load VAE - can­not gen­er­ate im­ages” */

re­turn 1;

flux_ctx *flux_load_dir(const char *model_dir); /* Load model, re­turns NULL on er­ror */

void flux_free(flux_ctx *ctx); /* Free all re­sources */

flux_im­age *flux_generate(flux_ctx *ctx, const char *prompt, const flux_­params *params);

flux_im­age *flux_img2img(flux_ctx *ctx, const char *prompt, const flux_im­age *input,

const flux_­params *params);

flux_im­age *flux_image_load(const char *path); /* Load PNG or PPM */

int flux_im­age_save(const flux_im­age *img, const char *path); /* 0=success, -1=error */

flux_im­age *flux_image_resize(const flux_im­age *img, int new_w, int new_h);

void flux_im­age_free(flux_im­age *img);

void flux_set_seed(in­t64_t seed); /* Set RNG seed for re­pro­ducibil­ity */

const char *flux_get_error(void); /* Get last er­ror mes­sage */

void flux_re­lease_­tex­t_en­coder(flux_ctx *ctx); /* Manually free ~8GB (optional) */

type­def struct {

int width; /* Output width in pix­els (default: 256) */

int height; /* Output height in pix­els (default: 256) */

int num_steps; /* Denoising steps, use 4 for klein (default: 4) */

float guid­ance_s­cale; /* CFG scale, use 1.0 for klein (default: 1.0) */

in­t64_t seed; /* Random seed, -1 for ran­dom (default: -1) */

float strength; /* img2img only: 0.0-1.0 (default: 0.75) */

} flux_­params;

/* Initialize with sen­si­ble de­faults */

#define FLUX_PARAMS_DEFAULT { 256, 256, 4, 1.0f, -1, 0.75f }

Wir nutzen auf un­serer Internetseite das Open-Source-Software-Tool Matomo. Mit Matomo wer­den keine Daten an Server über­mit­telt, die außer­halb der Kontrolle des Bundespresseamts liegen.

Das Tool ver­wen­det Cookies. Mit diesen Cookies kön­nen wir Besuche zählen. Diese Textdateien wer­den auf Ihrem Computer gespe­ichert und machen es dem Bundespresseamt möglich, die Nutzung seiner Webseite zu analysieren. Ihre IP-Adresse ist für uns eine anonyme Kennung; wir haben keine tech­nis­che Möglichkeit, Sie damit als angemelde­ten Nutzer zu iden­ti­fizieren. Sie bleiben als Nutzer anonym.

Wenn Sie mit der Auswertung Ihrer Daten ein­ver­standen sind, dann ak­tivieren Sie bitte diesen Cookie.