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.

Jul 21, 2026

|

Our newest Gemini mod­els de­liver the ef­fi­ciency, la­tency, and re­li­a­bil­ity to build AI agents at scale.

Your browser does not sup­port the au­dio el­e­ment.

Listen to ar­ti­cle

[[duration]] min­utes

This con­tent is gen­er­ated by Google AI. Generative AI is ex­per­i­men­tal

Developers and cus­tomers build­ing pro­duc­tion AI agents need higher to­ken ef­fi­ciency, lower la­tency, and more re­li­able per­for­mance. Our Flash se­ries of mod­els is built to meet the sweet spot of ef­fi­ciency and qual­ity to en­able scal­ing agen­tic work­flows. Building on Gemini 3.5 Flash, we’re in­tro­duc­ing new Gemini mod­els:

3.6 Flash: Our work­horse model that de­liv­ers bet­ter cod­ing, knowl­edge work, and mul­ti­modal per­for­mance. According to the Artificial Analysis Index, it re­duces out­put to­ken us­age by 17% com­pared to 3.5 Flash, and in some bench­marks like DeepSWE by Datacurve, we ob­serve up to 65%, all at a lower cost per out­put to­ken.

3.5 Flash-Lite: Our fastest, most cost-ef­fec­tive 3.5-class model, de­liv­er­ing 350 out­put to­kens per sec­ond ac­cord­ing to the Artificial Analysis Index, also sig­nif­i­cantly out­per­form­ing prior Flash-Lite gen­er­a­tions in agen­tic work­flows.

3.5 Flash Cyber in CodeMender: Successful cy­ber­se­cu­rity ap­pli­ca­tions re­quire care­ful or­ches­tra­tion of a model along­side an agent in­fra­struc­ture. We’re in­tro­duc­ing a com­bi­na­tion of a new, highly ef­fi­cient, spe­cial­ized cy­ber-fo­cused model paired with our CodeMender code se­cu­rity agent that de­liv­ers com­pet­i­tive per­for­mance at the fron­tier.

Beyond to­day’s re­leases, Gemini 3.5 Pro is cur­rently test­ing with part­ners and we plan to make it broadly avail­able as soon as it’s ready. In par­al­lel, our team is al­ready fo­cus­ing on build­ing the next gen­er­a­tion of mod­els. We have started our most am­bi­tious pre-train­ing run yet, for Gemini 4, and are ex­cited by the progress.

3.6 Flash: More ef­fi­cient and bet­ter qual­ity than 3.5 Flash

Gemini 3.6 Flash builds di­rectly on de­vel­oper and cus­tomer feed­back from 3.5 Flash. 3.6 Flash not only de­liv­ers a step up in cod­ing and knowl­edge work, but it does this while mean­ing­fully im­prov­ing to­ken ef­fi­ciency. For ex­am­ple, on the Artificial Analysis Index, we see 3.6 Flash con­sum­ing 17% fewer out­put to­kens than 3.5 Flash. It also takes fewer rea­son­ing steps and tool calls to ac­com­plish multi-step work­flows.

This en­hanced ef­fi­ciency is also com­bined with a lower price than 3.5 Flash. At $1.50/1M in­put to­kens and $7.50/1M out­put to­kens, 3.6 Flash re­duces the over­all cost per agen­tic task, mak­ing agents more cost-ef­fec­tive to build and run.

3.6 Flash shows bet­ter to­ken ef­fi­ciency and re­duced ver­bosity than 3.5 Flash in an OSWorld ver­i­fied task (API)

Even while be­ing more ef­fi­cient, 3.6 Flash sees per­for­mance gains com­pared to 3.5 Flash across use cases:

3.6 Flash de­liv­ers higher pre­ci­sion with fewer un­wanted code ed­its and re­duced ex­e­cu­tion loops, as seen in DeepSWE (49% vs. 37%), and shows sig­nif­i­cant im­prove­ment in ML Research, as seen in MLE Bench (63.9% vs. 49.7%).

It has im­proved com­puter use ca­pa­bil­i­ties as seen in OSWorld-Verified (83.0% vs. 78.4%). Computer use is now a built-in client side tool via the Gemini API and Gemini Enterprise.

It out­per­forms 3.5 Flash in knowl­edge work, as shown by bench­marks like GDPval-AA v2 (1421 vs. 1349). Customers like Hebbia and Harvey have found it par­tic­u­larly ca­pa­ble at mul­ti­modal tasks like doc­u­ment pars­ing, chart and data analy­sis, and re­port draft­ing.

Customers re­port 3.6 Flash is a step for­ward in both cost and qual­ity, bal­anc­ing to­ken ef­fi­ciency, ac­cu­racy, and speed across com­plex work­flows and knowl­edge-based tasks:

Built with safety

3.6 Flash is ship­ping with en­hanced Frontier Safety safe­guards in the do­mains of Chemical, Biological, Radiological, and Nuclear (CBRN) and cy­ber of­fense mis­uses. These safe­guards make the model sub­stan­tially more re­sis­tant to jail­breaks. At the same time, the model has been trained to min­i­mize re­fusals for ben­e­fi­cial uses.

For more in­for­ma­tion, see the 3.6 Flash model card.

3.5 Flash-Lite: Built to scale agen­tic work­flows

Beyond Flash, we’re also re­leas­ing Gemini 3.5 Flash-Lite, de­signed for both low-la­tency tasks and tasks where high through­put is crit­i­cal for de­vel­op­ers work­flows, like agen­tic search and doc­u­ment pro­cess­ing.

3.5 Flash-Lite is the fastest model in the 3.5 se­ries. As mea­sured by Artificial Analysis, it runs at 350 out­put to­kens/​s. Priced at $0.3/1M in­put to­kens and $2.5/1M out­put to­kens and with sig­nif­i­cantly bet­ter qual­ity than 3.1 Flash-Lite, 3.5 Flash-Lite of­fers a strong price-to-per­for­mance ra­tio for de­vel­op­ers and cus­tomers run­ning high through­put pro­duc­tion traf­fic.

3.5 Flash-Lite ex­e­cutes high vol­ume tasks at a lower la­tency than 3.5 Flash.

3.5 Flash-Lite en­ables ef­fi­cient scal­ing for agen­tic sys­tems. Across think­ing lev­els, the model sig­nif­i­cantly out­per­forms 3.1 Flash-Lite. Depending on the work­load, de­vel­op­ers can con­fig­ure the model to pri­or­i­tize low-la­tency, low-cost ex­e­cu­tion for high-vol­ume tasks with the min­i­mal and low think­ing lev­els, or en­gage higher think­ing lev­els to process multi-step sub­agent work­loads. The model now also has com­puter use as a built-in tool to re­li­ably sup­port these agen­tic tasks across sur­faces.

It’s a sig­nif­i­cant step up in cod­ing and agen­tic tasks as seen in Terminal-Bench 2.1 (54% vs 31%), long con­text as seen in GDM-MRCR v2 (72.2% vs. 60.1%), and real-world task ex­e­cu­tion as seen in GDPval-AA v2 (1140 vs. 642).

In fact, on many agen­tic and cod­ing evals, 3.5 Flash-Lite even out­per­forms 3 Flash, in­clud­ing on SWE-Bench Pro (54.2% vs. 49.6%) and OSWorld-Verified (74.0% vs. 65.1%), mak­ing it a faster & more ca­pa­ble op­tion for work­loads on both 2.5 and 3 Flash.

Early cus­tomers of 3.5 Flash-Lite are high­light­ing its unique com­bi­na­tion of speed, in­tel­li­gence, and cost ef­fi­ciency for scal­ing agen­tic work­flows and data pro­cess­ing tasks:

For more in­for­ma­tion about the model, see the 3.5 Flash-Lite model card.

3.5 Flash Cyber in CodeMender: find­ing and fix­ing vul­ner­a­bil­i­ties ef­fi­ciently

AI mod­els have be­come ca­pa­ble of find­ing se­cu­rity vul­ner­a­bil­i­ties faster than cur­rent sys­tems can fix them. Tackling this grow­ing threat re­quires an ap­proach to se­cur­ing soft­ware that is highly ca­pa­ble and ef­fi­cient.

Flash’s per­for­mance and ef­fi­ciency makes it an ideal foun­da­tion to de­tect, val­i­date, and patch code se­cu­rity is­sues at scale. Gemini 3.5 Flash Cyber is built on top of 3.5 Flash, and fine-tuned for find­ing and fix­ing cy­ber­se­cu­rity vul­ner­a­bil­i­ties at a lower price per to­ken than larger mod­els.

Within CodeMender, which uses mul­ti­ple 3.5 Flash Cyber agents work­ing to­gether to pro­duce a sin­gle com­bined re­port, 3.5 Flash Cyber reaches com­pet­i­tive per­for­mance at the fron­tier on the pop­u­lar bench­mark CyberGym.

Given the dual-use na­ture of this tech­nol­ogy, we have taken an in­ten­tional ap­proach to de­ploy­ing 3.5 Flash Cyber. The model will be ex­clu­sively avail­able to gov­ern­ments and trusted part­ners via CodeMender soon as part of a lim­ited-ac­cess pi­lot pro­gram. This will give front­line de­fend­ers a head start in find­ing and fix­ing crit­i­cal vul­ner­a­bil­i­ties be­fore they can be ex­ploited, while mit­i­gat­ing against broader mis­use.

3.6 Flash and 3.5 Flash-Lite: Get started to­day

3.6 Flash and 3.5 Flash-Lite are avail­able start­ing to­day:

For de­vel­op­ers in the Gemini API via Google AI Studio and Android Studio. 3.6 Flash is also avail­able in Google Antigravity. Get started with the Developer Guide.

For en­ter­prises in Gemini Enterprise Agent Platform. 3.6 Flash is also avail­able in the Gemini Enterprise app.

For every­one via the Gemini app. 3.5 Flash-Lite is also rolling out in Google Search.

As you start build­ing with 3.6 Flash and 3.5 Flash-Lite, we wel­come your feed­back to im­prove fu­ture Gemini mod­els and look for­ward to re­leas­ing 3.5 Pro soon.

Get the lat­est news from Google in your in­box

Sign up for our newslet­ters with prod­uct up­dates, event in­for­ma­tion, spe­cial of­fers, and more.

Your in­for­ma­tion will be used in ac­cor­dance with Google’s pri­vacy pol­icy. You may opt out at any time.

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.

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.

10

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:

Today, 08:46 AM

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:

5 hours 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!

Community Moderator

Posts: 1,073 Threads: 9 Joined: 2023 Jul

Reputation: 31

3 hours ago

Just want to echo the sen­ti­ments from all the con­ver­sa­tions as well as those shared here: thank you all for your con­tri­bu­tions to this mas­sively pop­u­lar and wildly suc­cess­ful pro­ject. I thank the whole team for ex­pand­ing my reper­toire of knowl­edge around self-host­ing and pro­vid­ing a bet­ter, open source al­ter­na­tive to other (unnamed 🗿) prod­ucts.

Good luck in your jour­neys. 🚀 I hope to see you back around the pro­ject should you be able to find the right bal­ance, con­tribut­ing how­ever you can.

Jellyfin 10.11.10 Official Docker | Ubuntu 24.04 LTS | i7 – 13700K | Arc A380 6 GB | 64 GB RAM | 79 TB Storage

1

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.

This case in­volves Apple’s han­dling of user-up­loaded files hosted in pri­vate iCloud stor­age. Instead of adopt­ing PhotoDNA to scan hosted files for CSAM, Apple cre­ated its own pro­pri­etary al­ter­na­tive, NeuralHash, which ap­par­ently was­n’t as good. So Apple U-turned on its ef­forts to scan for CSAM in its cloud stor­age. Instead, Apple im­ple­mented end-to-end en­cryp­tion for iCloud files.

Apple’s manuev­ers con­fused the pub­lic and seemed like an em­bar­rass­ing un­forced er­ror for Apple. It also en­sured pres­sure from gov­ern­ments and plain­tiffs, in­clud­ing CSAM vic­tims, who pre­ferred Apple’s more in­ter­ven­tion­ist ap­proaches, which Apple had vol­un­tar­ily demon­strated it was will­ing to do.

This law­suit rep­re­sents a full-scale at­tack on Apple and Section 230. “Plaintiffs al­lege that Apple’s fail­ure to im­ple­ment any known CSAM de­tec­tion is a de­sign de­fect be­cause Apple can safely im­ple­ment read­ily avail­able fea­tures to pre­vent the spread of known CSAM but has con­tin­u­ously failed to do so.” Prior blog post. The court dis­misses the third amended com­plaint, which tees this case up for the Ninth Circuit, where (as usual) any­thing could hap­pen.

* * *

The court re­it­er­ates that Section 230 ap­plies to the plain­tiffs’ claims:

First, Plaintiffs’ claims treat Apple as a pub­lisher or speaker of the CSAM con­tent that an­i­mates Plaintiffs’ in­juries. Fundamentally, Plaintiffs con­tend that Apple has elected to per­mit users to dis­sem­i­nate and share third-party CSAM con­tent when it could have—and, in their view, should have—used read­ily avail­able tech­nol­ogy to pre­vent the dis­tri­b­u­tion of child pornog­ra­phy de­pict­ing the Plaintiffs in this pu­ta­tive class. The du­ties Plaintiffs seek to in­voke “spring[ ] from the de­fen­dan­t’s sta­tus as pub­lisher,” and con­se­quently, “immunity ap­plies.” Second, im­mu­nity also ap­plies be­cause “the means to avoid li­a­bil­ity re­quires [Apple] to act as a pub­lisher.” As a re­sult, Apple is en­ti­tled to com­plete im­mu­nity un­der § 230.

First, Plaintiffs’ claims treat Apple as a pub­lisher or speaker of the CSAM con­tent that an­i­mates Plaintiffs’ in­juries. Fundamentally, Plaintiffs con­tend that Apple has elected to per­mit users to dis­sem­i­nate and share third-party CSAM con­tent when it could have—and, in their view, should have—used read­ily avail­able tech­nol­ogy to pre­vent the dis­tri­b­u­tion of child pornog­ra­phy de­pict­ing the Plaintiffs in this pu­ta­tive class. The du­ties Plaintiffs seek to in­voke “spring[ ] from the de­fen­dan­t’s sta­tus as pub­lisher,” and con­se­quently, “immunity ap­plies.” Second, im­mu­nity also ap­plies be­cause “the means to avoid li­a­bil­ity re­quires [Apple] to act as a pub­lisher.” As a re­sult, Apple is en­ti­tled to com­plete im­mu­nity un­der § 230.

Citing Doe 1 v. Meta, the court says:

Plaintiffs’ in­juries are the di­rect re­sult of the ac­tions of third par­ties who used iCloud to share CSAM, a use Apple nei­ther ex­plic­itly con­dones nor pre­vents (even as­sum­ing—as al­leged in the TAC—that Apple was aware of the use of iCloud for this pur­pose)….though Plaintiffs al­lege that Apple knew that its tools were likely to be used to dis­trib­ute child pornog­ra­phy (as con­firmed by the in­ter­nal Apple text mes­sages at the cen­ter of this case), un­der the cur­rent state of the law, Apple is still en­ti­tled to im­mu­nity un­der § 230—irrespective of that gen­eral knowl­edge…. Plaintiffs can­not avoid the fact that a tool that de­tects CSAM must re­view CSAM to make such a de­ter­mi­na­tion. And while Apple could have taken steps to do so—as its com­peti­tors have done by us­ing PhotoDNA—Grindr con­firms that § 230 bars claims aris­ing from the de­sign de­ci­sions Apple could have taken where those claims re­late to Apple’s role fa­cil­i­tat­ing the com­mu­ni­ca­tion and con­tent of oth­ers

Plaintiffs’ in­juries are the di­rect re­sult of the ac­tions of third par­ties who used iCloud to share CSAM, a use Apple nei­ther ex­plic­itly con­dones nor pre­vents (even as­sum­ing—as al­leged in the TAC—that Apple was aware of the use of iCloud for this pur­pose)….though Plaintiffs al­lege that Apple knew that its tools were likely to be used to dis­trib­ute child pornog­ra­phy (as con­firmed by the in­ter­nal Apple text mes­sages at the cen­ter of this case), un­der the cur­rent state of the law, Apple is still en­ti­tled to im­mu­nity un­der § 230—irrespective of that gen­eral knowl­edge….

Plaintiffs can­not avoid the fact that a tool that de­tects CSAM must re­view CSAM to make such a de­ter­mi­na­tion. And while Apple could have taken steps to do so—as its com­peti­tors have done by us­ing PhotoDNA—Grindr con­firms that § 230 bars claims aris­ing from the de­sign de­ci­sions Apple could have taken where those claims re­late to Apple’s role fa­cil­i­tat­ing the com­mu­ni­ca­tion and con­tent of oth­ers

(A re­minder that the de­fen­dan­t’s sci­en­ter is ir­rel­e­vant to Section 230).

The plain­tiffs tried to fit into the new Section 230 ex­cep­tions cre­ated in Doe v. Twitter, but the court re­buffs the move:

This case does not con­cern or even dis­cuss Apple’s con­tent re­port­ing sys­tems; it con­cerns Apple’s “failure to im­ple­ment in­dus­try-stan­dard safe­guards” against the dis­sem­i­na­tion of CSAM. Though re­port­ing sys­tems and CSAM safe­guards may both be de­scribed as “defects,” the lat­ter re­quires the Court to treat Apple as a pub­lisher. Twitter “could ful­fill its pur­ported duty to cure re­port­ing in­fra­struc­ture de­fi­cien­cies with­out mon­i­tor­ing, re­mov­ing, or in any way en­gag­ing with third-party con­tent”; Apple can­not ful­fill a duty to in­sti­tute CSAM safe­guards with­out de­ploy­ing a tool like NeuralHash or PhotoDNA. Both NeuralHash and PhotoDNA were built to mon­i­tor and re­port vi­ola­tive im­ages up­loaded to com­pany servers. Yet just the de­ci­sion re­gard­ing whether to de­ploy ei­ther tool is a choice re­lated to con­tent mod­er­a­tion.

This case does not con­cern or even dis­cuss Apple’s con­tent re­port­ing sys­tems; it con­cerns Apple’s “failure to im­ple­ment in­dus­try-stan­dard safe­guards” against the dis­sem­i­na­tion of CSAM. Though re­port­ing sys­tems and CSAM safe­guards may both be de­scribed as “defects,” the lat­ter re­quires the Court to treat Apple as a pub­lisher. Twitter “could ful­fill its pur­ported duty to cure re­port­ing in­fra­struc­ture de­fi­cien­cies with­out mon­i­tor­ing, re­mov­ing, or in any way en­gag­ing with third-party con­tent”; Apple can­not ful­fill a duty to in­sti­tute CSAM safe­guards with­out de­ploy­ing a tool like NeuralHash or PhotoDNA. Both NeuralHash and PhotoDNA were built to mon­i­tor and re­port vi­ola­tive im­ages up­loaded to com­pany servers. Yet just the de­ci­sion re­gard­ing whether to de­ploy ei­ther tool is a choice re­lated to con­tent mod­er­a­tion.

Also, Apple did­n’t fail to sat­isfy any duty to re­port items to NCMEC if it never iden­ti­fied CSAM in the first place.

The Lemmon v. Snap workaround fails: “all of Plaintiffs’ claims here are in­ex­orably linked to third-party con­tent; Plaintiffs do not al­lege that Apple cre­ated con­tent like a Snapchat fil­ter that caused them harm.” The Roommates.com workaround also fails: “Plaintiffs do not al­lege that Apple mod­i­fied or aug­mented the CSAM on its servers in any way.”

* * *

The case reaches its in­evitable de­noue­ment of a win for Apple. However, Judge Wise re­mains trou­bled about its im­pli­ca­tions. She ex­presses her un­easi­ness in stronger-than-nor­mal terms:

As it stands, noth­ing in the law pre­vents any com­pany, in­clud­ing Apple, from uti­liz­ing avail­able tech­nol­ogy or cre­at­ing new tech­nol­ogy to iden­tify and re­port child pornog­ra­phy stored and dis­trib­uted on their tra­di­tional servers or through their cloud ser­vices. Conversely, there is no law that ob­lig­ates com­pa­nies to proac­tively do so. Undoubtedly any such leg­is­la­tion would come at a cost of at least some loss of pri­vacy for mil­lions of peo­ple. But if law­mak­ers ex­pected that com­pa­nies would take steps to pre­vent their prod­ucts from be­ing used for stor­ing and dis­trib­ut­ing child pornog­ra­phy based on some­thing short of a le­gal im­per­a­tive, this case, like many oth­ers be­fore it, demon­strates the in­ad­e­quacy of that ap­proach. If law­mak­ers want to en­sure that Apple and other com­pa­nies ad­dress their role in the dis­sem­i­na­tion of CSAM, they must re­quire it un­der the law. In other words, law­mak­ers can fix this prob­lem that is con­tribut­ing to the ex­ploita­tion of chil­dren.

As it stands, noth­ing in the law pre­vents any com­pany, in­clud­ing Apple, from uti­liz­ing avail­able tech­nol­ogy or cre­at­ing new tech­nol­ogy to iden­tify and re­port child pornog­ra­phy stored and dis­trib­uted on their tra­di­tional servers or through their cloud ser­vices. Conversely, there is no law that ob­lig­ates com­pa­nies to proac­tively do so. Undoubtedly any such leg­is­la­tion would come at a cost of at least some loss of pri­vacy for mil­lions of peo­ple. But if law­mak­ers ex­pected that com­pa­nies would take steps to pre­vent their prod­ucts from be­ing used for stor­ing and dis­trib­ut­ing child pornog­ra­phy based on some­thing short of a le­gal im­per­a­tive, this case, like many oth­ers be­fore it, demon­strates the in­ad­e­quacy of that ap­proach. If law­mak­ers want to en­sure that Apple and other com­pa­nies ad­dress their role in the dis­sem­i­na­tion of CSAM, they must re­quire it un­der the law. In other words, law­mak­ers can fix this prob­lem that is con­tribut­ing to the ex­ploita­tion of chil­dren.

She goes through this fram­ing pretty quickly, but we should slow it down. The “loss of pri­vacy for mil­lions of peo­ple” she briefly ref­er­ences de­serves a lit­tle more care. The opin­ion down­plays the en­cryp­tion an­gle; it men­tions en­cryp­tion only twice, as if it’s an af­ter­thought. However, en­cryp­tion is the crit­i­cal at­tribute un­der­ly­ing Apple’s moves. Forcing Apple to scan for CSAM in iCloud means break­ing end-to-end en­cryp­tion for every­one and all pur­poses, in­clud­ing: male­fac­tors who would in­ter­cept pri­vate files for crim­i­nal pur­poses; and gov­ern­ment ac­tors who have re­peat­edly shown that they will break into, dis­trib­ute, and weaponize pri­vately stored file caches (I was just think­ing about the North Korea Sony hack. Remember it?).

So yes, the “privacy loss” Judge Wise men­tions in­deed would be a ma­jor cost to every­one. Worse, it would en­sure new vic­tims have their sen­si­tive, pri­vate, or abu­sive im­ages non­con­sen­su­ally in­ter­cepted and dis­sem­i­nated. (Do you re­call the Fappening and Snappening?) End-to-end en­cryp­tion is­n’t just some nice-to-have fea­ture; it is one of the core planks of a tech­nol­ogy ar­chi­tec­ture that keeps peo­ple safer.

Judge Wise con­tin­ues:

This Order does not turn on whether Apple’s de­ci­sions con­tributed to Plaintiffs’ in­juries. All Plaintiffs’ claims are founded on Apple serv­ing as a pub­lisher of third-party con­tent. It is that role as “publisher” that is dis­pos­i­tive on the is­sue of im­mu­nity. This does not mean that the ex­is­tence of im­ages and videos of the pu­ta­tive class mem­bers be­ing sex­u­ally abused—con­tent that they al­lege is reg­u­larly stored and dis­sem­i­nated on iCloud—has not caused Plaintiffs real and last­ing harm… the out­come also adds cre­dence to claims that the Ninth Circuit “has ex­panded § 230(c)’s scope to pro­vide func­tional im­mu­nity to in­ter­net com­pa­nies, even when they are aware (or should be aware) of un­law­ful con­tent on their web­sites.” The prac­ti­cal out­come is that the cur­rent state of the law pri­or­i­tizes pri­vacy—a laud­able and crit­i­cally im­por­tant value given that in our mod­ern world nearly all our most per­sonal and in­ti­mate data (including fi­nan­cial and health records) are stored and trans­mit­ted on­line. But the law should not ig­nore how those who cre­ate, view, and dis­trib­ute child pornog­ra­phy lever­age pri­vacy pro­tec­tions to avoid de­tec­tion by law en­force­ment. In the cur­rent le­gal frame­work, there is no pro­tec­tion for mem­bers of the pu­ta­tive class—in­di­vid­u­als who as chil­dren were pho­tographed and filmed while be­ing abused in the vilest ways imag­in­able, and who now are re­peat­edly vic­tim­ized each time the in­ti­mate and tor­tured im­ages of their trauma are dis­trib­uted to oth­ers. Those chil­dren are the col­lat­eral dam­age of our in­ef­fec­tive le­gal land­scape. They de­serve bet­ter.

This Order does not turn on whether Apple’s de­ci­sions con­tributed to Plaintiffs’ in­juries. All Plaintiffs’ claims are founded on Apple serv­ing as a pub­lisher of third-party con­tent. It is that role as “publisher” that is dis­pos­i­tive on the is­sue of im­mu­nity. This does not mean that the ex­is­tence of im­ages and videos of the pu­ta­tive class mem­bers be­ing sex­u­ally abused—con­tent that they al­lege is reg­u­larly stored and dis­sem­i­nated on iCloud—has not caused Plaintiffs real and last­ing harm…

the out­come also adds cre­dence to claims that the Ninth Circuit “has ex­panded § 230(c)’s scope to pro­vide func­tional im­mu­nity to in­ter­net com­pa­nies, even when they are aware (or should be aware) of un­law­ful con­tent on their web­sites.” The prac­ti­cal out­come is that the cur­rent state of the law pri­or­i­tizes pri­vacy—a laud­able and crit­i­cally im­por­tant value given that in our mod­ern world nearly all our most per­sonal and in­ti­mate data (including fi­nan­cial and health records) are stored and trans­mit­ted on­line. But the law should not ig­nore how those who cre­ate, view, and dis­trib­ute child pornog­ra­phy lever­age pri­vacy pro­tec­tions to avoid de­tec­tion by law en­force­ment. In the cur­rent le­gal frame­work, there is no pro­tec­tion for mem­bers of the pu­ta­tive class—in­di­vid­u­als who as chil­dren were pho­tographed and filmed while be­ing abused in the vilest ways imag­in­able, and who now are re­peat­edly vic­tim­ized each time the in­ti­mate and tor­tured im­ages of their trauma are dis­trib­uted to oth­ers. Those chil­dren are the col­lat­eral dam­age of our in­ef­fec­tive le­gal land­scape. They de­serve bet­ter.

Judge Wise is­n’t well-sit­u­ated to com­pare the rel­a­tive strengths and lim­i­ta­tions of the full range of po­ten­tial anti-CSAM op­tions, but a lead­ing tool has al­ways been and re­mains the gov­ern­men­t’s ef­forts to find and pros­e­cute the cre­ators, dis­sem­i­na­tors, and down­load­ers of CSAM. (Do you re­call the fed­eral gov­ern­men­t’s choices that leave chil­dren more vul­ner­a­ble?) Making sure the gov­ern­ment is do­ing what it can should be the #1 pri­or­ity. In con­trast, break­ing end-to-end en­cryp­tion should­n’t be any­where in the reg­u­la­tory toolkit.

Case Citation: Amy v. Apple Inc., 2026 WL 2031817 (N.D. Cal. July 13, 2026). The com­plaint.