Listen to this post:

There’s a story I tell about my first day in STRT-431 at Kellogg School of Management, the in­tro­duc­tory class that every first-year MBA was re­quired to take; I leafed through the read­ings and case stud­ies and was dis­mayed that there weren’t any tech com­pa­nies on the docket. Me be­ing me, I spoke to the pro­fes­sor af­ter class won­der­ing why, and was told that the goal of the course was not to nec­es­sar­ily learn about spe­cific in­dus­tries, but rather to un­cover broadly ap­plic­a­ble uni­ver­sal prin­ci­ples that could be ap­plied to any com­pany in any in­dus­try.

I did not, as I usu­ally tell the story, find this very sat­is­fac­tory: to me the na­ture of tech, par­tic­u­larly the fact that soft­ware and dis­tri­b­u­tion had zero mar­ginal costs (and zero trans­ac­tion costs), was some­thing fun­da­men­tally dif­fer­ent; putting in ze­roes in for­mu­las tends to wreak havoc! I soon re­al­ized, how­ever, that that was my op­por­tu­nity. The fun­da­men­tal in­sight un­der­gird­ing Aggregation Theory is that zero mar­ginal costs leads to fun­da­men­tally dif­fer­ent value chains than peo­ple once ex­pected from the Internet: cen­tral­iza­tion and scale in a world where con­trol­ling de­mand mat­tered more than dis­trib­ut­ing sup­ply.

What is fas­ci­nat­ing about AI, how­ever, is the ex­tent to which those old uni­ver­sal prin­ci­ples are com­ing back to the fore­front. That was never more ap­par­ent than this past week­end, when ar­gu­ments raged on X about the im­pli­ca­tions of Kimi K3, an­other open weights model out of China, ap­proach­ing the state-of-the-art in terms of ca­pa­bil­i­ties. The long and short of it is this: mar­ginal costs are back in a big way, both in terms of short-term im­pli­ca­tions of state-of-the-art free mod­els, and in terms of the long-term struc­ture of the in­dus­try.

COGS Versus R&D

One of the most com­mon mis­con­cep­tions un­der­gird­ing dis­cus­sion of open weights mod­els is that they are cheaper — free, even. After all, you can just down­load the weights, and skip the time and ex­pense and ca­pa­bil­i­ties nec­es­sary to cre­ate your own model. That is, of course, true, but the “free” in this case is a ref­er­ence to the amount you need to spend on re­search and de­vel­op­ment; R&D is a fixed ex­pense that is in­de­pen­dent of the rev­enue you gen­er­ate. If you spend $1 mil­lion in R&D, it does­n’t mat­ter if you do $100 thou­sand in rev­enue or $100 mil­lion; you still spent $1 mil­lion on R&D (it does, of course, im­pact your prof­itabil­ity).

What is re­lated to rev­enue is COGS — cost of goods sold — and COGS is real for AI in a way it has­n’t been for soft­ware for a very long time. Specifically, run­ning in­fer­ence on a model — whether that model be Kimi or Fable — costs money, and the amount of money an AI provider spends on in­fer­ence is, at least in most busi­ness mod­els, di­rectly cor­re­lated to rev­enue. To reuse the above ex­am­ple, gen­er­at­ing $100 mil­lion ver­sus $100 thou­sand in rev­enue will likely re­quire 1,000x COGS. In con­crete terms, if it costs 50 cents to gen­er­ate the to­kens that drive $1 in rev­enue, then $100 mil­lion in rev­enue will have $50 mil­lion in COGS; $100 thou­sand in rev­enue will only have $50 thou­sand in COGS.

The point in terms of open weight mod­els is that they are not free to serve. Kimi K3 costs $3 per mil­lion in­put to­kens, and $15 per mil­lion out­put to­kens; that is cheaper than Sol’s $5 per mil­lion in­put to­kens and $30 per mil­lion out­put to­kens, but that might not even be the right mea­sure­ment.

Tokens Versus Intelligence

Nvidia CEO Jensen Huang has de­scribed what Nvidia is build­ing as “token fac­to­ries”, and from Nvidia’s per­spec­tive that fram­ing makes sense. Nvidia GPUs are model ag­nos­tic: they gen­er­ate to­kens, and do so in the fastest and most ef­fi­cient way pos­si­ble. That leads to mea­sure­ments like to­kens-per-sec­ond, time-to-first-to­ken, to­kens-per-watt, to­ken cost, etc., and Huang ar­gues that these met­rics will be the ba­sis for de­ci­sion-mak­ing.

This is a fram­ing that def­i­nitely made sense dur­ing the first par­a­digm of AI, the ChatGPT era, when to­kens were de­liv­ered straight to the end user. The sec­ond par­a­digm of AI, how­ever, the rea­son­ing era, con­founds this mea­sure­ment. Reasoning en­tails an ex­plo­sion in chain-of-thought to­kens, and dif­fer­ent mod­els need dif­fer­ent amounts of rea­son­ing to­kens to ar­rive at the right an­swer. Kimi, for ex­am­ple, re­port­edly uses sig­nif­i­cantly more to­kens than Sol, ren­der­ing its price ad­van­tage moot. Agents in­tro­duce a sim­i­lar dy­namic: some mod­els are more ef­fi­cient than oth­ers in terms of the num­ber of to­kens they need to ex­e­cute agen­tic work­flows.

What this means is that to­kens are not a com­mod­ity. The defin­ing char­ac­ter­is­tic of a com­mod­ity is that it is fun­gi­ble: a gal­lon of oil is a gal­lon of oil; a ton of cop­per is a ton of cop­per; a bushel of wheat is a bushel of wheat. A to­ken from one model, how­ever, is not the same as a to­ken from an­other model. What is fun­gi­ble is what is con­structed from to­kens, which is to say in­tel­li­gence. In other words, if both Kimi and Sol gen­er­ated the right an­swer, then that an­swer is fun­gi­ble; the dif­fer­ence in to­kens gen­er­ated to get to that right an­swer is a con­trib­u­tor to a dif­fer­ence in COGS.

The COGS for in­tel­li­gence is a func­tion of a few dif­fer­ent fac­tors:

Model foot­print: The weights and run­time state de­ter­mine how much ex­pen­sive mem­ory and how many ac­cel­er­a­tors are re­quired to host each serv­ing replica.

Inference ef­fi­ciency: Architectural choices (e.g. Mixture-of-Experts) re­duce com­pu­ta­tion per gen­er­ated to­ken.

Memory ef­fi­ciency: Architectural choices can re­duce KV cache re­quire­ments, al­low­ing more con­cur­rent re­quests and bet­ter GPU uti­liza­tion.

Serving ef­fi­ciency: Batching, sched­ul­ing, pre­fix caching, and other in­fer­ence op­ti­miza­tions max­i­mize uti­liza­tion and share work across re­quests.

Token ef­fi­ciency: The fewer to­kens re­quired to reach a cor­rect an­swer, the lower the in­fer­ence cost.

The rea­son this mat­ters is that we are rapidly ap­proach­ing a state in which in­tel­li­gence for many eco­nom­i­cally ben­e­fi­cial tasks is in fact a com­mod­ity. Anyone build­ing a ba­sic CRUD app, for ex­am­ple, can likely do so us­ing mod­els from mul­ti­ple providers. And, in a com­mod­ity mar­ket, the route to prof­itabil­ity is not through charg­ing higher prices — again, you can (or will soon be able to) make the ex­act same app us­ing mul­ti­ple mod­els — but rather through hav­ing a su­pe­rior cost struc­ture.

Understanding Commodity Markets

It’s worth step­ping through the me­chan­ics here, be­cause, as I noted a few months ago in Amazon’s Durability, the dy­nam­ics of com­mod­ity mar­kets are not some­thing peo­ple in tech are gen­er­ally fa­mil­iar with:

In com­mod­ity mar­kets, every­one charges the same price, be­cause every­one is sell­ing the same thing; that price is de­ter­mined by sup­ply and de­mand.

The de­mand for a com­mod­ity is a func­tion of price elas­tic­ity: the cheaper the com­mod­ity, the more de­mand there is for it, and vice-versa.

The sup­ply for a com­mod­ity is a func­tion of the mar­ginal cost of pro­duc­ing the com­mod­ity.

The key thing to un­der­stand is that the mar­ginal cost of pro­duc­ing the com­mod­ity dif­fers by sup­plier. What this means in prac­tice is that the sup­plier with the worst cost struc­ture ends up sell­ing the com­mod­ity at their mar­ginal cost (if they can pro­duce at all); the prof­its of every­one else de­pend on the ex­tent to which their cost struc­ture is bet­ter than the mar­ginal sup­plier.

As an ex­am­ple:

Supplier A can pro­duce 10 units of the com­mod­ity for $10 each

Supplier B can pro­duce 10 units of the com­mod­ity for $15 each

Supplier C can pro­duce 10 units of the com­mod­ity for $20 each

Let’s as­sume the price elas­tic­ity is such that there is de­mand for 25 units of the com­mod­ity at $20. That means:

Supplier A will sell 10 units of the com­mod­ity for $20, earn­ing $10/unit

Supplier B will sell 10 units of the com­mod­ity for $20, earn­ing $5/unit

Supplier C will sell 5 units of the com­mod­ity for $20, earn­ing $0/unit

This is­n’t pre­cisely right: the rea­son why Supplier C will bear the short­fall is be­cause Suppliers A and B will be able to slightly un­der­cut them in price, which will of course af­fect de­mand (which is elas­tic), but it makes the point. Supplier A has a great busi­ness, Supplier B has a good busi­ness, and Supplier C is go­ing to go bank­rupt.

Bankruptcy risk is where fixed costs come back to the fore­front: Supplier C has both fixed costs (like po­ten­tially R&D spend) and also may have taken on debt to fi­nance the equip­ment nec­es­sary to pro­duce the com­mod­ity. It can’t price its com­mod­ity with these costs in mind — re­mem­ber, the mar­ket-clear­ing price ap­prox­i­mates the mar­ginal cost of the high­est-cost unit needed to sat­isfy de­mand — but those costs can ab­solutely drive the sup­plier out of busi­ness. And, if that sup­plier goes out of busi­ness, then prices go up, un­til an­other sup­plier de­cides to en­ter (or the other sup­pli­ers ex­pand).

The Intelligence Market

Let’s bring this back to mod­els. Right now, none of the above analy­sis ap­plies be­cause de­mand ex­ceeds sup­ply for fron­tier mod­els, and sup­ply is lim­ited by a lack of com­pute. This com­pute short­age does­n’t just mean that a com­pute sup­plier like Nvidia makes very large mar­gins, but also that Nvidia’s cus­tomers, like SpaceXAI, can turn around and re­sell com­pute at high mar­gins as well to a com­pany like Anthropic. Anthropic, mean­while, can pay the markup be­cause they can sell to­kens with a higher markup still.

It’s not just ex­cess de­mand that gives Anthropic great mar­gins, how­ever: Anthropic and OpenAI likely have among the low­est costs per unit of fron­tier-qual­ity in­tel­li­gence, thanks to model ca­pa­bil­ity, serv­ing scale, and to­ken ef­fi­ciency. They are serv­ing mod­els at a par­tic­u­lar ca­pa­bil­ity level for months be­fore their com­peti­tors, and are si­mul­ta­ne­ously ap­ply­ing the best mod­els to op­ti­miz­ing those costs.

It’s also worth not­ing that the mar­ket is not yet treat­ing in­tel­li­gence like a com­mod­ity: de­mand is for Anthropic and OpenAI specif­i­cally, and much less for mod­els that aren’t as good (thus SpaceXAI and Meta sell­ing ca­pac­ity to Anthropic); one way to think about the push for op­ti­miz­ing cost is that that is a func­tion of defin­ing jobs-to-be-done by in­tel­li­gence level, such that in­tel­li­gence buy­ers can cre­ate a mar­ket where in­tel­li­gence is com­modi­tized. In the long run, how­ever, who­ever is on the fron­tier is the best placed to dom­i­nate non-fron­tier mar­kets as well, which are just the fron­tier mi­nus n-months, i.e. months in which the fron­tier model mak­ers have been op­ti­miz­ing their cost of serv­ing.

All of this is to say that I think the re­ac­tion to Kimi and Chinese mod­els gen­er­ally is pretty over-blown, at least from an eco­nomic per­spec­tive. Right now there is a price um­brella that is down­stream of the lack of com­pute; I highly doubt that Chinese mod­els are cheaper to serve on a mar­ginal cost ba­sis, they just seem cheaper be­cause Anthropic and OpenAI are so sup­ply con­strained that they are charg­ing far more than they would if there were suf­fi­cient sup­ply to meet the de­mand for in­tel­li­gence.

Frontier Lab Paranoia

Why, then, do the model mak­ers in par­tic­u­lar seem so pan­icked about Chinese mod­els?

First, I think the fron­tier labs are an­chored in a world where train­ing costs dom­i­nated their fi­nan­cial mod­el­ing. As long as train­ing con­sumed more GPUs than in­fer­ence, it was crit­i­cal to max­i­mize in­fer­ence rev­enue to help fund the next train­ing run, which meant charg­ing very high prices for in­fer­ence.

Going for­ward, how­ever, I ex­pect the in­fer­ence mar­ket to grow much faster than train­ing costs (and that in­cludes the as­sump­tion that train­ing costs will con­tinue to sky­rocket), which means they re­ally can make it up in vol­ume. It was­n’t clear this would be the case as re­cently as eight months ago, but the agent par­a­digm un­lock is so mas­sive that fron­tier labs should have more con­fi­dence that they can not just sur­vive but thrive with lower prices (once they have suf­fi­cient com­pute).

Second, in­tel­li­gence is­n’t in fact a per­fect com­mod­ity, in part be­cause ap­plied in­tel­li­gence makes it­self smarter. Specifically, who­ever is run­ning in­fer­ence is also col­lect­ing data, and that data goes into mak­ing the next it­er­a­tion of the model bet­ter. This is, on one hand, all the more rea­son for the fron­tier labs to lower prices and in­crease us­age as more com­pute comes on­line; on the other hand, this is why com­pa­nies like Microsoft are in­creas­ingly ob­sessed with help­ing com­pa­nies run their own mod­els. That is much more vi­able if Chinese mod­els are a vi­able al­ter­na­tive.

Third, the other way that fron­tier labs can not only dif­fer­en­ti­ate from Chinese mod­els but also from each other is by con­tin­u­ing to in­te­grate up into the cus­tomer ex­pe­ri­ence. It’s strik­ing the ex­tent to which Claude Code and Codex are prov­ing to be quite sticky; whichever har­ness you start work­ing with is likely to be the one you stick with, and that fig­ures to be even more the case with non-tech­ni­cal users. And, in the long run, this im­per­a­tive to move up the stack does mean that fron­tier mod­els are ab­solutely a threat to soft­ware providers, in­clud­ing Microsoft. On the flip­side, the ex­tent to which soft­ware com­pa­nies who cur­rently own the cus­tomer ex­pe­ri­ence have ac­cess to com­pet­i­tive mod­els is the ex­tent to which they may be able to re­sist the en­croach­ment of the fron­tier labs.

Finally, the ide­o­log­i­cal an­gle of Anthropic in par­tic­u­lar is im­pos­si­ble to ig­nore. This is a com­pany that be­lieves only it can be en­trusted with AI, and the ex­is­tence of open weights al­ter­na­tives strikes a fa­tal blow to that pre­sump­tion.

China’s Motivation

Kimi is­n’t the only new Chinese model; from Bloomberg:

Alibaba Group Holding Ltd. shares rose as much as 5.4% on Monday af­ter the com­pany launched a pre­view ver­sion of its flag­ship Qwen3.8 Max model, de­scrib­ing it as sec­ond only to Anthropic PBC’s Fable 5. The Sunday re­lease came only days af­ter startup Moonshot AI un­veiled a pow­er­ful new of­fer­ing that’s roiled mar­kets and trig­gered con­cern in the US about China clos­ing the gap on global lead­ers like Anthropic and OpenAI. Qwen3.8 Max has 2.4 tril­lion pa­ra­me­ters, join­ing Moonshot’s Kimi K3 in the heavy­weight class. With 2.8 tril­lion pa­ra­me­ters, K3 ri­vals top of­fer­ings and Alibaba is set­ting sim­i­larly high ex­pec­ta­tions.

Developers can now ac­cess Qwen3.8 Max through Alibaba’s cod­ing plat­forms, in­clud­ing Qoder. Alibaba plans to make the model open-weight soon, ex­pand­ing ac­cess be­yond the pre­view re­lease. Interest in these made-in-China ar­ti­fi­cial in­tel­li­gence sys­tems and mod­els is so high that Moonshot was forced to pause tak­ing on new sub­scrip­tions late on Sunday to man­age over­whelm­ing de­mand.

Alibaba Group Holding Ltd. shares rose as much as 5.4% on Monday af­ter the com­pany launched a pre­view ver­sion of its flag­ship Qwen3.8 Max model, de­scrib­ing it as sec­ond only to Anthropic PBC’s Fable 5. The Sunday re­lease came only days af­ter startup Moonshot AI un­veiled a pow­er­ful new of­fer­ing that’s roiled mar­kets and trig­gered con­cern in the US about China clos­ing the gap on global lead­ers like Anthropic and OpenAI. Qwen3.8 Max has 2.4 tril­lion pa­ra­me­ters, join­ing Moonshot’s Kimi K3 in the heavy­weight class. With 2.8 tril­lion pa­ra­me­ters, K3 ri­vals top of­fer­ings and Alibaba is set­ting sim­i­larly high ex­pec­ta­tions.

Developers can now ac­cess Qwen3.8 Max through Alibaba’s cod­ing plat­forms, in­clud­ing Qoder. Alibaba plans to make the model open-weight soon, ex­pand­ing ac­cess be­yond the pre­view re­lease. Interest in these made-in-China ar­ti­fi­cial in­tel­li­gence sys­tems and mod­els is so high that Moonshot was forced to pause tak­ing on new sub­scrip­tions late on Sunday to man­age over­whelm­ing de­mand.

The fact that Qwen3.8 Max will also have open weights is no­table. Alibaba stopped re­leas­ing weights for its lead­ing edge mod­els ear­lier this year, but ap­pears to have re­verted that change; I sus­pect that shift was re­lated to last week’s Xi Jinping speech about AI that dou­bled down on the open weights ap­proach:

We should ad­here to the prin­ci­ple of open­ness and win-win and boost in­no­va­tion-dri­ven de­vel­op­ment. As a new en­gine of world eco­nomic growth and an ac­cel­er­a­tor for the shift of growth dri­vers, AI is mov­ing from the dig­i­tal world into the phys­i­cal world. We should seize this rare, his­toric op­por­tu­nity to en­cour­age open source, open­ness, col­lab­o­ra­tion and shar­ing. We should fa­cil­i­tate tech­no­log­i­cal in­no­va­tion, in­dus­trial de­vel­op­ment and sce­nario-based ap­pli­ca­tion of AI. We should make co­or­di­nated ad­vances in the trans­for­ma­tion and up­grade of tra­di­tional in­dus­tries, the cul­ti­va­tion and growth of emerg­ing in­dus­tries and for­ward-look­ing plan­ning for fu­ture in­dus­tries, so that all sec­tors and busi­nesses can ben­e­fit from AI.

We should ad­here to the prin­ci­ple of open­ness and win-win and boost in­no­va­tion-dri­ven de­vel­op­ment. As a new en­gine of world eco­nomic growth and an ac­cel­er­a­tor for the shift of growth dri­vers, AI is mov­ing from the dig­i­tal world into the phys­i­cal world. We should seize this rare, his­toric op­por­tu­nity to en­cour­age open source, open­ness, col­lab­o­ra­tion and shar­ing. We should fa­cil­i­tate tech­no­log­i­cal in­no­va­tion, in­dus­trial de­vel­op­ment and sce­nario-based ap­pli­ca­tion of AI. We should make co­or­di­nated ad­vances in the trans­for­ma­tion and up­grade of tra­di­tional in­dus­tries, the cul­ti­va­tion and growth of emerg­ing in­dus­tries and for­ward-look­ing plan­ning for fu­ture in­dus­tries, so that all sec­tors and busi­nesses can ben­e­fit from AI.

The strat­egy for China is ob­vi­ous: com­modi­tize your com­ple­ments. Note that Xi ex­plic­itly ties open­ness to AI “moving from the dig­i­tal world into the phys­i­cal world”; the phys­i­cal world is the world dom­i­nated by China, and the coun­try’s lead in ar­eas like ro­bot­ics is go­ing to mas­sively ben­e­fit from widely avail­able AI mod­els.

Along the same lines, China does not want the U.S. to gain an asym­met­ric ad­van­tage in AI; to the ex­tent that China can weaken the U.S. fron­tier labs while strength­en­ing any and all po­ten­tial U.S. ad­ver­saries so much the bet­ter, and it can ben­e­fit from the in­no­va­tion that will at­tach it­self to an open ecosys­tem.

The Distillation Question

By the same to­ken, don’t ex­pect China to do any­thing about dis­til­la­tion at­tacks on the fron­tier labs. I think it is mis­taken to at­tribute all of the suc­cess of Chinese labs to dis­til­la­tion, but it’s just as much of a mis­take to pre­tend like dis­til­la­tion does­n’t give Chinese labs a big ad­van­tage. That ad­van­tage has re­ally come to bear in the last year as post-train­ing re­in­force­ment learn­ing has be­come in­creas­ingly cru­cial to model per­for­mance. Instead of hav­ing to fash­ion re­in­force­ment learn­ing en­vi­ron­ments from scratch, Chinese labs can sim­ply use fron­tier labs mod­els as teach­ers, al­low­ing for rapid im­prove­ment at much lower costs (this is not the only rea­son why Chinese mod­els are cheaper to de­velop, but it’s a big one).

What is in­ter­est­ing is that one of the most im­por­tant use cases for Chinese mod­els in the West is it­self dis­til­la­tion. Thinking Machines, for ex­am­ple, which just re­leased an open-weight model, re­lies on Chinese mod­els to solve the cold start prob­lem for re­in­force­ment learn­ing. Dean Meyer and Konstantine Buhler wrote an ex­cel­lent ar­ti­cle on X ex­plain­ing that dis­til­la­tion means that Western open weight mod­els are fun­da­men­tally dis­ad­van­taged rel­a­tive to China:

Distillation does not ex­plain China’s en­tire open-model lead. Chinese labs have world-class re­searchers, sub­stan­tial com­pute, strong pre-trained mod­els, soft­ware-hard­ware code­sign, and rapidly im­prov­ing post-train­ing ca­pa­bil­i­ties. But dis­til­la­tion com­presses the costly fi­nal gap be­tween a strong base and a near-fron­tier sys­tem. Even if dis­til­la­tion rep­re­sents a smaller share of a Chinese mod­el’s to­tal ca­pa­bil­ity, it rep­re­sents a mean­ing­ful share of its ad­van­tage over American open mod­els.

New en­force­ment mech­a­nisms will make large-scale dis­til­la­tion harder, slower, and more ex­pen­sive for Chinese com­pa­nies. However, en­force­ment will not elim­i­nate dis­til­la­tion backed by state ac­tors. Every Western fron­tier ad­vance there­fore cre­ates an­other teacher for Chinese labs. Western builders must ei­ther re­pro­duce those ca­pa­bil­i­ties in­de­pen­dently or wait to learn from Chinese mod­els. This gap gives Chinese labs a re­cur­ring struc­tural ad­van­tage over Western com­pa­nies.

Distillation does not ex­plain China’s en­tire open-model lead. Chinese labs have world-class re­searchers, sub­stan­tial com­pute, strong pre-trained mod­els, soft­ware-hard­ware code­sign, and rapidly im­prov­ing post-train­ing ca­pa­bil­i­ties. But dis­til­la­tion com­presses the costly fi­nal gap be­tween a strong base and a near-fron­tier sys­tem. Even if dis­til­la­tion rep­re­sents a smaller share of a Chinese mod­el’s to­tal ca­pa­bil­ity, it rep­re­sents a mean­ing­ful share of its ad­van­tage over American open mod­els.

New en­force­ment mech­a­nisms will make large-scale dis­til­la­tion harder, slower, and more ex­pen­sive for Chinese com­pa­nies. However, en­force­ment will not elim­i­nate dis­til­la­tion backed by state ac­tors. Every Western fron­tier ad­vance there­fore cre­ates an­other teacher for Chinese labs. Western builders must ei­ther re­pro­duce those ca­pa­bil­i­ties in­de­pen­dently or wait to learn from Chinese mod­els. This gap gives Chinese labs a re­cur­ring struc­tural ad­van­tage over Western com­pa­nies.

This is a point that bears re­peat­ing: be­cause U.S. open weight model mak­ers must fol­low the fron­tier labs’ terms of ser­vice, they (1) are worse than Chinese al­ter­na­tives and (2) end up dis­till­ing the dis­til­la­tion, just with a de­tour through Chinese labs. Wouldn’t it be bet­ter if west­ern open weight model mak­ers could go to the source?

To that end, here’s an even more in­ter­est­ing ques­tion around dis­til­la­tion: why ex­actly is it bad? After all, what are large lan­guage mod­els but the dis­til­la­tion of all of the knowl­edge on the open Internet, scraped by the fron­tier labs and dis­tilled into the mod­els that are them­selves be­ing dis­tilled? Who is ex­actly be­ing wronged here?

In fact, this para­dox is the so­lu­tion. I be­lieve that open weight mod­els are good for in­no­va­tion (and, per the above, I think that labs on the fron­tier will be fine), but it’s a prob­lem to be de­pen­dent on China. The U.S. should pass a law that (1) makes ex­plicit that col­lect­ing data for train­ing mod­els is fair use, and (2) bars terms of ser­vice that for­bid dis­til­la­tion, for U.S. com­pa­nies at a min­i­mum. Stopping dis­til­la­tion — which is lit­er­ally just query­ing the API — is nearly im­pos­si­ble; the U.S. should go the other way and lean into a new copy­right pol­icy that both in­dem­ni­fies the labs and also guar­an­tees that what they learned fu­els fur­ther in­no­va­tion for every­one else.

The Reason to Be Afraid

This en­tire Article has been an ex­er­cise in de­fus­ing over­re­ac­tion to Kimi K3 specif­i­cally and Chinese open weight mod­els gen­er­ally; how­ever, there is one rea­son to be con­cerned, and that is cy­ber­se­cu­rity. Consider this story from The Stack:

Hugging Face said its pro­duc­tion in­fra­struc­ture was breached by an “autonomous” AI agent sys­tem early last week. The plat­for­m’s se­cu­rity team were ini­tially stymied in their in­ci­dent re­sponse (IR) by un­named US LLM fron­tier model guardrails “which can­not dis­tin­guish an in­ci­dent re­spon­der from an at­tacker,” they said. So Hugging Face’s de­fend­ers turned in­stead to the open-source GLM 5.2 model from China’s Z.ai lab — run­ning it on their own in­fra­struc­ture to analyse the 17,000+ logs, or foot­prints, that the at­tack­ers left be­hind.

That’s a strik­ing pub­lic ad­mis­sion for the New York-headquartered Hugging Face, which lets users col­lab­o­rate on mod­els, datasets and ap­pli­ca­tions, and which this sum­mer hit the $100 mil­lion ARR mark. In an in­ci­dent re­port, the com­pany rec­om­mended that de­fend­ers “have a ca­pa­ble model you can run on your own in­fra­struc­ture [our ital­ics] vet­ted and ready be­fore an in­ci­dent, both to avoid guardrail lock­out and to keep at­tacker data and cre­den­tials from leav­ing your en­vi­ron­ment.”

Hugging Face said its pro­duc­tion in­fra­struc­ture was breached by an “autonomous” AI agent sys­tem early last week. The plat­for­m’s se­cu­rity team were ini­tially stymied in their in­ci­dent re­sponse (IR) by un­named US LLM fron­tier model guardrails “which can­not dis­tin­guish an in­ci­dent re­spon­der from an at­tacker,” they said. So Hugging Face’s de­fend­ers turned in­stead to the open-source GLM 5.2 model from China’s Z.ai lab — run­ning it on their own in­fra­struc­ture to analyse the 17,000+ logs, or foot­prints, that the at­tack­ers left be­hind.

That’s a strik­ing pub­lic ad­mis­sion for the New York-headquartered Hugging Face, which lets users col­lab­o­rate on mod­els, datasets and ap­pli­ca­tions, and which this sum­mer hit the $100 mil­lion ARR mark. In an in­ci­dent re­port, the com­pany rec­om­mended that de­fend­ers “have a ca­pa­ble model you can run on your own in­fra­struc­ture [our ital­ics] vet­ted and ready be­fore an in­ci­dent, both to avoid guardrail lock­out and to keep at­tacker data and cre­den­tials from leav­ing your en­vi­ron­ment.”

It’s dif­fi­cult to over­state how wrong-headed the Trump ad­min­is­tra­tion’s pan­icked re­sponse to Anthropic’s re­lease of Fable was, par­tic­u­larly since it ex­ac­er­bated Anthropic’s worst ten­den­cies in terms of as­sum­ing only they can be trusted with pow­er­ful AI. In a world with only one AI, it might make sense to re­serve the most pow­er­ful cy­ber­se­cu­rity ca­pa­bil­i­ties for the U.S. gov­ern­ment and trusted al­lies; how­ever, that’s not the world we live in.

There are and will be mod­els em­i­nently ca­pa­ble of mount­ing cy­ber­se­cu­rity at­tacks on ex­ist­ing in­fra­struc­ture, and those mod­els will be — al­ready are — widely avail­able. The best de­fense — the only vi­able de­fense, in fact — will be to make sure de­fend­ers have ac­cess to the best mod­els as well. Right now de­fend­ers are ef­fec­tively banned from us­ing Fable or Sol for cy­ber­se­cu­rity be­cause of Trump ad­min­is­tra­tion di­rec­tives; that means the best al­ter­na­tive is us­ing mod­els from a coun­try which has been try­ing to weaken our cy­ber de­fenses for years. This is in­sane!

The bet­ter course is clear: first, loosen Fable and Sol re­stric­tions on cy­ber­se­cu­rity, and sec­ond, en­sure that U.S. open weight model mak­ers are on an equal play­ing field with China. Yes, the fron­tier labs will kick and scream about this, but the Administration should re­al­ize that lis­ten­ing to their histri­on­ics has led the U.S. to a po­si­tion where U.S. com­pa­nies are de­pen­dent on China for their de­fenses. Let the fron­tier labs win by be­ing bet­ter; don’t let them de­fine safety or se­cu­rity, or pull up the lad­der of hu­man­i­ty’s col­lec­tive knowl­edge. China is al­ready hard enough to com­pete with; let­ting them carry the stan­dard for open­ness and in­no­va­tion is sim­ply giv­ing away our biggest ad­van­tage.

The AI Desktop for Knowledge Work

Your in­tel­li­gent lo­cal agent

Deeply con­nected to your lo­cal files. Capable of browser au­toma­tion. Running around the clock. Built for max­i­mum pro­duc­tiv­ity

Set It & Forget It: 24/7 Automation

Your work­flow never sleeps. Powered by a ro­bust built-in Cron en­gine, Kimi Work au­to­mates your repet­i­tive tasks. Whether it’s an early-morn­ing LLM Agent call to draft daily brief­ings, or a mid­night Python script to process mas­sive datasets, Kimi runs qui­etly in the back­ground, ex­actly on time.

WebBridge: Your Autonomous Web Agent

Give Kimi a goal, and watch it nav­i­gate the in­ter­net like a hu­man. Powered by WebBridge, it au­tonomously browses across tabs, ex­tracts crit­i­cal data, and ex­e­cutes multi-step web tasks. You pro­vide the prompt, Kimi han­dles the clicks, scrolls, and re­search.

Try WebBridge

Agent Swarm & Instant Office Creation

Tackle com­plex prob­lems with the power of Swarm Intelligence. Kimi au­to­mat­i­cally co­or­di­nates mul­ti­ple spe­cial­ized agents to break down and solve multi-lay­ered tasks si­mul­ta­ne­ously. Once the re­search is com­plete, seam­lessly con­vert in­sights into pro­fes­sional PowerPoint decks or Excel sheets in sec­onds.

Built for Finance: Native Global Market Data

Meet your desk­top chief an­a­lyst. Kimi Work comes pre-in­te­grated with deep data sources for A-shares, HK stocks, and US eq­ui­ties. Skip the com­plex API se­tups - in­stantly pull earn­ings re­ports, an­a­lyze mar­ket anom­alies, and rec­on­cile spread­sheets through nat­ural con­ver­sa­tion. Gain a cru­cial edge in a fast-paced mar­ket.

Get Started with Kimi Work

Think, cre­ate, and ex­e­cute, all from your desk­top. Kimi Work brings in­tel­li­gence to every step of your work­flow

FAQ

While the Kimi web app is per­fect for quick chat and queries, Kimi Work is a Local Agent de­signed for deep work­flows. It mounts your lo­cal fold­ers, nav­i­gates the web au­tonomously via WebBridge, runs Python code in the back­ground, and ex­e­cutes sched­uled tasks. It’s a sys­tem-level dig­i­tal em­ployee.

You have ab­solute con­trol over your files. The built-in Ask be­fore act­ing safe­guard means Kimi will prompt you for ex­plicit au­tho­riza­tion be­fore it mod­i­fies, over­writes, or runs code within your lo­cal di­rec­to­ries. Nothing hap­pens with­out your con­sent.

WebBridge gives Kimi the abil­ity to use a browser like a hu­man. You can tell it to check the lat­est news on a web­site and sum­ma­rize it, or scrape his­tor­i­cal stock data to your lo­cal Excel. It clicks, scrolls, and ex­tracts data au­tonomously, sav­ing you hours of man­ual work.

Our Cron sched­uler sup­ports LLM Agent Calls, Python/Shell ex­e­cu­tions, and more. You can trig­ger tasks daily, hourly, or con­di­tion­ally. To en­sure tasks run seam­lessly overnight, sim­ply tog­gle the Keep Computer Awake op­tion in your set­tings.

It’s okay to bea lit­tle jelly

Jelly UI is a de­pen­dency-free Web Components li­brary for soft, tac­tile prod­uct in­ter­faces. Real form con­trols meet soft-body physics, with dark mode, right-to-left sup­port and WCAG AA color to­kens built in.

0 de­pen­den­cies 40 cus­tom el­e­ments 1 script tag WCAG AA Dark mode RTL

Scroll the show­case ↓ Read the API ref­er­ence →

<script type=“mod­ule” src=“https://​jelly-ui.com/​pack­age.js”></script>

<jelly-theme mode=“auto”> <jelly-button vari­ant=“mint”>Pub­lish</​jelly-but­ton> </jelly-theme>

It’s been an in­ter­est­ing few weeks for coun­terex­am­ples. This post is ba­si­cally my per­spec­tive of what has been go­ing on in the world of for­mal­iza­tion, AI tools and, in par­tic­u­lar, coun­terex­am­ples.

Unit dis­tance

Two months ago to­day (20th May 2026), ChatGPT dis­proved Erdős’ Unit Distance con­jec­ture in dis­crete geom­e­try. This is now old news but I had to start some­where. The an­nounce­ment was ac­com­pa­nied with tes­ti­monies by hu­man math­e­mati­cians, many of whom I knew and a few of whom I trusted, say­ing that they be­lieved the ar­gu­ment (they had been given early ac­cess to it and had checked it). The ba­sic struc­ture of the proof is that a pro­found the­o­rem in num­ber the­ory due to Golod and Shafarevich from the 1960s could be used to con­struct a coun­terex­am­ple to the con­jec­ture.

It is now 9 years since I had a mid-life cri­sis, re­alised I no longer trusted many hu­man math­e­mati­cians when it comes to tech­ni­cal de­tails, dis­cov­ered Lean, and started to ar­gue that in­ter­ac­tive the­o­rem provers should play an im­por­tant role in the fu­ture of math­e­mat­ics. So of course my first ques­tion was “is the coun­terex­am­ple for­mal­ized in Lean”. The an­swer was “no”.

But un­der a week later (26th May 2026), I got an email from Fields Medallist Mike Freedman. Mike is now the Chief Science Officer for Logical Intelligence, a com­pany co­founded by Turing Award win­ner and “godfather of AI” Yan LeCun. Mike in­formed me that their sys­tem had aut­o­for­mal­ized the en­tire ChatGPT-generated pa­per in Lean and could I take a look. I looked, and my post-doc Thomas Browning looked too. And in­deed this was what Logical Intelligence had done: they had for­mal­ized pre­cisely the state­ment that the pro­found the­o­rem of num­ber the­ory im­plied the Erdős coun­terex­am­ple. Breakthrough LLM-generated math­e­mat­ics be­ing for­mal­ized in real time. Interesting data point.

Of course there is an ele­phant in the room here though, the pro­found the­o­rem of num­ber the­ory which takes 100+ pages to prove (it needs huge chunks of global class field the­ory, a the­ory de­vel­oped at the be­gin­ning of the 20th cen­tury and for which there are still no short proofs; it is prov­ing dif­fi­cult to com­press). In 2025 I had run a Clay Summer School with Richard Hill on the for­mal­iza­tion of class field the­ory, and one year later we have nearly done the lo­cal case (it is the cur­rent PhD pro­ject of my stu­dent Edison Xie); the global case re­mained open, and in­deed in 2025 for­mal­iz­ing global class field the­ory seemed like a fan­tasy.

One month later, on June 26th 2026, my per­cep­tion of what was pos­si­ble again changed. Boris Alexeev an­nounced on the Lean Zulip that he had steered ChatGPT to a com­plete for­mal­iza­tion of the Erdős coun­terex­am­ple, as­sum­ing noth­ing be­yond the ax­ioms of math­e­mat­ics. Boris works at OpenAI and had used their new model Sol to do the aut­o­for­mal­iza­tion. Boris made the code pub­lic and it did not take long for me to re­alise that some­where within all this AI-generated (and some­times hor­ri­ble, al­though some­times de­cent) code was in­deed a proof of some re­ally hard the­o­rems in global class field the­ory. Also of in­ter­est to me was that Sol had gen­er­ated 1.2 mil­lion lines of Lean code in the three weeks that it had worked on the pro­ject. Lean’s fan­tas­tic (declaration of con­flict of in­ter­est: I am a main­tainer) math­e­mat­ics li­brary math­lib is only 2.3 mil­lion lines of code, and took nine years to write. Perhaps it was at this point that the penny re­ally dropped for me — large AI-generated de­vel­op­ments of math­e­mat­ics are in­evitable. One can­not trust AI-generated code so I ran it in a sand­box on my ma­chine (malicious Lean code can run ar­bi­trary com­mands on your com­puter — Lean is a pro­gram­ming lan­guage, af­ter all). Indeed, it was prov­ing non­triv­ial the­o­rems about the co­ho­mol­ogy of num­ber fields. Wow.

Group schemes of or­der n

A week af­ter Boris’ rev­e­la­tion, in early July, I was think­ing hard about how to run my Formalizing Fermat work­shop. This work­shop was spon­sored by Logos Research, who, like Logical Intelligence (and Harmonic and Axiom AI and Moonshot AI and…) have a tool which can aut­o­for­mal­ize math­e­mat­ics — trans­lat­ing it from hu­man lan­guage into Lean — build­ing on math­lib. Logos told me that they were only go­ing to al­low 5 peo­ple at a time to use their sys­tem dur­ing the work­shop, and there were 25 at­ten­dees, so I told all at­ten­dees that I would buy them a Claude Max sub­scrip­tion for a month, so they had some­thing to ex­per­i­ment with when it was­n’t their turn for Logos’ tool. The work­shop was 6th to 10th July, and the Claude Max sub­scrip­tion would give at­ten­dees ac­cess to Claude Fable, at least un­til Tuesday 7th, when it was be­ing switched off. When OpenAI got wind of what I was do­ing, they also of­fered all at­ten­dees free ChatGPT Pro ac­cess for a month; this was a big deal be­cause ChatGPT Sol was com­ing out on the 9th. So ba­si­cally all at­ten­dees would have ac­cess to Sol and Fable for 4 out of the 5 days of the work­shop, and Logos’ tool for the en­tire week. In fact Fable ac­cess was not re­moved on the 7th so we were in even bet­ter shape.

I was not sure how good Logos’ tool was go­ing to be, but I wanted a de­vel­op­ment of the the­ory of fi­nite flat group schemes in Lean for my on­go­ing proof of Fermat’s Last Theorem, so I put up­loaded some clas­sic pa­pers in the area to Fable and ChatGPT, and got them to­gether to write down an ex­po­si­tion of the the­ory in nat­ural lan­guage. I passed this pdf doc­u­ment over to Logos the day be­fore the work­shop, and on the first day of the work­shop they said that one of the claims in the pdf was false and they had found an ex­plicit coun­terex­am­ple. Another coun­terex­am­ple! I took a look and in­deed the LLM-generated pdf was sim­ply wrong at some point when de­scrib­ing a stan­dard con­struc­tion; false alarm. I had missed this my­self though when read­ing through the pdf. Interesting how AI had again found a coun­terex­am­ple. I fixed the pdf. I thought it was in­ter­est­ing that the AI did­n’t just say “I don’t quite fol­low this ar­gu­ment”, it in­stead said “here is a proof that this ar­gu­ment is sim­ply wrong”, a much more pow­er­ful state­ment.

With the de­vel­op­ment of the the­ory of fi­nite flat group schemes back on track, I could re­lax back into the FLT work­shop. On Tuesday 7th July I sat op­po­site Akhil Mathew at lunch; Akhil is a pro­fes­sor of math­e­mat­ics at UChicago and he was an at­tendee who had been ex­per­i­ment­ing with the tools avail­able. We talked about po­ten­tial ques­tions which AI could work on, and Akhil raised the old ques­tion of Grothendieck about whether every fi­nite free group scheme of or­der n was killed by n. Deligne had proved the re­sult in the com­mu­ta­tive case, and Grothendieck had proved it when the base was re­duced; Rene Schoof had proved it in more cases, and there had even been a pa­per by Emiliano Torti pub­lished last year, prov­ing it in even more gen­er­al­ity. I said that I thought that this was a fab­u­lous thing to get AI think­ing about.

The day af­ter the work­shop fin­ished, on Saturday 11th July, I got a DM from Akhil telling me that Sol had found a coun­terex­am­ple. He sent me a 12 page pdf. I im­me­di­ately replied say­ing that I was not read­ing AI-generated in­for­mal math­e­mat­ics and could he please for­mal­ize the en­tire thing in Lean. Four hours later he replied again, say­ing that Fable had aut­o­for­mal­ized the en­tire thing. I scanned over the 1076-line Lean file, check­ing that the code did not delete all the files on my hard drive (Lean is a pro­gram­ming lan­guage, so it can do this). Convinced that it was only the­o­rems, I then com­piled it on my lap­top and it took me un­der 5 min­utes in to­tal to check that (a) the state­ment of the claimed the­o­rem used only con­cepts in math­lib (and thus things like HopfAlgebra can be trusted to mean what math­e­mati­cians think of as Hopf al­ge­bras) (b) the state­ment of the claimed the­o­rem was that there was a coun­terex­am­ple and (c) the proof com­piled. At this point I knew that we had a coun­terex­am­ple — a group scheme of or­der 4 which was not killed by 4. I sug­gested to Akhil that he make a PR to math­lib with the coun­terex­am­ple — which he did. I would have also sug­gested to him that he draft a press re­lease say­ing that a ma­chine had solved a 60-year-old ques­tion of Grothendieck in al­ge­braic geom­e­try, but some­how by this point I was al­most be­com­ing im­mune to all of this. It was­n’t clear to me that the me­dia would even be able to dis­tin­guish be­tween “machine re­solves ques­tion due to Erdős” and “machine re­solves ques­tion due to Grothendieck” even though I per­son­ally found the lat­ter far more in­ter­est­ing. Of course the Grothendieck coun­terex­am­ple was far far eas­ier than the Erdős one (a thou­sand lines, not a mil­lion), all I’m say­ing is that it’s an area of math­e­mat­ics that I per­son­ally find more in­ter­est­ing. I pointed out to Akhil that ma­chines seemed to be get­ting very good at find­ing coun­terex­am­ples and sug­gested that he try the Hodge con­jec­ture next.

Modularity lift­ing the­o­rems

I think it’s worth step­ping back at this point and sur­vey­ing what the at­ti­tudes of hu­man ex­perts to these sorts of things are. On Tuesday (14th July) I went to work at Imperial and the Grothendieck coun­terex­am­ple was the talk of lunch. A mem­ber of the fac­ulty (who I won’t name) said to me that the fact that the coun­terex­am­ple was so easy to find just in­di­cated that hu­mans had not spent enough time think­ing about the prob­lem, im­ply­ing that a 60-year-old ques­tion of Grothendieck was not ac­tu­ally that in­ter­est­ing to work on. I did­n’t tell him that at some point ear­lier in my ca­reer I had spent a week work­ing hard on the prob­lem. In my mind my col­league is just go­ing through the five stages of grief; right now they seem to be in the de­nial phase.

After lunch I met with my PhD stu­dent Andrew Yang, who had been work­ing on for­mal­iz­ing a mod­u­lar­ity lift­ing the­o­rem in Lean, some­thing which is cru­cial to my FLT work. Andrew had come to the Logos FLT work­shop and now had ac­cess to both Sol and Fable. He told me that us­ing these tools he had writ­ten 250K lines of Lean code which ba­si­cally com­pletely fin­ished the pro­ject in what was I guess a 2 week pe­riod.

A few days ear­lier I had got an email from a pro­fes­sor in the maths de­part­ment here at Imperial, ex­press­ing sur­prise that some of our grad­u­ate stu­dents were pay­ing $200 per month to ac­cess mod­els such as Sol and Fable. He said that he thought that these peo­ple were crazy. I did not im­me­di­ately re­spond. But af­ter meet­ing with Andrew I emailed the pro­fes­sor back and told him that in my opin­ion, any PhD stu­dent who was not pay­ing $200 per month to ac­cess these tools was crazy. In fact dur­ing the work­shop I learnt from Harvard PhD stu­dent Bryan Wang that Harvard were al­ready giv­ing free Fable ac­cess to all PhD stu­dents, post-docs and fac­ulty at Harvard.

The Jacobian Conjecture

But back to Akhil. I am not sure if he took my idea to dis­prove the Hodge con­jec­ture se­ri­ously. But it looks like he had deeply un­der­stood that, with these ex­tra­or­di­nary new AI tools, coun­terex­am­ples might be low-hang­ing fruit right now. He had dis­cussed with Levent Alpöge the idea of find­ing more coun­terex­am­ples in al­ge­braic geom­e­try, and 12 hours ago Levent posted on X that Fable had found a coun­terex­am­ple to the Jacobian Conjecture. This is a big deal — this is a fa­mous ques­tion in al­ge­braic geom­e­try which had been open for 100 years and which many peo­ple had thought about. It was ap­par­ently solved dur­ing the 2026 World Cup Final.

I woke up to­day to a DM from Akhil say­ing “shall I make an­other PR?” but this time he was too late — Paul Lezeau had al­ready for­mal­ized the coun­terex­am­ple man­u­ally and had made a PR to DeepMind’s Formal Conjectures repo. Mathlib does not con­tain a large list of con­jec­tures in math­e­mat­ics, but DeepMind’s repo does. The im­por­tance of for­mal­iza­tion of con­jec­tures by hu­mans is that if hu­mans are agreed that a Lean state­ment does faith­fully cap­ture the idea be­hind a con­jec­ture, then check­ing that (possibly AI-generated) Lean code does com­prise a proof or dis­proof of the con­jec­ture is a triv­i­al­ity. Congratulations to Levent, thanks to Akhil for sug­gest­ing the prob­lem to him, and thanks to DeepMind for al­ready hav­ing for­mal­ized the state­ment and thus mak­ing for­mal ver­i­fi­ca­tion of the coun­terex­am­ple a triv­i­al­ity.

The Jacobian con­jec­ture is re­solved! Wow! The next step in that work is for hu­mans to un­der­stand ex­actly what is go­ing on with the ex­am­ple. For the true value of work like this is to give hu­mans bet­ter un­der­stand­ing of math­e­mat­ics. Indeed Akhil has been work­ing on try­ing to un­der­stand the Grothendieck coun­terex­am­ple in a way which is far deeper than “here is a ran­dom pre­sen­ta­tion of a ran­dom ring and a ran­dom cal­cu­la­tion which shows that some­thing does­n’t work”. What we need next is the in­sight which can be drawn from these ex­tra­or­di­nary ex­am­ples.

What a time to be alive.

The ACLU doc­u­ments how an au­to­matic li­cense plate reader com­pany has lied about its op­er­a­tions, sig­nal­ing a need for rep­utable gov­ern­ments to avoid work­ing with Flock Safety.

During a city coun­cil meet­ing in a sub­urb of Wisconsin in April, the city of Oshkosh con­sid­ered whether it should ap­prove a con­tract to use au­to­matic li­cense plate read­ers (ALPR) from Flock Safety, a promi­nent com­pany that pro­vides ALPRs to law en­force­ment agen­cies across the coun­try. During the meet­ing, one city coun­cil mem­ber asked Flock if the com­pa­ny’s ALPR sys­tem cre­ated heat maps that could re­veal where a par­tic­u­lar ve­hi­cle had dri­ven over a pe­riod of time. Flock’s chief in­for­ma­tion se­cu­rity of­fi­cer, who was in at­ten­dance, told the coun­cil that Flock’s sys­tem did not “create a pat­tern or heat map of an in­di­vid­u­al’s move­ment” through the track­ing of their ve­hi­cles. At the end of that meet­ing, the Oshkosh City Council ap­proved a con­tract with Flock. The very next morn­ing, the city learned that Flock had lied.

Later that day, the city coun­cil re­con­vened to dis­cuss what it had learned. Confronting Flock, Oshkosh Deputy Mayor Joe Stephenson said “I don’t know how this body can gov­ern if some­one tells un­truths, mis­truths, ex­ag­ger­ated truths. I don’t know how I can make a de­ci­sion or dis­cern what’s right or what’s wrong, or even the ca­pa­bil­i­ties of this sys­tem if you lie to me.”

“Shame on them,” Oshkosh Mayor Matt Mugerauer added. “All I’m say­ing is if you give bad in­for­ma­tion, then I just don’t want to work with you.”

Ultimately, the Oshkosh City Council voted to im­me­di­ately re­voke its ap­proval, thereby set­ting a record for the short­est time be­tween a city ap­prov­ing and can­celling a Flock con­tract: one day.

Flock later ad­mit­ted that its ALPR sys­tem does in­deed pro­duce a “heat map” that shows where “point-in-time im­ages have been cap­tured of a ve­hi­cle” for up to an en­tire month. However, the com­pany chose to re­spond to the re­vo­ca­tion of its con­tract by at­tack­ing the City of Oshkosh and its city coun­cil, com­plain­ing that Flock had “not [been] af­forded the op­por­tu­nity” to ex­plain its lie af­ter be­ing caught. Flock also sought to triv­i­al­ize its fac­tu­ally in­ac­cu­rate state­ment by cat­e­go­riz­ing it as “one small mis­con­cep­tion” and re­fer­ring to the dis­pute over the sys­tem’s heat map track­ing fea­ture as “a mi­nor nu­ance.”

What hap­pened in Oshkosh was not an iso­lated in­ci­dent. Rather, it re­flects a pat­tern of Flock reg­u­larly mis­lead­ing or even ly­ing about its busi­ness prac­tices, safety record, com­mit­ment to pri­vacy, and ef­forts to pro­tect vul­ner­a­ble pop­u­la­tions. And as was the case in Oshkosh, Flock’s lies are not just di­rected at the gen­eral pub­lic; they of­ten specif­i­cally tar­get Flock’s po­ten­tial gov­ern­ment cus­tomers. The ur­gent take­away for gov­ern­ment of­fi­cials and po­lice de­part­ments is that they should be ex­tremely hes­i­tant to be­lieve any­thing Flock’s tells them about its com­pany, its prod­ucts, or its com­mit­ment to safety and pri­vacy.

Flock’s Pattern of Lies

This is far from the first time Flock has mis­led the pub­lic and elected of­fi­cials. The com­pany has demon­strated a pat­tern of treat­ing le­git­i­mate op­er­a­tional ques­tions and con­cerns not as prob­lems to be solved, but rather as mere pub­lic re­la­tions is­sues.

In Colorado, Loveland Police Chief Tim Doran raised con­cern that fed­eral agents were ac­cess­ing the town’s ALPR data. Flock re­sponded by telling the chief that fed­eral agen­cies no longer had ac­cess to Loveland’s li­cense plate read­ers, and had their CEO re­it­er­ate to the press that fed­eral data shar­ing was a non-is­sue be­cause Flock had no fed­eral con­tracts. After con­tra­dic­tory in­for­ma­tion later came to light, the com­pany was forced to ad­mit that it did, in fact, have con­tracts with U.S. Customs and Border Protection (CBP) and Homeland Security (DHS) for pi­lot pro­jects that gave those agen­cies di­rect ac­cess to li­cense data. “We clearly com­mu­ni­cated poorly,” Flock’s CEO said, ac­knowl­edg­ing that Flock’s “public state­ments in­ad­ver­tently pro­vided in­ac­cu­rate in­for­ma­tion.”

Last year, re­ports re­vealed that, even in the ab­sence of fed­eral con­tracts, co­op­er­at­ing po­lice of­fi­cers and de­part­ments were reg­u­larly shar­ing Flock ALPR data and search re­sults with im­mi­gra­tion agen­cies like U.S. Immigration and Customs Enforcement (ICE) and CBP. The com­pany re­sponded to the re­ports with a disin­gen­u­ous blog en­ti­tled “Does Flock Share Data With ICE? No. Flock Does Not Work With ICE.” In its blog, the com­pany pushed back by as­sert­ing that “ICE does not have di­rect ac­cess to Flock cam­eras, sys­tems, or data” and that li­cense data is “owned and con­trolled by the cus­tomer.”

Flock knew that, de­spite not be­ing a cus­tomer, ICE had in­di­rect ac­cess to Flock’s data and sys­tem through the com­pa­ny’s state and lo­cal law en­force­ment cus­tomers. The is­sue was never about hav­ing di­rect ac­cess to Flock’s data, it was about hav­ing any ac­cess to the data. But rather than ad­dress these data se­cu­rity and con­trol is­sues on their mer­its, Flock re­leased a mis­lead­ing blog which reads as an at­tempt to con­fuse the pub­lic and cre­ate a false sense of se­cu­rity among its po­ten­tial gov­ern­ment cus­tomers. Ultimately, Flock was forced to ac­cept that its de­nials were sim­ply not cred­i­ble. The CEO ad­mit­ted Flock was used for im­mi­gra­tion en­force­ment but ar­gued that such mat­ters were not Flock’s prob­lem.

In May 2025, the press be­gan re­port­ing that Flock’s ALPR sys­tem had been used by law en­force­ment in at least one state, Texas, to track down a per­son seek­ing abor­tion care in an­other state, Illinois. Flock sought to as­suage con­cerns about its sys­tem be­ing used for cross-state abor­tion en­force­ment by un­veil­ing “New Product Solutions to Strengthen Compliance” led by its “Proactive Search Term Tool.” In de­scrib­ing this new tool, Flock wrote:

While Flock claimed its new over­sight tool would “significantly” re­duce the risk of im­proper uses like abor­tion en­force­ment, in re­al­ity the tool does­n’t work. As an in­ves­ti­ga­tion by our col­leagues at the ACLU of Massachusetts found, Flock net­work au­dits showed po­lice fre­quently en­ter vague terms like “investigation” or “susp” in­stead of in­for­ma­tion about the sub­stance of the in­ves­ti­ga­tion into the search rea­son field. In September 2025 alone, a lo­cal Oregon po­lice de­part­ment was al­lowed to search Flock’s ALPR sys­tem af­ter en­ter­ing “investigation” into the search rea­son field 111 times and “hehehe” into the field on 20 oc­ca­sions, which demon­strates how easy it is to search Flock’s sys­tem while avoid­ing se­cu­rity-trig­ger­ing words like “abortion.” Flock cer­tainly would have known, if it con­ducted even a rudi­men­tary test of its sys­tem, that the search field’s pro­tec­tions were ex­tremely sim­ple to cir­cum­vent. Nevertheless, Flock’s fi­nan­cial in­ter­ests ap­pear to have been bet­ter served by the com­pany mis­rep­re­sent­ing the ef­fi­cacy of its se­cu­rity fea­tures to the pub­lic and its po­ten­tial gov­ern­ment cus­tomers.

Flock Even Lies About Partnering with the ACLU

Flock has even made false claims to the pub­lic and elected of­fi­cials about work­ing with the ACLU. Earlier this year, af­ter the ACLU of New Mexico and Flock sup­ported the same state-level ALPR leg­is­la­tion — al­beit for very dif­fer­ent rea­sons — Flock’s Senior Director of Public Affairs took to so­cial me­dia to claim that Flock part­nered with the ACLU of New Mexico to craft the bill and pass it.

This was not the first time the ACLU has caught Flock falsely claim­ing to have worked with us. During an Urbana, Illinois City Council meet­ing in 2021, the com­pany told coun­cilmem­bers 23 min­utes into the dis­cus­sion that “Flock has worked with groups like the ACLU to de­sign an ALPR sys­tem that takes con­sid­er­a­tions they have into ac­count.”

To be clear, nei­ther the ACLU nor any of our af­fil­i­ates have ever part­nered with Flock Safety or worked with them to de­sign any ALPR sys­tem. As an or­ga­ni­za­tion that has spent 106 years earn­ing our good name and rep­u­ta­tion, we can con­fi­dently ad­vise Flock that ly­ing to the pub­lic and elected of­fi­cials about your work and your re­la­tion­ships is not how you get there.

Ultimately, rep­utable gov­ern­ments should not do busi­ness with dis­rep­utable com­pa­nies. While gov­ern­ments should think long and hard about not us­ing ALPRs, if lo­cal gov­ern­ments in­sist on do­ing so, at a bare min­i­mum, they should adopt strong guardrails gov­ern­ing fu­ture ALPR use — in­clud­ing strictly lim­it­ing data re­ten­tion, data shar­ing, and what crimes they can be used to en­force. And, of course, they should refuse to part­ner with any com­pany that reg­u­larly mis­leads the pub­lic, elected of­fi­cials, and even its own cus­tomers.

Latest re­lease · 100% open source · live now

Run AI mod­el­slo­cally on your Mac.

Nativ puts fron­tier in­tel­li­gence on your desk. Download and run open mod­els on Apple Silicon — no ac­counts, no sub­scrip­tions, no cloud.

Universal · Apple Silicon (M1+)

Nativ, run­ning on ma­cOS­Real app. Real lo­cal mod­els. No cloud.

01 / CHAT

Talk to open mod­els with stream­ing re­sponses and per-mes­sage per­for­mance met­rics.

CAPTURED LIVE ON THIS MAC · JUL 2026

/ SIX REASONS TO GO LOCAL

Everything you need.Noth­ing you don’t.

Pick the right model for your Mac

Run stand­out open mod­els from Google, Cohere, and Liquid AI. Nativ rec­om­mends the right part­ner model for your hard­ware.

Prompt it like you would Claude

A clean in­ter­face with stream­ing, mark­down, code high­light­ing, and im­age in­put. Every re­sponse is gen­er­ated lo­cally.

See what’s ac­tu­ally hap­pen­ing

Live to­kens/​sec, mem­ory pres­sure, ther­mal state, and time-to-first-to­ken. The de­tails de­vel­op­ers want.

Optimized for Apple Silicon

Built on MLX-VLM and tuned for M-series uni­fied mem­ory and Metal — no wrap­pers, no trans­la­tion lay­ers.

Language, vi­sion, video, code, au­dio

Chat with an LLM, cap­tion an im­age, sum­ma­rize video, au­to­com­plete code, or tran­scribe and gen­er­ate speech.

Not a SaaS.Not a sub­scrip­tion.

No ac­counts to cre­ate, no cred­its to buy, no data to sell. You own it end-to-end.

/ INTEGRATIONS

Your tools.Your mod­els.

Connect the cod­ing agents you al­ready use to mod­els run­ning lo­cally on your Mac. Nativ han­dles the end­point; your work­flow stays fa­mil­iar.

01Pi 02Codex 03Claude Code 04Hermes 05OpenCode

MANIFESTO · REV 1.0

Why we’re open source­when no­body else is.

phi­los­o­phy.tx­tUTF-8

$ cat phi­los­o­phy.txt

The other “local AI” apps you’ve heard of? They’re pro­pri­etary shells built on top of open-source en­gines they don’t own. They keep the UI closed, add a pay­wall, and hope you don’t look un­der the hood.

We built in the open. The desk­top app is open too. Every line. Every model loader. Every teleme­try chart. You can read it, fork it, or send a pull re­quest tonight.

No VC roadmap. No en­ter­prise tier. No dark pat­tern that turns your prompts into train­ing data. Just soft­ware made by re­searchers and hack­ers, for re­searchers and hack­ers.

YOUR MAC IS MORE CAPABLE THAN YOU THINK

Stop renting­in­tel­li­gence.

Run it lo­cally, in the open.

Posts: 118 Threads: 27 Joined: 2023 Jun

Reputation: 26

Country:

Yesterday, 03:01 PM (This post was last mod­i­fied: Yesterday, 03:05 PM by joshuaboni­face. Edited 2 times in to­tal.)

Hello every­one. Ef­fec­tive yes­ter­day, Anthony and I de­cided to de­part from the pro­ject, my­self as Project Leader, and he as a core team mem­ber. This is in ad­di­tion to the res­ig­na­tion of Andrew on Friday. We leave the pro­ject in the very ca­pa­ble hands of the re­main­ing team who have been dri­ving the pro­ject for many years now.

Joshua:

For me per­son­ally, it was just time for a change. I sim­ply could no longer pro­vide the ef­fort (mental or time-wise) that the role de­manded, and thus I was not per­form­ing my du­ties to an ac­cept­able de­gree, fac­ing se­vere burnout, and risks to my men­tal health. It was time to step aside. Hand-off is on­go­ing and is am­i­ca­ble, and there is good com­mu­ni­ca­tion lines, so there is lit­tle to no risk of a hos­tile fork or any­thing of that na­ture. Jellyfin will con­tinue for a long time to come, just not with me at its head.

When I started Jellyfin, I thought it would be some­thing used by a few hun­dred, or maybe if we were lucky, a few thou­sand, users. We might put a few pet fea­tures in, and do a bit of cleanup, but re­ally, I did­n’t ex­pect much. Now here we are 7-and-a-half years later, and it’s the #1 FLOSS me­dia server, a truly vi­able al­ter­na­tive to Plex for lit­er­ally mil­lions of server ad­min­is­tra­tors and prob­a­bly 10x that many in­di­vid­ual users, and we’ve left our par­ent pro­ject com­pletely in our dust. We’ve proven that FLOSS works, and is in de­mand.

I truly hope Jellyfin out­lives me, and I trust those in the team to keep the phi­los­o­phy and code alive.

For the last time, happy watch­ing all!

Anthony:

My par­tic­u­lar rea­sons are a bit dif­fer­ent, so I fig­ured I would post as well.

For my­self, though I don’t touch much code these days, I do a lot to man­age things in the back­end and with App Stores/etc. After 7.5 - nearly 8 - years, it’s been a long time since I’ve been able to give much of my free time to Jellyfin. My life is chang­ing and I’ve got other things that must take pri­or­ity.

I am fully com­mit­ted to a smooth tran­si­tion, which is some­thing I’ve wanted for a long time any­way. Even if the tran­si­tion takes a year, I’m still down to do that. I want Jellyfin to suc­ceed, and it should.

9

Member

Posts: 114 Threads: 32 Joined: 2025 Mar

Reputation: 2

Country:

Yesterday, 09:34 PM

Thank you for every­thing!

I com­plain about Jellyfin a lot and have no idea what I’m do­ing.

1

Junior Member

Posts: 14 Threads: 4 Joined: 2023 Jun

Reputation: 0

Yesterday, 11:01 PM

Thank you very much Joshua, Anthony and Andrew for the time and ef­fort you’ve put into this pro­ject.

Junior Member

Posts: 1 Threads: 0 Joined: 2026 Jul

Reputation: 0

Country:

6 hours ago

Thank you both so much for all the time and ef­fort you put into this pro­ject, it is one of my favourite self-hosted pro­jects which I now con­sider es­sen­tial!

Junior Member

Posts: 1 Threads: 0 Joined: 2026 Jul

Reputation: 0

Country:

4 min­utes ago

I have noth­ing but the great­est re­spect for both such ex­cel­lent, sus­tained ef­fort and also for rec­og­niz­ing when your own sit­u­a­tion war­rants step­ping back and hand­ing the reigns to some­one else to carry on.

Thank you!

Technology

Data cen­ter leases, GPU sup­ply con­tracts raise li­a­bil­i­ties at Meta, Oracle, Nikkei study shows

A Meta data cen­ter in the state of Georgia. The com­pa­ny’s off-bal­ance-sheet debt is about $420 bil­lion, nearly triple its trans­par­ent debt. © AP

KOHEI YAMADA

July 21, 2026 02:29 JST

PALO ALTO, California — Hidden debt at U.S. tech gi­ants swelled eight­fold in roughly four years to an es­ti­mated $1.65 tril­lion as ar­ti­fi­cial in­tel­li­gence in­vest­ments bal­looned, a Nikkei study shows, ex­ceed­ing ac­tual debt and mak­ing it tougher for in­vestors to as­sess risk.

Incremental is a li­brary that gives you a way of build­ing com­plex com­pu­ta­tions that can up­date ef­fi­ciently in re­sponse to their in­puts chang­ing, in­spired by the work of Umut Acar et. al. on self-ad­just­ing com­pu­ta­tions. Incremental can be use­ful in a num­ber of ap­pli­ca­tions, in­clud­ing:

Building large cal­cu­la­tions (of the kind you might build into a spread­sheet) that can re­act ef­fi­ciently to chang­ing data.

Constructing views in GUI ap­pli­ca­tions that can in­cor­po­rate new data ef­fi­ciently.

Computing de­rived data while guar­an­tee­ing that the de­rived data stays in sync with the source data, for in­stance fil­ter­ing or in­vers­ing a map­ping.

You can find de­tailed doc­u­men­ta­tion of the li­brary and how to use it in in­cre­men­tal/​src/​in­cre­men­tal_intf.ml. You can also find an in­for­mal in­tro­duc­tion to the li­brary in this blog post and this video.