In the con­text of con­cerns around young peo­ple’s in­ter­ac­tions with dig­i­tal tech­nolo­gies, the UK’s Department for Science, Innovation and Technology is con­sult­ing on ad­di­tional mea­sures to pre­pare young peo­ple for grow­ing up in a dig­i­tal world. Before the back­drop of users cir­cum­vent­ing age as­sur­ance sys­tems man­dated un­der the UK’s Online Safety Act, the con­sul­ta­tion con­sid­ers age-gat­ing vir­tual pri­vate net­works (VPNs).

Mozilla’s mis­sion is grounded in the be­lief that the in­ter­net must re­main open and ac­ces­si­ble to all, and that pri­vacy and se­cu­rity on­line are fun­da­men­tal hu­man rights. We rec­og­nize that the pro­tec­tion of young peo­ple on­line is one of the most press­ing and chal­leng­ing ques­tions of our time, and we are com­mit­ted to sup­port­ing pol­icy pro­pos­als that ad­dress the root causes of on­line harms. We are con­cerned, how­ever, that blunt in­ter­ven­tions like manda­tory age as­sur­ance and re­strict­ing ac­cess to tools like VPNs are not ef­fec­tive in im­prov­ing the pro­tec­tion af­forded to young peo­ple on­line, while un­der­min­ing the fun­da­men­tal rights of all users.

VPNs serve as crit­i­cal pri­vacy and se­cu­rity tools for users across all ages. By hid­ing users’ IP ad­dresses, VPNs help pro­tect users’ lo­ca­tion, re­duce track­ing and avoid IP-based pro­fil­ing. People use VPNs for lots of dif­fer­ent rea­sons: to con­nect to their school’s or em­ploy­er’s net­work re­motely, to avoid cen­sor­ship or to sim­ply pro­tect their pri­vacy and se­cu­rity on­line. While be­ing able to ac­cess VPNs is es­pe­cially im­por­tant for vul­ner­a­ble groups like ac­tivists, dis­si­dents or jour­nal­ists, VPNs im­prove every­one’s base­line pro­tec­tion on­line.

Young peo­ple are par­tic­u­larly vul­ner­a­ble to on­line track­ing, tar­geted ad­ver­tis­ing, and the risks that flow from per­sonal data be­ing col­lected and processed for com­mer­cial pur­poses with­out ad­e­quate con­sent or trans­parency. In a world in which young peo­ple are in­ter­act­ing with dig­i­tal tech­nolo­gies as part of their re­al­i­ties from young ages on­ward, re­strict­ing young peo­ple’s ac­cess to pri­vacy-pro­tect­ing tech­nolo­gies is in ten­sion with the goal of equip­ping them to nav­i­gate the in­ter­net safely and com­pe­tently. In or­der to be able to de­velop agency and re­spon­si­ble habits in en­gag­ing with dig­i­tal tech­nolo­gies, it is cru­cial for young peo­ple to be in­tro­duced to best prac­tices and key safety and pri­vacy tools as they en­gage with the on­line world.

Rather than age-gat­ing tech­nolo­gies like VPNs, we be­lieve that reg­u­la­tors should ad­dress the root causes of on­line harm by hold­ing plat­forms to ac­count, en­cour­ag­ing the re­spon­si­ble use of parental con­trols and in­vest­ing in dig­i­tal skills and a whole of so­ci­ety ap­proach to dig­i­tal well­be­ing.

Read our full sub­mis­sion to the Department for Science, Innovation and Technology.

I have the feel­ing that every or­ga­ni­za­tion out there is, at least par­tially, fo­cus­ing on process op­ti­miza­tion, some­thing that of­ten hap­pens when the mar­ket is down. These days there is also the AI an­gle to the en­tire thing, and the un­re­al­is­tic ex­pec­ta­tions that fol­low it.

To come fully pre­pared for this, I’ve de­cided to re-read two ab­solute clas­sics in this space: The Toyota way & The Goal 1. I’ve read both of these books in col­lege, but re-read­ing them made me re­al­ize that a lot of these process op­ti­miza­tion ex­er­cises are too sim­plis­tic in na­ture, and of­ten mis­un­der­stand what to fo­cus on.

The vi­sual bot­tle­neck

Let me show what I mean.

gantt

ti­tle Project Timeline

date­For­mat YYYY-MM-DD

sec­tion Scoping

Feature ex­plo­ration :s1, 2024 – 01-01, 10d

Budget scop­ing :s2, af­ter s1, 3d

Legal :s3, af­ter s1, 10d

Documenting :s4, af­ter s3, 5d

sec­tion Development

Exploration :d1, af­ter s4, 25d

Software Development :d2, af­ter d1, 70d

Documentation :d3, af­ter d2, 5d

sec­tion Deployment

Deployment :dp1, af­ter d2, 5d

Hyper-care :dp2, af­ter dp1, 10d

This is a Gantt chart for demon­stra­tion pur­poses, nor­mally you would look at BPMN. Showing a Gantt makes the point eas­ier.

If you take a look at this Gantt chart you will im­me­di­ately see what takes the most amount of time: soft­ware de­vel­op­ment. If your task was to im­prove pro­ject through­put, that would be your first stop. And that would be cor­rect.

The prob­lem, how­ever, is how I typ­i­cally see peo­ple go about it: throw peo­ple at the prob­lem2 or just as­sume AI is go­ing to make it so much faster.

What peo­ple typ­i­cally don’t do is look at why this is tak­ing so long, and even more im­por­tantly: long du­ra­tion does not au­to­mat­i­cally mean the prob­lem orig­i­nates there.

Solving the is­sue up­stream

We are now talk­ing about soft­ware de­vel­op­ment, but this is ap­plic­a­ble to all processes that take longer than you would like.

Every soft­ware de­vel­oper knows that you can’t make pro­jects go faster just by typ­ing faster. If that were the case we would all be tak­ing typ­ing lessons.

Software de­vel­op­ment is about trans­lat­ing a prob­lem into a so­lu­tion that a com­puter can un­der­stand and au­to­mat­i­cally re­solve. Preferably in a se­cure and scal­able way.

To do some­thing like that, you need a full overview of the prob­lem. Either in fea­ture or scope doc­u­ments (if you’re go­ing more wa­ter­fall), or with con­stant it­er­a­tion with the do­main ex­perts (more ag­ile).

This is of­ten the part that slows down soft­ware de­vel­op­ment. Trying to fig­ure out what a vague, ti­tle only, fea­ture re­quest ac­tu­ally means.

What does “send mail to user once sale is com­pleted” mean? Ok, we can send a mail, but what should be in the mail? What if there was an is­sue in the sales process, do we still send an er­ror mail? When is a sale com­pleted?

Just throw AI at it

An ar­gu­ment that I keep hear­ing about the au­toma­tion of soft­ware de­vel­op­ment (AI gen­er­ated code) is that you can just by­pass the de­vel­op­ment part and the soft­ware de­vel­oper be­comes the pro­ject man­ager. AI dis­cus­sions around soft­ware de­vel­op­ment ac­tu­ally il­lus­trate this prob­lem per­fectly.

A lot of peo­ple ex­pect the out­come of AI de­vel­op­ment to look like this:

gantt ti­tle Project Timeline date­For­mat YYYY-MM-DD sec­tion Scoping Feature ex­plo­ration :s1, 2024 – 01-01, 10d Budget scop­ing :s2, af­ter s1, 3d Legal :s3, af­ter s1, 10d Documenting :s4, af­ter s3, 5d sec­tion Development AI de­vel­op­ment :d1, af­ter s4, 3d sec­tion Deployment Deployment :dp1, af­ter d1, 5d Hyper-care :dp2, af­ter dp1, 10d

But that’s not how this works. Here we face the ex­act same up­stream is­sue as be­fore.

Yes, AI can gen­er­ate code quickly (whether that’s a good thing is open for de­bate), but that does­n’t mean it’s gen­er­at­ing the cor­rect code.

In com­par­isons be­tween hu­man vs AI de­vel­op­ment they al­ways ig­nore the hand­hold­ing that is needed for AI to do its thing. It looks a lot more like this:

gantt ti­tle Project Timeline date­For­mat YYYY-MM-DD sec­tion Scoping Feature ex­plo­ration :s1, 2024 – 01-01, 10d Budget scop­ing :s2, af­ter s1, 3d Legal :s3, af­ter s1, 10d Documenting :s4, af­ter s3, 40d sec­tion Development AI de­vel­op­ment :d1, af­ter s3, 40d sec­tion Deployment Deployment :dp1, af­ter d1, 5d Hyper-care :dp2, af­ter dp1, 10d

Maybe this setup is faster com­pared to the old way of work­ing. But I also think it’s an un­fair com­par­i­son. Working like this re­quires a much deeper in­volve­ment of do­main and prod­uct ex­perts. This in­volve­ment would mean writ­ing out every fea­ture and bug fix down to the tini­est de­tail.

This ex­act thing is what soft­ware de­vel­op­ers have been beg­ging for since the be­gin­ning of the pro­fes­sion: Receiving a de­tailed out­line of the prob­lem and what the end re­sult should look like.

If you were to give hu­man de­vel­op­ers the same amount of fea­ture/​scope doc­u­men­ta­tion you would also see your pro­duc­tiv­ity sky­rocket.

Actually speed­ing up processes

If you want to speed up processes, you need to make sure that the peo­ple that need to do the work have all the means to ac­tu­ally do the work.

This means that if your le­gal ap­proval process is go­ing slow, you take a look at what is needed to start a le­gal ap­proval process. If they need to chase five dif­fer­ent peo­ple for in­com­plete doc­u­ments, you’re not go­ing to speed up said process by adding more lawyers to the de­part­ment.

One of the big lessons of The Goal is: ”bottlenecks should re­ceive pre­dictable, high-qual­ity in­puts”.

I think that should be the first stop in process au­toma­tion.

The Toyota way is amaz­ing and I would highly rec­om­mend it. The Goal is a bit of a less pleas­ant read, I would go for the comic ver­sion ↩︎

The Toyota way is amaz­ing and I would highly rec­om­mend it. The Goal is a bit of a less pleas­ant read, I would go for the comic ver­sion ↩︎

The Mythical Man-Month. Another clas­sic ↩︎

The Mythical Man-Month. Another clas­sic ↩︎

TL;DR: People across the United States are cut­ting down, smash­ing, and dis­man­tling Flock Safety sur­veil­lance cam­eras. At least 25 cam­eras have been de­stroyed in five states since April 2025. One Virginia man faces 25 crim­i­nal charges for sys­tem­at­i­cally de­stroy­ing 13 cam­eras—he says he did it for the Fourth Amendment. The de­struc­tion comes as pub­lic anger builds over Flock’s doc­u­mented ICE con­nec­tions. Cities are hid­ing cam­era lo­ca­tions. Reddit threads show near-uni­ver­sal sup­port. This is what hap­pens when a $7.5 bil­lion sur­veil­lance com­pany ig­nores pub­lic op­po­si­tion.

The Destruction Map

The cam­eras are com­ing down:

La Mesa, California (February 2026): Two cam­eras found de­stroyed on Fletcher Parkway. One smashed and left on the me­dian. One had key parts re­moved. This hap­pened weeks af­ter the city coun­cil voted to keep the cam­eras de­spite over­whelm­ing pub­lic op­po­si­tion [1][2].

Eugene and Springfield, Oregon (October 2025): Six cam­eras cut down from poles. At least one spray-painted. A note left be­hind: “Hahaha get wrecked ya sur­veilling fucks” [3].

Suffolk, Virginia (April–October 2025): Thirteen cam­eras sys­tem­at­i­cally de­stroyed over six months. One man ar­rested af­ter de­tec­tives tracked him through—you guessed it—the sur­viv­ing Flock cam­eras [4].

Greenview, Illinois (February 2026): Two cam­eras cut down. Poles sev­ered at the base [3].

Lisbon, Connecticut (February 2026): One cam­era smashed. Police in­ves­ti­gat­ing [3].

The pat­tern: de­struc­tion in blue states, red states, cities, sub­urbs. Nobody is co­or­di­nat­ing this. People are just an­gry.

The Guy Who Got Caught

Jeffrey S. Sovern, 41, of Suffolk, Virginia, did­n’t hide what he did. He set up a GoFundMe for his le­gal de­fense. He linked to de­flock.org, an anti-sur­veil­lance ac­tivist site. He wrote a state­ment:

“I ap­pre­ci­ate every­one’s right to pri­vacy, en­shrined in the fourth amend­ment.”

“I ap­pre­ci­ate every­one’s right to pri­vacy, en­shrined in the fourth amend­ment.”

And:

“I ap­pre­ci­ate a quiet life and am not look­ing for­ward to this process, but I will take the sil­ver lin­ing that this can be a cat­a­lyst in a big­ger move­ment to roll-back in­tru­sive sur­veil­lance.”

“I ap­pre­ci­ate a quiet life and am not look­ing for­ward to this process, but I will take the sil­ver lin­ing that this can be a cat­a­lyst in a big­ger move­ment to roll-back in­tru­sive sur­veil­lance.”

Sovern faces 13 counts of de­struc­tion of prop­erty, six counts of pe­tit lar­ceny, and six counts of pos­ses­sion of bur­glary tools [4]. The tools in ques­tion: vice grips and metal cut­ters. His method: dis­man­tle the mount­ing poles, re­move the wiring, bat­ter­ies, and so­lar pan­els. Clean work.

Reddit’s re­ac­tion: near-uni­ver­sal sup­port. When your jury pool thinks you’re a folk hero, that’s a prob­lem for pros­e­cu­tors.

Why People Are This Angry

Flock Safety op­er­ates in ap­prox­i­mately 6,000 U.S. com­mu­ni­ties. That’s thou­sands of AI-powered cam­eras scan­ning every li­cense plate that passes. The com­pany is val­ued at $7.5 bil­lion [5].

The pitch: neigh­bor­hood safety. The re­al­ity: a sur­veil­lance net­work that feeds into fed­eral im­mi­gra­tion en­force­ment.

Here’s what the data shows:

More than 4,000 lookups by lo­cal and state po­lice were con­ducted for fed­eral im­mi­gra­tion pur­poses—in­clud­ing searches ex­plic­itly tagged “ICE,” “ICE+ERO,” and “ICE WARRANT” [6].

In Virginia alone, po­lice per­formed nearly 3,000 im­mi­gra­tion-re­lated searches on the Flock net­work over 12 months [7].

In Washington state, at least eight law en­force­ment agen­cies en­abled di­rect shar­ing of their Flock net­works with U.S. Border Patrol [7].

One Texas school dis­trict had cam­eras searched by 30 law en­force­ment agen­cies from states in­clud­ing Florida, Georgia, Indiana, and Tennessee—for im­mi­gra­tion pur­poses [6].

Flock says it does­n’t work with ICE. The data says lo­cal cops run ICE searches through the back­door.

People no­ticed.

When Councils Ignore the Public

La Mesa is the tem­plate. In December 2025, the city coun­cil held a meet­ing about con­tin­u­ing its Flock con­tract. The room was packed. The over­whelm­ing ma­jor­ity op­posed the cam­eras [1].

The coun­cil voted to keep them any­way.

Two months later, two cam­eras were found de­stroyed on the same street. One smashed. One gut­ted. Positioned on the me­dian like a mes­sage.

San Diego had the same dy­namic. Huge turnout against Flock at coun­cil meet­ings. Officials ap­proved con­tin­u­a­tion any­way. This is what hap­pens when elected of­fi­cials tell con­stituents their con­cerns don’t mat­ter: some peo­ple stop us­ing of­fi­cial chan­nels.

Cities Are Hiding Camera Locations

Louisville is su­ing to keep Flock cam­era lo­ca­tions se­cret. The city claims re­leas­ing the lo­ca­tions could com­pro­mise pub­lic safety. The real con­cern: van­dal­ism [8].

Norfolk lost a law­suit in December 2025 that forced dis­clo­sure of 600 cam­era lo­ca­tions in Hampton Roads. A fed­eral judge ruled the lo­ca­tions weren’t pro­tected [9].

Flock it­self does­n’t pub­licly dis­close where its cam­eras are. But there are now over 6,000 com­mu­ni­ties with cam­eras. That’s a lot of hard­ware to pro­tect from an­gry res­i­dents with vice grips.

Flock’s Response

Garrett Langley, Flock’s 38-year-old CEO, has made state­ments that don’t ex­actly calm things down. He’s claimed that mass sur­veil­lance could elim­i­nate all crime in America [10]. The com­pa­ny’s of­fi­cial state­ment about the de­struc­tion:

“We re­spect and value con­cerns and feed­back raised about our tech­nol­ogy, and build­ing trust is im­por­tant to us.”

“We re­spect and value con­cerns and feed­back raised about our tech­nol­ogy, and build­ing trust is im­por­tant to us.”

Building trust. While cities hide cam­era lo­ca­tions and po­lice run ICE searches with­out war­rants. While school cam­eras get searched by agen­cies three states away. While coun­cil meet­ings with over­whelm­ing op­po­si­tion end in con­tract re­newals.

That trust-build­ing is­n’t go­ing well.

What Happens Now

The de­struc­tion is likely to con­tinue. The trig­gers re­main in place:

ICE searches con­tinue: Despite Flock’s de­nials, the back­door ac­cess through lo­cal po­lice has­n’t stopped.

Cities keep ig­nor­ing op­po­si­tion: When pub­lic com­ment pe­ri­ods be­come per­for­mance the­ater, peo­ple find other out­lets.

Cameras keep ex­pand­ing: 6,000 com­mu­ni­ties and grow­ing. More tar­gets, more op­por­tu­ni­ties.

Arrests cre­ate mar­tyrs: Jeffrey Sovern’s GoFundMe. Reddit threads full of sup­port. The more peo­ple get charged, the more at­ten­tion the cause gets.

Meanwhile, Amazon al­ready killed its Ring-Flock part­ner­ship. 46 cities have for­mally re­jected Flock cam­eras. Austin can­celled. Eugene can­celled. Mountain View can­celled. Santa Cruz can­celled. Alameda County post­poned [11].

The po­lit­i­cal winds are shift­ing. But for some peo­ple, the of­fi­cial chan­nels are too slow.

The Bigger Picture

This is­n’t about Flock specif­i­cally. It’s about what Flock rep­re­sents: sur­veil­lance in­fra­struc­ture that ex­pands re­gard­less of pub­lic op­po­si­tion, that claims to be lo­cal while feed­ing fed­eral data­bases, that promises com­mu­nity safety while en­abling de­por­ta­tion ma­chin­ery.

Flock CEO Langley said mass sur­veil­lance could elim­i­nate all crime. The peo­ple smash­ing cam­eras would ar­gue mass sur­veil­lance is the crime.

Right now, that ar­gu­ment is be­ing made with vice grips.

References

San Diego Slackers — Flock Cameras Destroyed in La Mesa Amid Surveillance Backlash (February 16, 2026)

TechCrunch — Americans are de­stroy­ing Flock sur­veil­lance cam­eras (February 23, 2026)

Blood in the Machine — Across the US, peo­ple are dis­man­tling and de­stroy­ing Flock sur­veil­lance cam­eras (February 2026)

Gizmodo — Flock Cameras Have a People-Love-Smashing-Them Problem (February 2026)

International Business Times — ICE Can Reportedly Access Flock Surveillance Cameras — Now Americans Are Destroying Them (February 2026)

404 Media — ICE Taps into Nationwide AI-Enabled Camera Network, Data Shows (2026)

University of Washington Center for Human Rights — Leaving the Door Wide Open: Flock Systems Expose Washington Data to Immigration Enforcement (October 2025)

State of Surveillance — Louisville Sues to Keep Camera Locations Secret (2026)

Virginia Mercury — Locations of 600 Flock cam­eras now pub­lic in Hampton Roads fol­low­ing law­suits (December 2025)

Flock Safety — Statement in Response to Recent Reports (2026)

State of Surveillance — The Flock Rebellion: Cities Pull the Plug on License Plate Surveillance (2026)

Published: February 24, 2026

I have been a na­tive ma­cOS / iOS de­vel­oper for al­most twenty years, and I want to say some­thing about the usual “Oh, it is Node / Electron again… what a shame…” re­ac­tion.

Recently, I tried to im­ple­ment a sim­ple chat with Markdown sup­port in a pure Swift / SwiftUI app. And hon­estly, it is al­most funny how im­ma­ture all these “native” things still are when you step out­side sim­ple screens. Yes, you can achieve rea­son­able per­for­mance in SwiftUI. You can even con­vince your­self that jumpy scrolling is fine, and that a few lags here & there are ac­cept­able. But then you want to se­lect a whole Markdown doc­u­ment built from SwiftUI prim­i­tives, and you just can­not. By de­sign.

So, be­ing smart & ex­pe­ri­enced, you move to NS­TextView. It even sup­ports TextKit 2 now. Great. Except now you lose most of the test­ing & per­for­mance work you had around SwiftUI, be­cause it does not play well with it. Then you try to stream text into it, be­cause it is 2026 & every­one streams re­sponses from mod­els now, and you start see­ing CPU spikes. Fine. We still have AppKit. We still have NSCol­lec­tion­View. Mature, per­for­mant, bat­tle-tested. So you switch again, im­ple­ment the whole thing, and on the sec­ond day you re­alise the cells will blink no mat­ter what. By de­sign.

Then you even con­sider go­ing lower-level with pure TextKit 2. You make a pro­to­type. Performance is okay. Streaming is still ter­ri­ble. It does not play well with any­thing mod­ern. You re­move SwiftUI com­pletely, stick with AppKit, and start fight­ing ex­pand­ing text chunks man­u­ally. At this point al­most every­thing is bro­ken, but hey, you can se­lect the text!

Then you re­alise it will take months just to reach fea­ture par­ity with ba­sic na­tive ma­cOS be­hav­iour: con­text menus, dic­tio­nary lookup, se­lec­tion, ac­ces­si­bil­ity, text in­ter­ac­tions, all the small things users ex­pect with­out think­ing about them.

So you try WebKit to ren­der Markdown. And it works. There are caveats, of course, but mostly it just works. Performance is good. Typography is al­most per­fect. You have a proper level of con­trol.

And then, at the dark­est pos­si­ble mo­ment, you think: okay, let’s gen­er­ate a sim­ple Electron pro­ject. You go to the dark side.

And you are amazed.

Text op­er­a­tions, Markdown ren­der­ing, good ty­pog­ra­phy — all of it works out of the box, with per­for­mance you could not get even from your pure TextKit 2 im­ple­men­ta­tion. ma­cOS in­te­gra­tions are there too. You can even ren­der fancy Git diffs with a few lines of code. I am not even talk­ing about things like diffs.com.

And then you ask your­self: what went wrong?

I did every­thing peo­ple say you should do. Native all the way. I know the plat­form. I know the op­tions. I know SwiftUI, AppKit, TextKit, WebKit.

But I still can­not make a sim­ple thing work prop­erly: a chat with Markdown & the abil­ity to se­lect a whole mes­sage.

And sud­denly it be­comes much clearer why most new chat-heavy apps that de­pend on one of the most im­por­tant in­ter­face pat­terns of this era — chat, long-form rich text, flex­i­ble ty­pog­ra­phy — are web-based in one way or an­other.

There is no real al­ter­na­tive.

SwiftUI is fine for sim­ple screens, prefer­ably with­out too much scrolling. Swift is still great for per­for­mance-crit­i­cal parts. But you can get most of that per­for­mance from Electron or React Native al­most for free with the na­tive in­ter­op­er­abil­ity, while keep­ing a much bet­ter text & ren­der­ing model.

So this is not even a “quick so­lu­tion vs proper so­lu­tion” de­bate any­more. If you want to build rich text ren­der­ing for long-form chats, SwiftUI & Apple’s na­tive SDKs are not help­ing you. They stop be­ing an ad­van­tage & start be­com­ing con­straints.

P.S. Discussion on Hacker News

P.P.S. Discussion on Lobsters.

Every AI lab is los­ing money serv­ing your com­pany right now. They know it. And they are do­ing it on pur­pose.

OpenAI, Anthropic, Google, and the rest are run­ning an in­dus­try-wide loss-leader pro­gram at a scale that has no prece­dent. They are sell­ing en­ter­prises filet mignon at gas sta­tion hot dog prices and call­ing it a busi­ness model. The gap be­tween what your com­pany pays for AI sub­scrip­tions and what it ac­tu­ally costs to serve those seats is not a round­ing er­ror. It is a gulf. And every or­ga­ni­za­tion that has built work­flows, prod­ucts, or en­tire busi­ness units on top of these sub­si­dized prices is stand­ing right on the edge of it.

This should be front of mind for every CTO, CFO, and head of op­er­a­tions read­ing this. Because when the pric­ing cor­rects, and it will, the com­pa­nies that treated AI as a per­ma­nently cheap util­ity are go­ing to wake up to bills that make their cur­rent SaaS spend look quaint.

The Math Your Finance Team Has Not Done

Pull out the nap­kin. This mat­ters.

Claude Pro costs $20 a month. For that, you get ac­cess to Sonnet 4.6, Opus 4.6, web search, code ex­e­cu­tion, file cre­ation, and roughly 5x the us­age of the free tier. On the API side, Sonnet 4.6 costs $3 per mil­lion in­put to­kens and $15 per mil­lion out­put to­kens. Opus 4.6 runs $5 in­put and $25 out­put per mil­lion to­kens.

A knowl­edge worker run­ning a few hours of Claude daily, up­load­ing doc­u­ments, draft­ing re­ports, an­a­lyz­ing data, can eas­ily burn through sev­eral mil­lion to­kens per week. At API rates, that same work­load runs some­where be­tween $200 and $400 a month per seat. Some power users push well be­yond that. But on a Pro sub­scrip­tion, the com­pany is pay­ing $20 per head.

Anthropic is not the only one eat­ing this cost. Microsoft was re­port­edly los­ing over $20 per user per month on GitHub Copilot. For power users, the com­pute burn was hit­ting $80 a month on a $10 sub­scrip­tion. One widely cited analy­sis found that Anthropic users were con­sum­ing up­wards of $8 in com­pute for every $1 of sub­scrip­tion rev­enue. OpenAI’s own VP of Product, Nick Turley, has de­scribed their sub­scrip­tion pric­ing as some­thing they “stumbled into” and has floated the idea of phas­ing out un­lim­ited plans en­tirely, com­par­ing them to “unlimited elec­tric­ity.”

ChatGPT Plus has been $20 a month for three years. In that time, the mod­els got dra­mat­i­cally more ca­pa­ble. The fea­tures mul­ti­plied. Image gen­er­a­tion, code in­ter­pre­ta­tion, voice mode, agen­tic rea­son­ing, web search. And the price never moved. For en­ter­prise buy­ers who locked in team or busi­ness rates dur­ing this win­dow, the ques­tion is not whether they got a good deal. The ques­tion is how long that deal sur­vives.

This Is Not One Company’s Problem

Every ma­jor provider is play­ing the same game with the same math.

Google of­fers Gemini Advanced at $20 a month bun­dled into Google One AI Premium while si­mul­ta­ne­ously charg­ing de­vel­op­ers real money for API ac­cess to the same mod­els. Meta gives away Llama for free, sub­si­diz­ing the com­pute cost of hun­dreds of mil­lions of AI queries across its plat­forms en­tirely through ad rev­enue. xAI’s Grok un­der­cuts every­one on API pric­ing at $0.20 per mil­lion in­put to­kens, a num­ber that only makes sense if you as­sume the com­pany is will­ing to he­m­or­rhage money to buy mar­ket share.

The pat­tern is iden­ti­cal across the board. Price for adop­tion, not for eco­nom­ics. Lock or­ga­ni­za­tions in. Make AI a load-bear­ing part of every team’s daily work­flow. Worry about the bill later.

For en­ter­prises, “later” is ar­riv­ing. OpenAI is los­ing money on con­sumer sub­scribers and is re­port­edly con­sid­er­ing a strate­gic pivot away from its con­sumer bets to­ward a tighter fo­cus on en­ter­prise, where the unit eco­nom­ics are slightly less ru­inous. The Wall Street Journal re­ported that the com­pany missed key rev­enue and user tar­gets in its sprint to­ward an IPO. The sub­sidy era is not wind­ing down grace­fully. It is show­ing cracks every­where.

Agents Broke the Economics

What made the sub­sidy math merely bad just be­came cat­a­strophic. The rea­son is agen­tic AI.

When AI was a chat­bot, you ask a ques­tion, it an­swers, to­ken con­sump­tion was rel­a­tively pre­dictable. A con­ver­sa­tion might run a few thou­sand to­kens. Heavy use might push into the tens of thou­sands. That was man­age­able at sub­si­dized rates.

The agen­tic shift changes the equa­tion com­pletely. Claude Code ses­sions run au­tonomously for ex­tended pe­ri­ods, burn­ing through to­kens at rates that dwarf con­ver­sa­tional us­age. Users have re­ported ex­haust­ing 5-hour rate limit win­dows in un­der 90 min­utes. GitHub just an­nounced that Copilot is mov­ing to us­age-based billing on June 1, 2026 specif­i­cally be­cause the flat-fee model col­lapsed un­der agen­tic work­loads. GitHub’s own an­nounce­ment ac­knowl­edged that Copilot has evolved sub­stan­tially and that agen­tic us­age “is be­com­ing the de­fault,” which causes higher com­pute and in­fer­ence de­mands. Sam Altman has said pub­licly that OpenAI now needs to be­come “an AI in­fer­ence com­pany,” an ac­knowl­edg­ment that agen­tic us­age re­quires a fun­da­men­tally dif­fer­ent eco­nomic model.

For en­ter­prise en­gi­neer­ing teams, the im­pli­ca­tions are con­crete. Agent Teams, mul­ti­ple AI in­stances work­ing in par­al­lel on a sin­gle pro­ject, mul­ti­ply the burn rate dra­mat­i­cally. A de­vel­oper run­ning three or four con­cur­rent cod­ing agents is not con­sum­ing 3x or 4x the to­kens of a chat con­ver­sa­tion. It is an or­der of mag­ni­tude more. And the sub­scrip­tion price on that seat has not changed.

The Enterprise Exposure No One Is Measuring

This is where it gets ugly for or­ga­ni­za­tions that have not done the work.

Over the past two years, thou­sands of com­pa­nies have wo­ven AI sub­scrip­tions deep into their op­er­a­tions. Marketing teams draft copy through ChatGPT Plus. Engineering teams write and re­view code through Claude Pro. Research teams syn­the­size doc­u­ments. Customer suc­cess teams sum­ma­rize tick­ets. Finance teams model sce­nar­ios. These are not ex­per­i­ments any­more. They are load-bear­ing work­flows.

Most of these com­pa­nies are bud­get­ing for AI at cur­rent sub­scrip­tion prices. A team of 50 on Claude Pro costs $1,000 a month. The same team on ChatGPT Plus costs the same. At those prices, AI is a round­ing er­ror on the P&L. Cheaper than a sin­gle SaaS tool. Cheaper than a con­trac­tor.

But the equiv­a­lent API us­age for that same team, if the com­pany were pay­ing the ac­tual cost of the to­kens con­sumed, would be some­where be­tween $15,000 and $40,000 a month de­pend­ing on us­age in­ten­sity. That is not a round­ing er­ror. That is a line item that needs its own bud­get code.

When prices ad­just, and they will ad­just, the com­pa­nies that treated $20-a-month AI as a per­ma­nently cheap in­put are go­ing to get hit with bills they did not bud­get for, at a time when the work­flows are too em­bed­ded to rip out. The sub­sidy cre­ates de­pen­dency. The de­pen­dency makes the price in­crease un­avoid­able. That is the whole trap.

The data backs this up. KPMG’s Q1 2026 AI Quarterly Pulse found that U.S. or­ga­ni­za­tions are pro­ject­ing av­er­age AI spend­ing of $207 mil­lion over the next 12 months, nearly dou­ble the fig­ure from the same pe­riod last year. But a Goldman Sachs re­search sur­vey found many large com­pa­nies are al­ready over­run­ning their AI bud­gets by or­ders of mag­ni­tude, with AI spend­ing on pace to ri­val en­gi­neers’ salaries in the near fu­ture.

And most or­ga­ni­za­tions are not even track­ing con­sump­tion prop­erly. Swami Chandrasekaran, head of AI and data labs at KPMG North America, told Marketplace: “Even, like, a quar­ter, two quar­ters ago, no­body both­ered about LLM con­sump­tion costs.” Brian Jabarian, an econ­o­mist at the University of Chicago who con­sults with com­pa­nies on AI trans­for­ma­tion, was more blunt: “The time for the bill is go­ing to come.”

The IPO Trigger

There is a spe­cific mech­a­nism that will force the repric­ing, and it is al­ready in mo­tion.

Both OpenAI and Anthropic are prepar­ing for IPOs. Anthropic has re­port­edly sur­passed $30 bil­lion in an­nu­al­ized rev­enue, up from $9 bil­lion at the end of 2025. OpenAI is on pace for roughly $25 bil­lion. These num­bers look im­pres­sive un­til you look at the cost side.

OpenAI pro­jects $115 bil­lion in cu­mu­la­tive cash burn through 2029 and has com­mit­ted to $665 bil­lion in com­pute spend­ing by 2030. Oracle took on $43 bil­lion in debt in a sin­gle fis­cal year to build data cen­ters for OpenAI. The en­tire in­fra­struc­ture be­hind these ser­vices is fi­nanced on the as­sump­tion that rev­enue will even­tu­ally cover costs. Right now, it does not.

When you are pri­vate and burn­ing ven­ture cap­i­tal, you can sub­si­dize in­fer­ence. You can run mod­els at a loss. You can of­fer $20-a-month plans that cost $100 or more to serve. An IPO changes the equa­tion overnight. Public mar­kets de­mand mar­gins. Analysts de­mand unit eco­nom­ics. Investors de­mand a path to prof­itabil­ity that does not de­pend on in­fi­nite fundrais­ing.

The mo­ment these com­pa­nies go pub­lic, the pres­sure to close the gap be­tween sub­scrip­tion price and ac­tual cost be­comes ex­is­ten­tial. The fastest way to close that gap is to raise prices, im­pose us­age caps, or shift to con­sump­tion-based billing. All three will hit cur­rent en­ter­prise sub­scribers hard.

The Playbook Is Already Visible

The repric­ing will not hap­pen all at once, but the sig­nals are al­ready vis­i­ble for any­one pay­ing at­ten­tion.

GitHub is mov­ing to us­age-based billing on June 1, 2026, re­plac­ing flat-rate pre­mium re­quests with to­ken-based AI Credits. Microsoft has raised Microsoft 365 prices twice in four years, with the lat­est round specif­i­cally tied to AI in­fra­struc­ture costs. OpenAI has in­tro­duced a $100 Pro tier po­si­tioned as the new “real” price for heavy users. Anthropic’s Max tier at $200 a month pro­vides a pre­view of what com­mit­ted us­age will ac­tu­ally cost when the sub­si­dies end. One by one, the floor is be­ing raised.

As Geoff Webb, VP at Conga, put it: “This AI land-grab is on a colos­sal scale, and the price tag for dom­i­nat­ing this new world is equally colos­sal. Monetizing the ser­vices and re­coup­ing some of that in­vest­ment is go­ing to force some pretty sig­nif­i­cant changes in busi­ness mod­els and ser­vice pric­ing, and those changes are likely to hap­pen fast.”

What Enterprise Leaders Should Be Doing Right Now

The com­pa­nies that sur­vive this tran­si­tion will be the ones do­ing the math to­day. That means au­dit­ing ac­tual to­ken con­sump­tion across teams, not just count­ing seats. It means mod­el­ing what AI costs look like at 2x, 5x, or 10x cur­rent prices. It means build­ing ven­dor op­tion­al­ity into the stack so that no sin­gle provider’s pric­ing change can blow up the bud­get overnight.

It also means hav­ing an hon­est con­ver­sa­tion with the CFO be­fore the CFO has it with you. Because the gap be­tween what your or­ga­ni­za­tion pays for AI to­day and what it will pay in 18 months is go­ing to be one of the most dis­rup­tive line-item in­creases most com­pa­nies have ever ab­sorbed. And the or­ga­ni­za­tions that get caught flat-footed will be the ones scram­bling to ex­plain why a tool that used to cost less than a team lunch sud­denly re­quires a six-fig­ure an­nual bud­get.

The sub­sidy era is end­ing. The clock is run­ning. And most en­ter­prises have not even started the con­ver­sa­tion.

Steven Levy, writ­ing for Wired last month af­ter Apple’s CEO tran­si­tion was an­nounced, un­der the provoca­tive head­line “Apple’s Next CEO Needs to Launch a Killer AI Product” (News+ link to get around Wired’s miserly pay­wall):

Much more re­cently, I quizzed Ternus and global mar­ket­ing head Greg Joswiak about Apple’s fu­ture, specif­i­cally its plans to get ahead of the AI trans­for­ma­tion. Ternus ac­knowl­edged that AI is “an im­mense kind of in­flec­tion point,” but couched it as one of many leaps that Apple has nav­i­gated. Each hit prod­uct — the Apple II, the Mac, iTunes, the iPod, the iPhone, iPad — pig­gy­backed on a pre­vi­ous prod­uct. “We never think about ship­ping a tech­nol­ogy,” he said. “We want to ship amaz­ing prod­ucts, fea­tures, and ex­pe­ri­ences, and we don’t want our cus­tomers to think about what [underlying] tech­nol­ogy makes it pos­si­ble. That’s the way we think about AI.”

That’s fine, but I look back to the mid-2000s when every­body was wait­ing for Apple to come out with a phone. When Jobs fi­nally de­liv­ered in January 2007, the prod­uct de­fined the mo­bile era. It’s a big ask for Ternus to do some­thing sim­i­lar for the AI age — but it’s an op­por­tu­nity that must be seized. AI threat­ens to dis­rupt the en­tire iPhone ecosys­tem. By the end of this decade, it’s un­likely that peo­ple will swipe on their phones to tap on Uber or Lyft. They will just tell their al­ways-on AI agent to get them home. Or that agent will have al­ready fig­ured out where they need to go, and the car will be wait­ing with­out the fric­tion of a re­quest. “There’s an app for that,” may be re­placed by “Let the agent do that.”

Much more re­cently, I quizzed Ternus and global mar­ket­ing head Greg Joswiak about Apple’s fu­ture, specif­i­cally its plans to get ahead of the AI trans­for­ma­tion. Ternus ac­knowl­edged that AI is “an im­mense kind of in­flec­tion point,” but couched it as one of many leaps that Apple has nav­i­gated. Each hit prod­uct — the Apple II, the Mac, iTunes, the iPod, the iPhone, iPad — pig­gy­backed on a pre­vi­ous prod­uct. “We never think about ship­ping a tech­nol­ogy,” he said. “We want to ship amaz­ing prod­ucts, fea­tures, and ex­pe­ri­ences, and we don’t want our cus­tomers to think about what [underlying] tech­nol­ogy makes it pos­si­ble. That’s the way we think about AI.”

That’s fine, but I look back to the mid-2000s when every­body was wait­ing for Apple to come out with a phone. When Jobs fi­nally de­liv­ered in January 2007, the prod­uct de­fined the mo­bile era. It’s a big ask for Ternus to do some­thing sim­i­lar for the AI age — but it’s an op­por­tu­nity that must be seized. AI threat­ens to dis­rupt the en­tire iPhone ecosys­tem. By the end of this decade, it’s un­likely that peo­ple will swipe on their phones to tap on Uber or Lyft. They will just tell their al­ways-on AI agent to get them home. Or that agent will have al­ready fig­ured out where they need to go, and the car will be wait­ing with­out the fric­tion of a re­quest. “There’s an app for that,” may be re­placed by “Let the agent do that.”

I’m a huge long­time Steven Levy fan, but this is non­sense. It’s hard to read this and not worry that he too has lost his mind to the AI snake-oil hy­pesters. What Ternus told him is ex­actly right. The Apple way is never to ship a tech­nol­ogy. The iPod was­n’t about MP3 files. It was­n’t about 1.8-inch hard dri­ves. It was about mu­sic. The iPhone did de­fine the mo­bile era (which we’re still very much in), but Apple does­n’t need to cap­i­tal­ize on every sin­gle mar­ket the mo­bile era opened up. Social me­dia is a defin­ing com­po­nent of the mo­bile era. It com­prises the en­tirety of Meta’s value and a siz­able slice of Google’s (via YouTube). Apple does­n’t have a so­cial net­work busi­ness. It’s fine — be­cause the way peo­ple con­sume and cre­ate so­cial me­dia is us­ing their phones.

Does AI “threaten to dis­rupt the en­tire iPhone ecosys­tem”? It’s pos­si­ble, but it does­n’t seem nearly as likely to me as Levy as­serts. Changing the iPhone ecosys­tem? Sure — that’s al­ready true. Obviating the iPhone ecosys­tem? I don’t see it. Levy’s ar­gu­ment re­minds me of the hype around “the cloud” when that first be­came a term. It’s so mean­ing­less when used broadly (e.g. “Everything will soon be in the cloud”) that it could mean any­thing. It’s step #2 in the gnomes-steal­ing-un­der­pants mas­ter plan.

The idea that AI agents “will have al­ready fig­ured out where [we] need to go, and the car will be wait­ing with­out the fric­tion of a re­quest” strikes me as pure fever dream high-on-the-hype fan­tasy. I’m just go­ing to step out­side a restau­rant when I’m done eat­ing a meal and a ride-share is go­ing to be there, wait­ing for me, with­out my hav­ing hailed it? Every time? And I’m go­ing to find this pleas­ing, not creepy? And ride-share dri­vers are go­ing to re­spond to all these re­quests, be­cause the re­quests will never be wrong? And this is go­ing to hap­pen, some­how, with­out my car­ry­ing a phone with me? And this is go­ing to hap­pen in the next four years? I don’t think I’d want this even if it were plau­si­ble, but it does­n’t sound plau­si­ble.

Actual prod­ucts have to be real. Actual ex­pe­ri­ences have to rely on ac­tual prod­ucts. How ex­actly in Levy’s end-of-this-decade sce­nario will we tell our “always-on AI agent” to get us home? What mi­cro­phone is lis­ten­ing to the com­mand? What speaker is telling us the re­quest was un­der­stood and acted upon? What screen do we look at to see how far away the hailed car is? I’d bet a pretty large sum of money that in 2030, when some­one hails a ride-share ve­hi­cle to take them home, the most com­mon prod­uct they’ll use to do that will be their phone. Whether they’re do­ing it via a ver­bal com­mand is­sued to an “always-on AI agent” or good old tap­ping and swip­ing, it’ll be a phone.

If you think that peo­ple will buy smaller de­vices to re­place their phones, and use those to talk to “always-on AI agents” in­stead, you have to an­swer some ques­tions. What com­pany is the best in the world at mak­ing smaller-than-phone per­sonal com­put­ing de­vices? What de­vice will peo­ple use as their cam­era? What de­vice will peo­ple use as their screen, for watch­ing videos, play­ing games, tex­ting, and (one hopes) read­ing? My an­swers to those three ques­tions: Apple, phone, phone. Why would smaller de­vices — you know, like watches, ear­buds, and, say, glasses — work in­de­pen­dently rather than pair with the phone that you’re al­most cer­tainly still go­ing to be car­ry­ing with you?

Only a fool would ar­gue that Apple can stand on the side­lines and ig­nore AI. It’s very dif­fer­ent from, say, so­cial me­dia that way. Social me­dia does­n’t per­vade every­thing in tech­nol­ogy. You can ig­nore so­cial me­dia as a user. (And you’re prob­a­bly more pro­duc­tive, and hap­pier, if you do.) A com­pany can es­chew so­cial me­dia as a busi­ness. AI, on the other hand, is per­va­sive. It can’t be ig­nored. But it’s just tech­nol­ogy.

Wireless net­work­ing is per­va­sive too. But Apple does­n’t have “a killer wire­less net­work­ing prod­uct”.1 Wireless net­work­ing sim­ply per­vades every­thing Apple makes. I’m hard pressed to think of a sin­gle prod­uct Apple makes that does­n’t use some com­bi­na­tion of Wi-Fi, cel­lu­lar, Bluetooth, and pro­pri­etary wire­less pro­to­cols. There was a time, not too long ago, when Apple did­n’t make a sin­gle prod­uct with wire­less con­nec­tiv­ity. Now it’s per­va­sive in all their de­vices. That’s more what AI is go­ing to be like. There’s not go­ing to be one “killer AI de­vice”. Everything is go­ing to be an AI de­vice, to some ex­tent, just like how every­thing to­day is a wire­less con­nec­tiv­ity de­vice, to some ex­tent.

AirPort qual­i­fied, ar­guably. But Apple walked away from it, alas. ↩︎

AirPort qual­i­fied, ar­guably. But Apple walked away from it, alas. ↩︎

Offline Agentic Coding part 3: Apple Silicon costs more than OpenRouter.

Published 2026 – 05-17

Apple sil­i­con costs more than OpenRouter.

At ~50 – 100 watts un­der load, and ~$0.20 per kWh, my M5 MacbookPro will cost a few cents per hour. Accelerated de­pre­ci­a­tion (if any) from short­en­ing the lifes­pan of the de­vice will be more ex­pen­sive than the elec­tric­ity. At a few tens of to­kens per sec­ond this works out to am­mor­tized costs of ~$1.50 per mil­lion to­kens. Openrouter for com­pa­ra­ble mod­els is 1/3rd the price and ~2x the speed.

Electricity

In Northern Virginia my last elec­tric­ity bill worked out to $0.18 per kilo­watt hour. Let’s round up to $0.20 per kWh.

EIA has av­er­age res­i­den­tial costs for 2025 at $0.1730 per kWh in the US. https://​www.eia.gov/​elec­tric­ity/​monthly/​ep­m_table_­g­ra­pher.php?t=table_5_03

At ~50 – 100 watts and $0.18/kWh that’s $0.009 or $0.018 per hour. $0.02 per hour. $0.48 cents per day for the elec­tric­ity to be run­ning in­fer­ence at 100%.

Hardware

A 14 inch MBP with M5 Max and 64 gigs of ram is cur­rently listed as $4299 on the ap­ple web­site. 128 gigs will cost you more but 64 gigs should run a model like Gemma 4 31b, which is al­most an­thropic son­net lev­els of per­for­mance.

For cost al­lo­ca­tion, let’s con­sider that this hard­ware will last 3, 5, or 10 years. The cost per year is $1433, $860, or $430 re­spec­tively.

The hourly cost over 3, 5, and 10 years is thus:

$0.16358

$0.09815

$0.04908

Depending on use­ful lifes­pan, I think 5 years is a rea­son­able es­ti­mate for nor­mal use. 7 or 10 is very plau­si­ble. At maxed out in­fer­ence 3 years may be a rea­son­able es­ti­mate as well.

Tokenomics

The big ques­tion is how many to­kens per hour can you get out of a lo­cal model. My M5 Max test­ing seems to be in the 10 – 40 to­kens per sec­ond range for a se­ri­ous model like Gemma4:31b. At 10 to­kens per sec­ond that’s 36000 to­kens per hour.

36000 to­kens per hour across our 3 – 10 year lifes­pan at $0.18 per kwh gives a price per mil­lion to­kens of $1.61 to $4.79 on the high end.

At 40 to­kens per sec­ond that’s 144000 to­kens per hour which gets you to $0.40 to $1.20 per mil­lion to­kens.

For ap­ple sil­i­con, the hard­ware cost dom­i­nates.

OpenRouter has Gemma4 31b at ~38 – 50 cents per mil­lion to­kens. This means that on the op­ti­mistic side (50 watts, 40 to­kens per sec­ond, and 10 years) the pro max is as cheap as open­router. On the pes­simistic side (100 watts and 3 years at 10 to­kens per sec­ond) the pro max is 10x the cost. I think ~3x the cost per mil­lion to­kens is likely the right num­ber for lo­cal in­fer­ence on the pro max from an ac­count­ing per­spec­tive.

Conclusion

Speed of in­fer­ence is the biggest fac­tor here though for most cases. Local in­fer­ence is slower than cloud in­fer­ence. Some of the gemma 4 providers on open­router get up to 60 – 70 to­kens per sec­ond, which is 3 – 7 times faster than what I’m see­ing with the pro max (~10 – 20 to­kens per sec­ond). For a hu­man em­ployee with a work lap­top, their salary costs are go­ing to be ~1000x the cost of the to­kens they can gen­er­ate lo­cally. Throwing money at an­thropic makes more sense in this con­text.

It’s still wild that a con­sumer de­vice can run mod­els that are close to an­thropic son­net lev­els of per­for­mance.

Please en­able JS and dis­able any ad blocker

rkde­bian — Debian 12 for Doogee U10 (RK3562)

Download Pre-release Image

Current pub­lic build (pre-release, May 14, 2026):

Release page: tech4bot/​rk3562deb pre­re­lease-14052026 Direct im­age down­load: rk3562-de­bian.img.xz Video demo: YouTube

Current pub­lic build (pre-release, May 14, 2026):

Release page: tech4bot/​rk3562deb pre­re­lease-14052026

Direct im­age down­load: rk3562-de­bian.img.xz

Video demo: YouTube

Run full Debian 12 Bookworm on your Doogee U10 tablet — no boot­loader un­lock re­quired. Boot from SD card, re­move it to re­turn to stock Android. No changes to in­ter­nal stor­age.

Run full Debian 12 Bookworm on your Doogee U10 tablet — no boot­loader un­lock re­quired. Boot from SD card, re­move it to re­turn to stock Android. No changes to in­ter­nal stor­age.

Reverse en­gi­neered from scratch — no BSP, no ven­dor doc­u­men­ta­tion, no of­fi­cial sup­port. Built with the help of Claude, Codex, and Antigravity (Google Gemini), us­ing Firefly RK3562 open-source repos­i­to­ries as a start­ing point.

Reverse en­gi­neered from scratch — no BSP, no ven­dor doc­u­men­ta­tion, no of­fi­cial sup­port. Built with the help of Claude, Codex, and Antigravity (Google Gemini), us­ing Firefly RK3562 open-source repos­i­to­ries as a start­ing point.

Overview

rkde­bian is a build sys­tem that pro­duces a com­plete, bootable Debian 12 Bookworm im­age for the Doogee U10 Android tablet, pow­ered by the Rockchip RK3562 SoC.

The re­sult­ing im­age is writ­ten to an SD card. Insert it and power on — the tablet boots Debian. Remove the SD card and it boots Android from in­ter­nal eMMC as nor­mal.

Hardware: Doogee U10

What Works

Default Installed Apps

NPU LLM (RK3562)

This tablet im­age sup­ports lo­cal LLM in­fer­ence on the RK3562 NPU us­ing Rockchip’s RKLLM stack.

NPU soft­ware used

airockchip/​rknn-llm — run­time, RKLLM toolkit, demo app (llm_demo)

airockchip/​rknn-toolk­it2 — RKNN con­ver­sion/​tool­chain de­pen­dency used by RKLLM work­flows

Model con­ver­sion setup used

Target plat­form: rk3562

Quantization: W8A8

NPU cores: num_n­pu_­core=1 (RK3562 sup­ports one NPU core)

Optimization level: 0 (chosen for com­pat­i­bil­ity/​sta­bil­ity on this board)

Example con­ver­sion com­mand (host PC):

python3 con­vert_qwen_rk3562.py \ –model-dir ./models/Qwen3 – 0.6B \ –target-platform rk3562 \ –quantized-dtype W8A8 \ –optimization-level 0 \ –num-npu-core 1 \ –output ./out/Qwen3 – 0.6B_W8A8_RK3562_opt0.rkllm

Benchmark (on tablet, NPU path)

Measured on April 6, 2026 on <tablet-ip> with:

prompt: Output ex­actly 300 English words about arith­metic speed test­ing do not in­clude punc­tu­a­tion and do not stop early

MAX_NEW_TOKENS=64, MAX_CONTEXT_LEN=1024

run­ner: ~/npu-test/xcompile/demo_Linux_aarch64/run_llm_rk3562.sh

Commands used:

# Qwen3 – 0.6B (first run in­cludes fix_freq) USE_FIX_FREQ=1 RKLLM_LOG_LEVEL=1 PROMPT=“Output ex­actly 300 English words about arith­metic speed test­ing do not in­clude punc­tu­a­tion and do not stop early” \ ./run_llm_rk3562.sh ~/npu-test/models/Qwen3 – 0.6B_W8A8_RK3562_opt0.rkllm 64 1024

# Qwen2.5 – 1.5B USE_FIX_FREQ=0 RKLLM_LOG_LEVEL=1 PROMPT=“Output ex­actly 300 English words about arith­metic speed test­ing do not in­clude punc­tu­a­tion and do not stop early” \ ./run_llm_rk3562.sh ~/npu-test/models/Qwen2.5 – 1.5B-Instruct_W8A8_RK3562.rkllm 64 1024

Warm-run av­er­age (runs 2 – 3):

Result: Qwen3 – 0.6B is sig­nif­i­cantly faster on this RK3562 tablet for lo­cal NPU in­fer­ence.

Known Issues

Battery may re­port 0% af­ter the tablet has been pow­ered off for a cou­ple of hours.

rk-bat­tery-gauge-fix.ser­vice fixes this on boot.

If the tablet did not fully power off, re­boot once; on the next boot the bat­tery level should be cor­rected.

Front (s5k5e8) and rear (s5k4h5yb) cam­era pre­view/​cap­ture are func­tional, but col­ors are still slightly off and re­quire ad­di­tional ISP cal­i­bra­tion.

Requirements

Host ma­chine: x86 – 64 Linux (Debian/Ubuntu rec­om­mended)

Install all build de­pen­den­cies with:

sudo apt-get in­stall \ git make gcc-aarch64-linux-gnu \ bc bi­son flex de­vice-tree-com­piler \ gen­im­age wget tar mtools \ xz-utils \ de­boot­strap qemu-user-sta­tic \ e2f­sprogs

Building

Full build (recommended)

Builds U-Boot, ker­nel, Debian rootfs, and pro­duces a ready-to-flash SD card im­age:

./build.sh all

With full log­ging to file (tee) while pre­serv­ing the real build exit sta­tus:

set -o pipefail ./build.sh all 2>&1 | tee build.log

./build.sh with no tar­get de­faults to all.

The fi­nal im­age is writ­ten to:

out/​rk3562-de­bian.img.xz — com­pressed fi­nal im­age (recommended)

out­put/​up­date/​up­date.img.xz — com­pressed Firefly-compatible path

Compatibility/raw im­ages are also kept:

out/​rk3562-de­bian.img

out­put/​up­date/​up­date.img

CLI us­age and op­tions

./build.sh [options] {check|lunch|uboot|extboot|updateimg|updatepkg|compile|rootfs|image|all}

Individual build tar­gets

im­age and up­datepkg re­quire ex­ist­ing build ar­ti­facts (out/rootfs, ker­nel/​DTB, and boot con­fig files).

Environment Variables

These vari­ables can be set be­fore run­ning build.sh to con­trol build be­hav­iour:

Rootfs

Kernel

Examples

# Force a clean rootfs re­build RKDEBIAN_FORCE_CLEAN_ROOTFS=1 ./build.sh all

# Same us­ing CLI flags ./build.sh all –force-clean-rootfs

# Force clean rootfs re­build with a fixed 4 GB rootfs par­ti­tion RKDEBIAN_FORCE_CLEAN_ROOTFS=1 ROOTFS_IMAGE_SIZE=4G ./build.sh all

# Build only the rootfs, force clean RKDEBIAN_FORCE_CLEAN_ROOTFS=1 ./build.sh rootfs

# Rebuild im­age only (U-Boot and ker­nel al­ready built) ./build.sh im­age

# Build ker­nel only ./build.sh ext­boot

# Keep over­lay PMIC patches dur­ing ker­nel build RKDEBIAN_KEEP_OVERLAY_PMIC_PATCHES=1 ./build.sh ext­boot

# Force a Wayland desk­top im­age for test­ing ./build.sh all –display-server=wayland

# Explicitly dis­able force-clean (useful in scripted runs) ./build.sh all –no-force-clean-rootfs

# Override base­line gov­er­nor used for Phosh bal­anced mode map­ping RKDEBIAN_CPU_GOVERNOR=schedutil ./build.sh all

# Show CLI us­age and tar­get list ./build.sh –help

# Build a Phosh im­age on Mesa/Panfrost (clean rootfs strongly ad­vised) ./build.sh all –ui-session=phosh –gpu-stack=panfrost –force-clean-rootfs

# Mali stack with Debian libgbm over­ride (only for com­pat­i­bil­ity test­ing) RKDEBIAN_MALI_GBM_PROVIDER=debian ./build.sh all –ui-session=phosh –gpu-stack=mali –force-clean-rootfs

# Size-focused build for eas­ier GitHub up­loads RKDEBIAN_FORCE_CLEAN_ROOTFS=1 RKDEBIAN_MINIMIZE_IMAGE=1 RKDEBIAN_PREINSTALL_FREETUBE=0 ./build.sh all

# Size-focused build while keep­ing de­fault FreeTube pre­in­stall en­abled RKDEBIAN_FORCE_CLEAN_ROOTFS=1 RKDEBIAN_MINIMIZE_IMAGE=1 RKDEBIAN_PREINSTALL_FREETUBE=1 ./build.sh all

When chang­ing RKDEBIAN_UI_SESSION or RKDEBIAN_GPU_STACK, use –force-clean-rootfs to avoid stale pack­age carry-over.

Phosh Power Mode Mapping

Images in­clude rk-power-pro­file-sync.ser­vice, which maps Phosh power modes (power-profiles-daemon) to cpufreq pol­icy on-de­vice:

bal­anced -> gov­er­nor from RKDEBIAN_CPU_GOVERNOR (default per­for­mance), max freq cap 100%

power-saver -> gov­er­nor pow­er­save, max freq cap 65%

per­for­mance (if ex­posed by hard­ware) -> gov­er­nor per­for­mance, max freq cap 100%

Tune map­ping on-de­vice in /etc/default/rk-power-profile-map.

Phosh UX Integrations

Rear cam­era flash­light is ex­posed as LED cam­era:flash, so Phosh shows the na­tive top-menu torch icon.

rk-flash­lightctl sup­ports both tog­gle and in­ten­sity con­trol (set 0..100) for the rear LED.

rk-pow­erkey-long­press.ser­vice owns hard­ware power-key pol­icy:

short press (<3s) -> sus­pend on key re­lease long press (>=3s) -> stan­dard GNOME shut­down di­a­log logind/​GNOME press-trig­gered de­faults are dis­abled to avoid im­me­di­ate sleep on key-down

short press (<3s) -> sus­pend on key re­lease

long press (>=3s) -> stan­dard GNOME shut­down di­a­log