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 ↩︎

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.

Back in 2019, I built a sim­ple volt­meter clock:

As the name im­plies, these clocks use ana­log panel volt­meters in­stead of tra­di­tional clock faces to dis­play time. I did­n’t come up with the idea, so I never re­ally blogged about the de­sign; I just built one and kept it on my of­fice desk.

The idea en­dures, but most of the de­signs I see on the in­ter­net are need­lessly com­pli­cated and not all that pretty, so when I de­cided to build a re­vised de­sign, I fig­ured it might be good to doc­u­ment it bet­ter. The process started with a rough mockup in a 3D de­sign pro­gram:

For this ver­sion of the me­ter clock, I opted to use three generic, 90° panel volt­meters from Amazon (link, about $9). I dis­as­sem­bled them, took care­ful mea­sure­ments of the faces, and then printed re­place­ment de­cals on ad­he­sive pa­per. Printable PDF tem­plates can be found here.

Note that the new hour gauge has 13 di­vi­sions, from 0 to 12, while the minute and sec­ond tem­plates have 61 di­vi­sions, from 00 to 60. This is be­cause I wanted to im­ple­ment con­tin­u­ous mo­tion for each hand; this meant that at 11:30, the hour dial could­n’t be just stuck at 11; it needed to be mov­ing to­ward the twelfth di­vi­sion, even if it was never to reach it.

In ad­di­tion to a host of other prob­lems, the cheap “Baomain 65C5” me­ters I’m us­ing have a rather hideous plas­tic flange. I de­cided to hide this flange from view and use a re­cessed dec­o­ra­tive pat­tern to keep the front panel in­ter­est­ing. This made it more ex­pe­di­ent to cut the front and back on a CNC mill in­stead of build­ing the en­clo­sure by hand (as I did for ver­sion 1). The stock ma­te­r­ial is maple lum­ber re­sawn, squared, and planed in my work­shop:

The rounded side wall posed a dif­fer­ent chal­lenge. For a seam­less ap­pear­ance, I needed to do bend a flat piece of wood us­ing a shaped tem­plate. To pull this off with­out a steam bend­ing jig, I had to cut a se­ries of in­ter­nal notches on the side wall. This al­lowed the wood to flex more eas­ily:

The wood had to be moist­ened, clamped, and then al­lowed to dry. After a cou­ple of days, I glued the curved side wall to the front and back faces, re­ly­ing on an­other tem­plate cut out of scrap ply­wood to get a pre­cise fit with­out any more gym­nas­tics with clamps and ratchet straps:

Anyway — here’s the as­sem­bled piece af­ter sand­ing and a coat of ni­tro­cel­lu­lose lac­quer:

Not bad, right?

The cir­cuit is far less in­ter­est­ing and took just an hour or so: I grabbed the ven­er­a­ble AVR128DB28 MCU, pow­ered it off a wall wart, in­ter­faced it to an 8 MHz crys­tal (ECS-80 – 18-4X-CKM). A 32.768 kHz crys­tal would also do. The pan­els are con­nected to three dig­i­tal out­put pins (PC0, PC1, PC2). Finally, two in­put pins (PD6, PD7) are in­ter­faced to two small push­but­tons mounted on the back and used to set time.

Note that the cir­cuit does­n’t re­quired dig­i­tal-to-ana­log con­vert­ers or any other ad­di­tional com­po­nents to drive the me­ters; in­stead, I’m just us­ing a rel­a­tively high-fre­quency, 1-bit dig­i­tal pulse train. The in­er­tia of the me­ter (and the in­duc­tance of the coil in­side the me­ter) does the rest, set­tling in an in­ter­me­di­ate po­si­tion de­pend­ing on the soft­ware-con­trolled sig­nal duty cy­cle.

The code can be viewed here; it’s short and well-com­mented. The ba­sic idea is to ad­vance a 10 Hz counter us­ing a timer in­ter­rupt syn­chro­nized with the crys­tal. With this out of the way, the main event loop com­putes the ap­pro­pri­ate duty cy­cle and then man­u­ally tog­gles the out­put pins. Although the chip has a hard­ware PWM mod­ule, the ap­pli­ca­tion is sim­ple enough that us­ing the PWM cir­cuitry would­n’t re­ally buy us any­thing.

Here’s the oblig­a­tory “rollover” video cap­tured around 11:59:59:

Peace out.

If you’re new here, you might en­joy some of my other ar­ti­cles:

No posts

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.

In to­day’s episode of “dumb things to do with an AVR mi­cro­con­troller”:

MCU web­site demo (may go down if this gets posted to HN)

My vic­tim is the AVR64DD32 which is quite sim­i­lar to the Atmega328 of Arduino fame. Compared to the older Atmega, these AVR DD lines are cheaper for the same mem­ory, use a sin­gle pro­gram­ming pin and have nicer pe­riph­er­als:

So that’s the com­puter (a rather spa­cious one at that) but it’ll need an in­ter­net con­nec­tion to host a web­site.

The ob­vi­ous choice is Ethernet, but even the slow­est ver­sion (10BASE-T) still runs at 10 megabits/​sec­ond. Worse, it uses Manchester en­cod­ing: a zero is sent as “10” and a one as “01″, so 10 megabits of data is ac­tu­ally 20 megabits at the wire.

This is sim­ply too fast for the AVR to gen­er­ate. While it’s proces­sor can run at 24 MHz, but all the pe­riph­er­als and IO pins max out at a 12 MHz clock. (although some other 8-bit chips should be able to do it)

The proper so­lu­tion is to buy a ded­i­cated eth­er­net chip from DigiKey, but then I’d be wait­ing weeks to fin­ish this pro­ject.

… and eth­er­net is far from the only op­tion:

Serial Line Internet Protocol (RFC 1055) is a very old and very sim­ple stan­dard for run­ning net­works over se­r­ial:

Before send­ing a packet, wrap it in 0xC0 bytes. If the packet con­tains any 0xC0 bytes, re­place them with 0xDB 0xDC. To avoid am­bi­gu­ity, any pre-ex­ist­ing 0xDB bytes are re­placed with 0xDB 0xDD.

This scheme was widely used for con­nect­ing to the in­ter­net in the olden days: A dial up mo­dem cre­ates a se­r­ial link over a phone line, and it’s up the the com­puter to do any­thing with it. (This also means that they are not lim­ited to net­work­ing: those same modems could be con­nected to a ter­mi­nal for re­mote ac­cess)

… which is why SLIP is still sup­ported by mod­ern Linux:

# Just a nor­mal USB to Serial adapter stty -F /dev/ttyUSB0 115200 raw cs8 slat­tach -m -F -L -p slip /dev/ttyUSB0 # … and now it’s a net­work in­ter­face

The hard­ware on the mi­cro­con­troller’s end is triv­ial:

It does work with no ex­ter­nal com­po­nents, but I wanted some blinken­lights, and an id­iot-proof­ing diode for when I in­evitably con­nect the power back­wards.

Because it only draws a few mil­li­watts, it can run the server of the se­r­ial adapter’s 5 volt rail: it’s re­ally nice to only have one ca­ble to deal with.

Now it has an in­ter­net con­nec­tion, but that’s hardly a server.

In or­der for my web page to get to your com­puter, it needs to pass through dozens of dif­fer­ent net­works. To do this, each packet has an IP header: 40 bytes that con­tain the ad­dress of the source and des­ti­na­tion com­put­ers, and some other stuff I don’t re­ally care about.

The pro­to­col used to be a lot more com­plex, with fea­tures like packet frag­men­ta­tion that re­quire a lot of mem­ory to han­dle cor­rectly, but I don’t have to: every mod­ern op­er­at­ing sys­tem dis­ables frag­men­ta­tion and IPv6 re­moved it en­tirely.

This makes im­ple­ment­ing it very easy: Just swap around the source and des­ti­na­tion of a re­cieved packet to gen­er­ate the header for the re­sponse. (and re­set the TTL counter)

The other pro­to­col, TCP is a lot harder: Implementing it re­quires the mi­cro­con­troller to track con­nec­tion states, pe­ri­od­i­cally re­trans­mit lost pack­ets and han­dle a huge num­ber edge cases.

It took sev­eral days to get my cus­tom im­ple­men­ta­tion work­ing well enough, and it’s still got a few bugs.

As for im­ple­ment­ing HTTP, I did­n’t: The server al­ways sends a hard­coded “response” back to the client. This works fine as long as there’s only a sin­gle URL on the site.

[Video of the page load­ing. See web or files di­rec­tory: load­ing.mp4]

Ok great, but what if I want to share it with friends? Unfortunately, for their re­quests to reach it, it needs a pub­li­cally routable IPv4 ad­dress. Not only are these ex­pen­sive but it’s im­pos­si­ble to get a good in­ter­net con­nec­tion at my place.

(no, Starlink is not good)

I do have a ma­chine with a pub­li­cally routable ad­dress, but it’s at a dat­a­cen­ter near Helsinki: I’d need a very long se­r­ial ca­ble…

an­other cool thing Linux sup­ports is wire­guard, which cre­ates a vir­tual net­work link over the in­ter­net. This works even if one of the ma­chines is be­hind (CG)NAT or other an­noy­ances.

Problem solved:

have the Linux router box con­nect to the VPS to get a proper in­ter­net con­nec­tion?

… ex­cept the MCU still does­n’t have it’s own IP ad­dress: I could for­ward every­thing from my VPS’s ad­dress to it, but that would break my nor­mal web­site.

Instead, I setup the server to proxy any re­quests un­der /mcu to the server us­ing a lo­cal ad­dress block. This means that vis­i­tors aren’t di­rectly con­nect­ing to the MCU’s TCP/IP stack… but hey, it’s the same setup that the Vape Server uses and no one com­plained.

(It also makes it slightly harder to break by send­ing SYN pack­ets, but it’s not ex­actly hard to DDoS a server con­nected over what’s ef­fec­tively dial-up)

Related:

/mcu: The page hosted from the mi­cro­con­troller.

http://​ewaste.fka.wtf/: The Vape Server, a web­site hosted off a 32-bit MCU pulled from the trash.

https://​lcamtuf.sub­stack.com/​p/​psa-if-youre-a-fan-of-at­mega-try: lcamtuf on the AVR Dx line.

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