10 interesting stories served every morning and every evening.

Ghostty Is Leaving GitHub

mitchellh.com

Writing this makes me ir­ra­tionally sad, but Ghostty will be leav­ing GitHub1.

I’m GitHub user 1299, joined Feb 2008.

Since then, I’ve opened GitHub every sin­gle day. Every day, mul­ti­ple times per

day, for over 18 years. Over half my life. A hand­ful of ex­cep­tions in there

(I’d love to see the data), but I can’t imag­ine more than a week per year.

GitHub is the place that has made me the most happy. I al­ways made time for

it. When I went through tough breakups? I lost my­self in open source… on

GitHub. During col­lege at 4 AM when every­one is passed out? Let me get one

com­mit in. During my hon­ey­moon while my wife is still asleep? Yeah, GitHub.

It’s where I’ve his­tor­i­cally been hap­pi­est and wanted to be.

Even the an­noy­ing stuff! Some peo­ple doom scroll so­cial me­dia. I’ve been doom

scrolling GitHub is­sues since be­fore that was a word. On va­ca­tions I’d have

book­marks of dif­fer­ent pro­jects on GitHub I wanted to study. Not just source

code, but OSS processes, how other main­tain­ers re­act to dif­fi­cult sit­u­a­tions.

Etc. Believe it or not, I like this.

Some might call this sick, but my hobby and work and pas­sion all align and for

most of my life they got to also live in one place on the in­ter­net: GitHub.

Did you know I started Vagrant (my first suc­cess­ful open source pro­ject) in

large part be­cause I hoped it would get me a job at GitHub? It’s no se­cret,

I’ve said this re­peat­edly, and in my first pub­lic talk about Vagrant, when I

was a mere 20 years old, I joked maybe GitHub will hire me if it’s good!”

GitHub was my dream job. I did­n’t ever get to work there (not their fault).

But it was the per­fect place I wanted to be. The en­gi­neers were in­cred­i­ble,

the prod­uct was in­cred­i­ble, and it was some­thing I lived and breathed every

day. I still do and con­sis­tently have… for these 18 years. Enough time for

an en­tire hu­man to be­come an adult, all on GitHub.

Lately, I’ve been very pub­licly crit­i­cal of GitHub. I’ve been mean about it.

I’ve been an­gry about it. I’ve hurt peo­ple’s feel­ings. I’ve been lash­ing out.

Because GitHub is fail­ing me, every sin­gle day, and it is per­sonal. It is

ir­ra­tionally per­sonal. I love GitHub more than a per­son should love a thing,

and I’m mad at it. I’m sorry about the hurt feel­ings to the peo­ple work­ing on

it.

I’ve felt this way for a long time, but for the past month I’ve kept a jour­nal

where I put an X” next to every date where a GitHub out­age has neg­a­tively

im­pacted my abil­ity to work2. Almost every day has an X. On the day I am

writ­ing this post, I’ve been un­able to do any PR re­view for ~2 hours be­cause

there is a GitHub Actions out­age3. This is no longer a place for se­ri­ous

work if it just blocks you out for hours per day, every day.

It’s not a fun place for me to be any­more. I want to be there but it does­n’t

want me to be there. I want to get work done and it does­n’t want me to get

work done. I want to ship soft­ware and it does­n’t want me to ship soft­ware.

I want it to be bet­ter, but I also want to code. And I can’t code with GitHub

any­more. I’m sorry. After 18 years, I’ve got to go. I’d love to come back one

day, but this will have to be pred­i­cated on real re­sults and im­prove­ments,

not words and promises.

I’ll share more de­tails about where the Ghostty pro­ject will be mov­ing to in

the com­ing months. We have a plan but I’m also very much still in dis­cus­sions

with mul­ti­ple providers (both com­mer­cial and FOSS).

It’ll take us time to re­move all of our de­pen­den­cies on GitHub and we have a

plan in place to do it as in­cre­men­tally as pos­si­ble. We plan on keep­ing a

read-only mir­ror avail­able on GitHub at the cur­rent URL.

My per­sonal pro­jects and other work will re­main on GitHub for now.

Ghostty is where I, our main­tain­ers, and our open source com­mu­nity are

most im­pacted so that is the fo­cus of this change. We’ll see where it

goes af­ter that.

Footnotes

The tim­ing of this is co­in­ci­den­tal with the large out­age on April 27, 2026.

We’ve been dis­cussing and putting to­gether a plan to leave GitHub

for months, and this blog post was writ­ten over a week ago. We only

made the fi­nal de­ci­sion this week. ↩

The tim­ing of this is co­in­ci­den­tal with the large out­age on April 27, 2026.

We’ve been dis­cussing and putting to­gether a plan to leave GitHub

for months, and this blog post was writ­ten over a week ago. We only

made the fi­nal de­ci­sion this week. ↩

To the Git is dis­trib­uted!” crowd: the is­sue is­n’t Git, it’s the

in­fra­struc­ture we rely on around it: is­sues, PRs, Actions, etc. ↩

To the Git is dis­trib­uted!” crowd: the is­sue is­n’t Git, it’s the

in­fra­struc­ture we rely on around it: is­sues, PRs, Actions, etc. ↩

This is not the large Elasticsearch out­age they had on April 27, 2026.

This blog post was writ­ten a week be­fore that, so this was a dif­fer­ent

out­age. ↩

This is not the large Elasticsearch out­age they had on April 27, 2026.

This blog post was writ­ten a week be­fore that, so this was a dif­fer­ent

out­age. ↩

DeepSeek V4 Preview Release | DeepSeek API Docs

api-docs.deepseek.com

🚀 DeepSeek-V4 Preview is of­fi­cially live & open-sourced! Welcome to the era of cost-ef­fec­tive 1M con­text length.

🔹 DeepSeek-V4-Pro: 1.6T to­tal / 49B ac­tive params. Performance ri­val­ing the world’s top closed-source mod­els.

🔹 DeepSeek-V4-Flash: 284B to­tal / 13B ac­tive params. Your fast, ef­fi­cient, and eco­nom­i­cal choice.

Try it now at chat.deepseek.com via Expert Mode / Instant Mode. API is up­dated & avail­able to­day!

📄 Tech Report: https://​hug­ging­face.co/​deepseek-ai/​DeepSeek-V4-Pro/​blob/​main/​DeepSeek_V4.pdf

🤗 Open Weights: https://​hug­ging­face.co/​col­lec­tions/​deepseek-ai/​deepseek-v4

DeepSeek-V4-Pro​

🔹 Enhanced Agentic Capabilities: Open-source SOTA in Agentic Coding bench­marks.

🔹 Rich World Knowledge: Leads all cur­rent open mod­els, trail­ing only Gemini-3.1-Pro.

🔹 World-Class Reasoning: Beats all cur­rent open mod­els in Math/STEM/Coding, ri­val­ing top closed-source mod­els.

DeepSeek-V4-Flash​

🔹 Reasoning ca­pa­bil­i­ties closely ap­proach V4-Pro.

🔹 Performs on par with V4-Pro on sim­ple Agent tasks.

🔹 Smaller pa­ra­me­ter size, faster re­sponse times, and highly cost-ef­fec­tive API pric­ing.

Structural Innovation & Ultra-High Context Efficiency​

🔹 Novel Attention: Token-wise com­pres­sion + DSA (DeepSeek Sparse Attention).

🔹 Peak Efficiency: World-leading long con­text with dras­ti­cally re­duced com­pute & mem­ory costs.

🔹 1M Standard: 1M con­text is now the de­fault across all of­fi­cial DeepSeek ser­vices.

Dedicated Optimizations for Agent Capabilities​

🔹 DeepSeek-V4 is seam­lessly in­te­grated with lead­ing AI agents like Claude Code, OpenClaw & OpenCode.

🔹 Already dri­ving our in-house agen­tic cod­ing at DeepSeek.

The fig­ure be­low show­cases a sam­ple PDF gen­er­ated by DeepSeek-V4-Pro.

API is Available Today!​

🔹 Keep base_url, just up­date model to deepseek-v4-pro or deepseek-v4-flash.

🔹 Supports OpenAI ChatCompletions & Anthropic APIs.

🔹 Both mod­els sup­port 1M con­text & dual modes (Thinking / Non-Thinking): https://​api-docs.deepseek.com/​guides/​think­ing_­mode

⚠️ Note: deepseek-chat & deepseek-rea­soner will be fully re­tired and in­ac­ces­si­ble af­ter Jul 24th, 2026, 15:59 (UTC Time). (Currently rout­ing to deepseek-v4-flash non-think­ing/​think­ing).

🔹 Amid re­cent at­ten­tion, a quick re­minder: please rely only on our of­fi­cial ac­counts for DeepSeek news. Statements from other chan­nels do not re­flect our views.

🔹 Thank you for your con­tin­ued trust. We re­main com­mit­ted to longter­mism, ad­vanc­ing steadily to­ward our ul­ti­mate goal of AGI.

Your First API Call | DeepSeek API Docs

api-docs.deepseek.com

The DeepSeek API uses an API for­mat com­pat­i­ble with OpenAI/Anthropic. By mod­i­fy­ing the con­fig­u­ra­tion, you can use the OpenAI/Anthropic SDK or soft­wares com­pat­i­ble with the OpenAI/Anthropic API to ac­cess the DeepSeek API.

* The model names deepseek-chat and deepseek-rea­soner will be dep­re­cated on 2026/07/24. For com­pat­i­bil­ity, they cor­re­spond to the non-think­ing mode and think­ing mode of deepseek-v4-flash, re­spec­tively.

Invoke The Chat API​

Once you have ob­tained an API key, you can ac­cess the DeepSeek model us­ing the fol­low­ing ex­am­ple scripts in the OpenAI API for­mat. This is a non-stream ex­am­ple, you can set the stream pa­ra­me­ter to true to get stream re­sponse.

For ex­am­ples us­ing the Anthropic API for­mat, please re­fer to Anthropic API.

curl

python

nodejs

curl https://​api.deepseek.com/​chat/​com­ple­tions \ -H Content-Type: ap­pli­ca­tion/​json” \ -H Authorization: Bearer ${DEEPSEEK_API_KEY}” \ -d { model”: deepseek-v4-pro”, messages”: [ {“role”: system”, content”: You are a help­ful as­sis­tant.“}, {“role”: user”, content”: Hello!“} ], thinking”: {“type”: enabled”}, reasoning_effort”: high”, stream”: false }’

Keep Android Open

keepandroidopen.org

Your phone is about to stop be­ing yours.

125 days un­til lock­down

Starting September 2026, a silent up­date, non­con­sen­su­ally pushed by Google, will block every Android app whose de­vel­oper has­n’t reg­is­tered with Google, signed their con­tract, paid up, and handed over gov­ern­ment ID.

Every app and every de­vice, world­wide, with no opt-out.

Post on X Post on Mastodon Post on Bluesky LinkedIn Facebook

What Google is do­ing

In August 2025, Google an­nounced a new re­quire­ment: start­ing September 2026, every Android app de­vel­oper must reg­is­ter cen­trally with Google be­fore their soft­ware can be in­stalled on any de­vice. Not just Play Store apps: all apps. This in­cludes apps shared be­tween friends, dis­trib­uted through F-Droid, built by hob­by­ists for per­sonal use. Independent de­vel­op­ers, church and com­mu­nity groups, and hob­by­ists alike will all be frozen out of be­ing able to de­velop and dis­trib­ute their soft­ware.

Registration re­quires:

Paying a fee to Google

Agreeing to Google’s Terms and Conditions

Surrendering your gov­ern­ment-is­sued iden­ti­fi­ca­tion

Providing ev­i­dence of your pri­vate sign­ing key

Listing all cur­rent and all fu­ture ap­pli­ca­tion iden­ti­fiers

If a de­vel­oper does not com­ply, their apps get silently blocked on every Android de­vice world­wide.

Who this hurts

You

You bought an Android phone be­cause Google told you it was open. You could in­stall what you wanted, and that was the deal.

Google is now rewrit­ing that deal, retroac­tively, on hard­ware you al­ready own. After the up­date lands, you can only run soft­ware that Google has pre-ap­proved. On your phone: your prop­erty, that you paid for.

Independent de­vel­op­ers

A teenager’s first app, a vol­un­teer’s pri­vacy tool, or a com­pa­ny’s con­fi­den­tial in­ter­nal beta. It does­n’t mat­ter. After September 2026, none of these can be in­stalled with­out Google’s bless­ing.

F-Droid, home to thou­sands of free and open-source Android apps, has called this an existential” threat. Cory Doctorow calls it Darth Android”.

Governments & civil so­ci­ety

Google has a doc­u­mented track record of com­ply­ing when au­thor­i­tar­ian regimes de­mand app re­movals. With this pro­gram, the soft­ware that runs your coun­try’s in­sti­tu­tions will ex­ist at the plea­sure of a sin­gle un­ac­count­able for­eign cor­po­ra­tion.

The EFF calls app gate­keep­ing an ever-ex­pand­ing path­way to in­ter­net cen­sor­ship.”

Google’s escape hatch” is a trap door

Google says power users” can still in­stall” un­ver­i­fied apps. Here’s what that ac­tu­ally looks like:

Delve into System Settings, find Developer Options

Tap the build num­ber seven times to en­able Developer Mode

Dismiss scare screens about co­er­cion

Enter your PIN

Restart the de­vice

Wait 24 hours

Come back, dis­miss more scare screens

Pick allow tem­porar­ily” (7 days) or allow in­def­i­nitely”

Confirm, again, that you un­der­stand the risks”

Nine steps. A manda­tory 24-hour cool­ing-off pe­riod. For in­stalling soft­ware on a de­vice you own.

Worse: this flow runs en­tirely through Google Play Services, not the Android OS. Google can change it, tighten it, or kill it at any time, with no OS up­date re­quired and no con­sent needed. And as of to­day, it has­n’t shipped in any beta, pre­view, or ca­nary build. It ex­ists only as a blog post and some mock­ups.

This is big­ger than Android

If Google can retroac­tively lock down bil­lions of de­vices that were sold as open plat­forms, every hard­ware man­u­fac­turer on the planet is watch­ing.

The prin­ci­ple be­ing es­tab­lished: the com­pany that made your de­vice gets to de­cide, af­ter you’ve bought it, what soft­ware you’re al­lowed to run. In soft­ware, this is called a rug pull”; but at least you could al­ways in­stall com­pet­ing soft­ware. In hard­ware, it is a fait ac­com­pli that strips you of your agency and ren­ders you pow­er­less to the whims of a sin­gle un­ac­count­able gate­keeper and con­victed mo­nop­o­list.

Android’s open­ness was never just a fea­ture. It was the promise that dis­tin­guished it from iPhone. Millions chose Android for ex­actly that rea­son. Google is now re­vok­ing that promise uni­lat­er­ally, on de­vices al­ready in peo­ple’s pock­ets, be­cause they’ve de­cided they have enough mar­ket dom­i­nance and reg­u­la­tory cap­ture to get away with it.

Ars Technica: Google’s Apple envy threat­ens to dis­man­tle Android’s open legacy.”

But wait, is­n’t this…

″…just about se­cu­rity?”

The se­cu­rity ra­tio­nale is a smoke­screen. Google Play Protect al­ready scans for mal­ware in­de­pen­dent of de­vel­oper iden­tity. Requiring a gov­ern­ment ID does­n’t make code safer. It makes de­vel­op­ers iden­ti­fi­able and con­trol­lable. Malware au­thors can reg­is­ter. Indie de­vel­op­ers and dis­si­dents of­ten can’t. The EFF is blunt: iden­tity-based gate­keep­ing is a cen­sor­ship tool, not a se­cu­rity one.

″…still side­load­ing if you use the ad­vanced flow?”

Nine steps, 24-hour wait, buried in Developer Options, de­liv­ered through a pro­pri­etary ser­vice that Google can re­voke when­ever they want. That’s not side­load­ing. That’s a de­ter­rence mech­a­nism built to en­sure al­most no­body com­pletes it. And since it runs through Play Services rather than the OS, Google can tighten or kill it silently.

″…only a prob­lem if you have some­thing to hide?”

Whistleblowers, jour­nal­ists, and ac­tivists un­der au­thor­i­tar­ian gov­ern­ments will be the first vic­tims. People in do­mes­tic abuse sit­u­a­tions are next. All these groups have le­git­i­mate rea­sons to dis­trib­ute or use soft­ware with­out putting their le­gal iden­tity in a Google data­base. Anonymous open-source con­tri­bu­tion is a tra­di­tion older than Google it­self. This pol­icy ends it on Android.

″…the same thing Apple does?”

Apple has been a walled gar­den from day one. People chose Android be­cause it was dif­fer­ent. Apple does it too” is a race to the bot­tom and a weak tu quoque ar­gu­ment. And un­der reg­u­la­tory pres­sure (the EUs Digital Markets Act), even Apple is be­ing forced to open up. Google is mov­ing in the op­po­site di­rec­tion: at­tempt­ing to fur­ther en­trench its gate­keep­ing sta­tus.

″…just $25 and some pa­per­work?”

Maybe, if you’re a de­vel­oper in the US with a credit card and a dri­ver’s li­cense. Try be­ing a stu­dent in sub-Sa­ha­ran Africa, or a dis­si­dent in Myanmar, or a vol­un­teer main­tain­ing a com­mu­nity health app. The cost is­n’t only fi­nan­cial: you’re sur­ren­der­ing gov­ern­ment ID and ev­i­dence of your sign­ing keys to a com­pany that rou­tinely com­plies with gov­ern­ment de­mands to re­move apps and ex­pose de­vel­op­ers.

Fight back

Everyone

Install F-Droid on every Android de­vice you own. Alternative stores only sur­vive if peo­ple ac­tu­ally use them.

Contact your reg­u­la­tors. Regulators world­wide are gen­uinely con­cerned about mo­nop­o­lies and the cen­tral­iza­tion of power in the tech sec­tor, and want to hear di­rectly from in­di­vid­u­als who are af­fected and con­cerned.

Share this page. Link to keepan­droidopen.org every­where.

Push back on as­tro­turfers. The well, ac­tu­ally…” crowd is out in force. Don’t let them set the nar­ra­tive.

Sign the change.org pe­ti­tion and join the over 100,000 sig­na­to­ries who have made their voices heard.

Read and share our open let­ter

Tell Google what you think of this through their own de­vel­oper ver­i­fi­ca­tion sur­vey (for all the good that will do).

Developers

Do not sign up. Don’t join the pro­gram by sign­ing up for the Android Developer Console and agree­ing to their ir­rev­o­ca­ble Terms and Conditions. Don’t ver­ify your iden­tity. Don’t play ball.

Google’s plan only works if de­vel­op­ers com­ply. Don’t.

Talk other de­vel­op­ers and or­ga­ni­za­tions out of sign­ing up.

Add the FreeDroidWarn li­brary to your apps to warn users.

Run a web­site? Add the count­down ban­ner.

Google em­ploy­ees

If you know some­thing about the pro­gram’s tech­ni­cal im­ple­men­ta­tion or in­ter­nal ra­tio­nale, con­tact tips@keepan­droidopen.org from a non-work ma­chine and a non-Gmail ac­count. Strict con­fi­dence guar­an­teed.

All those op­posed…

69 or­ga­ni­za­tions from 21 coun­tries have signed the open let­ter

Read the full open let­ter and thank the sig­na­to­ries →

What they’re say­ing

Tech press

Google plans to block side-load­ing like Apple, de­clar­ing war on Android free­dom” Tuta Blog

Google plans to block side-load­ing like Apple, de­clar­ing war on Android free­dom”

Google’s de­vel­oper reg­is­tra­tion decree’ means the end for al­ter­na­tive app stores” Cybernews

Google’s de­vel­oper reg­is­tra­tion decree’ means the end for al­ter­na­tive app stores”

Open-Source Android Apps at Risk Under Google’s New Decree” TechRepublic

Open-Source Android Apps at Risk Under Google’s New Decree”

F-Droid Slams Google for Misleading Users About Android’s App Verification” Android Headlines

F-Droid Slams Google for Misleading Users About Android’s App Verification”

Android, Epic, and What’s Really Behind Google’s Existential’ Threat to F-Droid” Slashdot

Android, Epic, and What’s Really Behind Google’s Existential’ Threat to F-Droid”

Google is re­strict­ing one of Android’s most im­por­tant fea­tures, and users are out­raged” SlashGear

Google is re­strict­ing one of Android’s most im­por­tant fea­tures, and users are out­raged”

Resistance to Google’s Android ver­i­fi­ca­tion grows among de­vel­op­ers” Techzine EU

Resistance to Google’s Android ver­i­fi­ca­tion grows among de­vel­op­ers”

Google says it’s mak­ing Android side­load­ing high-friction’ to bet­ter warn users about po­ten­tial risks” XDA Developers

Google says it’s mak­ing Android side­load­ing high-friction’ to bet­ter warn users about po­ten­tial risks”

Google’s dev reg­is­tra­tion plan will end the F-Droid pro­ject’” The Register

Google’s dev reg­is­tra­tion plan will end the F-Droid pro­ject’”

Keep Android Open — Abwehr gegen Verbot anonymer Apps von Google” heise on­line

Keep Android Open — Abwehr gegen Verbot anonymer Apps von Google”

Google will make you wait 24 hours to side­load Android apps” How-To Geek

Google will make you wait 24 hours to side­load Android apps”

Sideloading is dead for all in­tents and pur­poses. The Android you know and love is slowly dis­ap­pear­ing.” Android Police

Sideloading is dead for all in­tents and pur­poses. The Android you know and love is slowly dis­ap­pear­ing.”

Sideloading on Android? Soon It’ll Be Like a TSA Check for Apps” Android Headlines

openai.com

The West Forgot How to Build. Now It's Forgetting Code

techtrenches.dev

In 2023, Raytheon’s pres­i­dent stood at the Paris Air Show and de­scribed what it took to restart Stinger mis­sile pro­duc­tion. They brought back en­gi­neers in their 70s to teach younger work­ers how to build a mis­sile from pa­per schemat­ics drawn dur­ing the Carter ad­min­is­tra­tion. Test equip­ment had been sit­ting in ware­houses for years. The nose cone still had to be at­tached by hand, ex­actly as it was forty years ago.

The Pentagon had­n’t bought a new Stinger in twenty years. Then Russia in­vaded Ukraine, and sud­denly every­one needed them. The pro­duc­tion line was shut down. The elec­tron­ics were ob­so­lete. The seeker com­po­nent was out of pro­duc­tion. An or­der placed in May 2022 would­n’t de­liver un­til 2026. Four years. Not be­cause of money. Because the peo­ple who knew how to build them re­tired a decade ear­lier and no­body re­placed them.

I run en­gi­neer­ing teams in Ukraine. My peo­ple lived the other side of this equa­tion. Not the fac­tory floor. The re­ceiv­ing end. While Raytheon was strug­gling to restart pro­duc­tion from forty-year-old blue­prints, the US was ship­ping thou­sands of Stingers to Ukraine. RTX CEO Greg Hayes: ten months of war burned through thir­teen years’ worth of Stinger pro­duc­tion. I’ve seen this pat­tern be­fore. It’s hap­pen­ing in my in­dus­try right now.

In March 2023, the EU promised Ukraine one mil­lion ar­tillery shells within twelve months. European pro­duc­tion ca­pac­ity sat at 230,000 shells per year. Ukraine was con­sum­ing 5,000 to 7,000 rounds per day. Anyone with a cal­cu­la­tor could see this would­n’t work.

By the dead­line, Europe de­liv­ered about half. Macron called the orig­i­nal promise reck­less. An in­ves­ti­ga­tion by eleven me­dia out­lets across nine coun­tries found ac­tual pro­duc­tion ca­pac­ity was roughly one-third of of­fi­cial EU claims. The mil­lion-shell mark was­n’t hit un­til December 2024, nine months late.

It was­n’t one bot­tle­neck. It was all of them. France had halted do­mes­tic pro­pel­lant pro­duc­tion in 2007. Seventeen years of noth­ing. Europe’s sin­gle ma­jor TNT pro­ducer was in Poland. Germany had two days of am­mu­ni­tion stored. A Nammo plant in Denmark was shut down in 2020 and had to be restarted from scratch. The en­tire con­ti­nen­t’s de­fense in­dus­try had been op­ti­mized for mak­ing small batches of ex­pen­sive cus­tom prod­ucts. Nobody planned for vol­ume. Nobody planned for cri­sis.

The U.S. was­n’t much bet­ter. One plant in Scranton, one fa­cil­ity in Iowa for ex­plo­sive fill, no do­mes­tic TNT pro­duc­tion since 1986. Billions of in­vest­ment later, pro­duc­tion still had­n’t hit half the tar­get.

This was­n’t an ac­ci­dent. In 1993, the Pentagon told de­fense CEOs to con­sol­i­date or die. Fifty-one ma­jor de­fense con­trac­tors col­lapsed into five. Tactical mis­sile sup­pli­ers went from thir­teen to three. Shipbuilders from eight to two. The work­force fell from 3.2 mil­lion to 1.1 mil­lion. A 65% cut.

The am­mu­ni­tion sup­ply chain had sin­gle points of fail­ure every­where. One man­u­fac­turer for 155mm shell cas­ings, sit­ting in Coachella, California, on the San Andreas Fault. One fa­cil­ity in Canada for pro­pel­lant charges. Optimized for min­i­mum cost with zero mar­gin for surge. On pa­per, ef­fi­cient. In prac­tice, one bad day away from col­lapse.

Then there’s Fogbank. A clas­si­fied ma­te­r­ial used in nu­clear war­heads. Produced from 1975 to 1989, then the fa­cil­ity was shut down. When the gov­ern­ment needed to re­pro­duce it for a war­head life ex­ten­sion pro­gram, they dis­cov­ered they could­n’t. A GAO re­port found that al­most all staff with pro­duc­tion ex­per­tise had re­tired, died, or left the agency. Few records ex­isted.

After $69 mil­lion in cost over­runs and years of failed at­tempts, they fi­nally pro­duced vi­able Fogbank. Then dis­cov­ered the new batch was too pure. The orig­i­nal process had re­lied on an un­in­ten­tional im­pu­rity that was crit­i­cal to the ma­te­ri­al’s func­tion. Nobody knew. Not the en­gi­neers try­ing to re­pro­duce it. Not even the orig­i­nal work­ers who made it decades ear­lier. Los Alamos called it an un­know­ing de­pen­dency in the orig­i­nal process.

A nu­clear weapons pro­gram lost the abil­ity to make a ma­te­r­ial it in­vented. The knowl­edge did­n’t just leave with peo­ple. It was never fully un­der­stood by any­one.

(Correction: the orig­i­nal ver­sion stated that the work­ers who made Fogbank knew about the im­pu­rity. They did­n’t. The de­pen­dency was un­wit­ting, which makes the knowl­edge-loss ar­gu­ment stronger, not weaker. Thanks to John F. in the com­ments for catch­ing this.)

I read the Fogbank story and rec­og­nized it im­me­di­ately. Not the nu­clear ma­te­r­ial. The pat­tern. Build ca­pa­bil­ity over decades. Find a cheaper sub­sti­tute. Let the hu­man pipeline at­ro­phy. Enjoy the sav­ings. Then watch it all col­lapse when a cri­sis de­mands what you op­ti­mized away.

In de­fense, the sub­sti­tute was the peace div­i­dend. In soft­ware, it’s AI.

I wrote about the tal­ent pipeline col­lapse be­fore. The hir­ing num­bers and the ju­nior-to-se­nior prob­lem are doc­u­mented. So is the com­pre­hen­sion cri­sis. What I did­n’t have was the right his­tor­i­cal par­al­lel. Now I do.

And it tells you some­thing the hir­ing data does­n’t: how long re­build­ing ac­tu­ally takes.

Every ma­jor de­fense pro­duc­tion ramp-up took three to five years for sim­ple sys­tems. Five to ten for com­plex ones. Stinger: thirty months min­i­mum from or­der to de­liv­ery. Javelin: four and a half years to less than dou­ble pro­duc­tion. 155mm shells: four years and still not at tar­get de­spite five bil­lion dol­lars in­vested. France only restarted pro­pel­lant pro­duc­tion in 2024, sev­en­teen years af­ter shut­ting it down.

Money was never the con­straint. Knowledge was. RAND found that 10% of tech­ni­cal skills for sub­ma­rine de­sign need ten years of on-the-job ex­pe­ri­ence to de­velop, some­times fol­low­ing a PhD. Apprenticeships in de­fense trades take two to four years, with five to eight years to reach su­per­vi­sory com­pe­tence.

Now map that onto soft­ware. A ju­nior de­vel­oper needs three to five years to be­come a com­pe­tent mid-level en­gi­neer. Five to eight years to be­come se­nior. Ten or more to be­come a prin­ci­pal or ar­chi­tect. That time­line can’t be com­pressed by throw­ing money at it. It can’t be com­pressed by AI ei­ther.

A METR ran­dom­ized con­trolled trial found that ex­pe­ri­enced de­vel­op­ers us­ing AI cod­ing tools ac­tu­ally took 19% longer on real-world open source tasks. Before start­ing, they pre­dicted AI would make them 24% faster. The gap be­tween pre­dic­tion and re­al­ity was 43 per­cent­age points. When re­searchers tried to run a fol­low-up, a sig­nif­i­cant share of de­vel­op­ers re­fused to par­tic­i­pate if it meant work­ing with­out AI. They could­n’t imag­ine go­ing back.

The soft­ware in­dus­try is in year three of the same op­ti­miza­tion. Salesforce said it won’t hire more soft­ware en­gi­neers in 2025. A LeadDev sur­vey found 54% of en­gi­neer­ing lead­ers be­lieve AI copi­lots will re­duce ju­nior hir­ing long-term. A CRA sur­vey of uni­ver­sity com­put­ing de­part­ments found 62% re­ported de­clin­ing en­roll­ment this year.

I see it in code re­view. Review is now the bot­tle­neck. AI gen­er­ates code fast. Humans re­view it slow. The in­dus­try’s an­swer is pre­dictable: let AI re­view AIs code. I’m not do­ing that. I’ve re­worked our pull re­quest tem­plates in­stead. Every PR now has to ex­plain what changed, why, what type of change it is, screen­shots of be­fore and af­ter. Structured con­text so the re­viewer is­n’t guess­ing. I’m adding ded­i­cated re­view­ers per pro­ject. More eyes, more chances to catch what the model missed.

But even that does­n’t solve the deeper prob­lem. The skills you need to be ef­fec­tive now are dif­fer­ent. Technical ex­per­tise alone is­n’t enough any­more. You need peo­ple who can take own­er­ship, com­mu­ni­cate trade­offs, push back on bad sug­ges­tions from a ma­chine that sounds very con­fi­dent. Leadership qual­i­ties. Our last hir­ing round tells you how rare that is: 2,253 can­di­dates, 2,069 dis­qual­i­fied, 4 hired. A 0.18% con­ver­sion rate. The com­bi­na­tion of tech­ni­cal skill and the judg­ment to know when the AI is wrong barely ex­ists in the mar­ket any­more.

We doc­u­ment every­thing. Site Books, SDDs, RVS re­ports, boil­er­plate mod­ules with full cov­er­age. It works to­day, be­cause the peo­ple read­ing those docs have the en­gi­neer­ing ex­per­tise to act on them. What hap­pens when they don’t? Honestly, I don’t know. Maybe AI in five years is good enough that it won’t mat­ter. Maybe the prob­lem stays man­age­able. I can’t pre­dict the ca­pa­bil­i­ties of mod­els in 2031.

But crises don’t send cal­en­dar in­vites. Nobody ex­pected a full-scale land war in Europe in 2022. The de­fense in­dus­try had thirty years to pre­pare and did­n’t. Even Fogbank had records. There weren’t enough. The orig­i­nal work­ers did­n’t fully un­der­stand their own process.

Five to ten years from now, we’ll need se­nior en­gi­neers. People who un­der­stand sys­tems end to end, who can de­bug dis­trib­uted fail­ures at 2 AM, who carry in­sti­tu­tional knowl­edge that ex­ists nowhere in the code­base. Those en­gi­neers don’t ex­ist yet be­cause we’re not cre­at­ing them. The ju­niors who should be learn­ing right now are ei­ther not be­ing hired or de­vel­op­ing what a DoD-funded work­force study calls AI-mediated com­pe­tence.” They can prompt an AI. They can’t tell you what the AI got wrong.

It’s Fogbank for code. When ju­niors skip de­bug­ging and skip the for­ma­tive mis­takes, they don’t build the tacit ex­per­tise. And when my gen­er­a­tion of en­gi­neers re­tires, that knowl­edge does­n’t trans­fer to the AI.

It just dis­ap­pears.

The West al­ready made this mis­take once. The bill came due in Ukraine.

I know how this sounds. I know I’ve writ­ten about the tal­ent pipeline be­fore. The de­fense ex­am­ple is­n’t about re­peat­ing the ar­gu­ment. It’s about show­ing what hap­pens if the in­dus­try’s ex­pec­ta­tions don’t work out. Stinger, Javelin, Fogbank, a mil­lion shells no­body could make. That’s the cost of bet­ting wrong on op­ti­miza­tion. We’re mak­ing the same bet with soft­ware en­gi­neer­ing right now.

Maybe AI gets good enough, and the bet pays off. Maybe it does­n’t. The de­fense in­dus­try thought peace would last for­ever, too.

No posts

Just a moment...

ca98am79.medium.com

crawshaw - 2026-04-22

crawshaw.io

I am build­ing a cloud

2026 – 04-22

Today is fundrais­ing an­nounce­ment day. As is the na­ture of writ­ing for a larger au­di­ence, it is a for­mal, safe an­nounce­ment. As it should be. Writing must nec­es­sar­ily be­come im­per­sonal at scale. But I would like to write some­thing per­sonal about why I am do­ing this. What is the goal of build­ing exe.dev? I am al­ready the co-founder of one startup that is do­ing very well, sell­ing a prod­uct I love as much as when I first helped de­sign and build it.

What could pos­sess me to go through all the pain of start­ing an­other com­pany? Some fel­low founders have looked at me with in­credulity and shock that I would throw my­self back into the fry­ing pan. (Worse yet, ex­pe­ri­ence tells me that most of the pain is still in my fu­ture.) It has been a gen­uinely hard ques­tion to an­swer be­cause I start search­ing for a big” rea­son, a prin­ci­ple or a so­cial need, a rea­son or mo­ti­va­tion be­yond chal­lenge. But I be­lieve the truth is far sim­pler, and to some I am sure al­most equally in­cred­u­lous.

I like com­put­ers.

In some tech cir­cles, that is an un­usual state­ment. (“In this house, we curse com­put­ers!”) I get it, com­put­ers can be re­ally frus­trat­ing. But I like com­put­ers. I al­ways have. It is re­ally fun get­ting com­put­ers to do things. Painful, sure, but the re­sults are worth it. Small mi­cro­con­trollers are fun, desk­tops are fun, phones are fun, and servers are fun, whether racked in your base­ment or in a data cen­ter across the world. I like them all.

So it is no small thing for me when I ad­mit: I do not like the cloud to­day.

I want to. Computers are great, whether it is a BSD in­stalled di­rectly on a PC or a Linux VM. I can en­joy Windows, BeOS, Novell NetWare, I even in­stalled OS/2 Warp back in the day and had a great time with it. Linux is par­tic­u­larly pow­er­ful to­day and a source of end­less po­ten­tial. And for all the pages of prod­ucts, the cloud is just Linux VMs. Better, they are API dri­ven Linux VMs. I should be in heaven.

But every cloud prod­uct I try is wrong. Some are bet­ter than oth­ers, but I am con­stantly con­strained by the choices cloud ven­dors make in ways that make it hard to get com­put­ers to do the things I want them to do.

These is­sues go be­yond UX or bad API de­sign. Some of the fun­da­men­tal build­ing blocks of to­day’s clouds are the wrong shape. VMs are the wrong shape be­cause they are tied to CPU/memory re­sources. I want to buy some CPUs, mem­ory, and disk, and then run VMs on it. A Linux VM is a process run­ning in an­other Linux’s cgroup, I should be able to run as many as I like on the com­puter I have. The only way to do that eas­ily on to­day’s clouds is to take iso­la­tion into my own hands, with gVi­sor or nested vir­tu­al­iza­tion on a sin­gle cloud VM, pay­ing the nest­ing per­for­mance penalty, and then I am left with the job of run­ning and man­ag­ing, at a min­i­mum, a re­verse proxy onto my VMs. All be­cause the cloud ab­strac­tion is the wrong shape.

Clouds have tried to solve this with PaaS” sys­tems. Abstractions that are in­her­ently less pow­er­ful than a com­puter, be­spoke to a par­tic­u­lar provider. Learn a new way to write soft­ware for each com­pute ven­dor, only to find half way into your pro­ject that some­thing that is easy on a nor­mal com­puter is nearly im­pos­si­ble be­cause of some ob­scure limit of the plat­form sys­tem buried so deep you can­not find it un­til you are deeply com­mit­ted to a pro­ject. Time and again I have said this is the one” only to be be­trayed by some half-assed, half-im­ple­mented, or half-thought-through ab­strac­tion. No thank you.

Consider disk. Cloud providers want you to use re­mote block de­vices (or some­thing even more lim­ited and slow, like S3). When re­mote block de­vices were in­tro­duced they made sense, be­cause com­put­ers used hard dri­ves. Remote does not hurt se­quen­tial read/​write per­for­mance, if the buffer­ing im­ple­men­ta­tion is good. Random seeks on a hard drive take 10ms, so 1ms RTT for the Ethernet con­nec­tion to re­mote stor­age is a fine price to pay. It is a good prod­uct for hard dri­ves and makes the cloud ven­dor’s life a lot eas­ier be­cause it re­moves an en­tire di­men­sion from their stan­dard in­stance types.

But then we all switched to SSD. Seek time went from 10 mil­lisec­onds to 20 mi­crosec­onds. Heroic ef­forts have cut the net­work RTT a bit for re­ally good re­mote block sys­tems, but the IOPS over­head of re­mote sys­tems went from 10% with hard dri­ves to more than 10x with SSDs.

It is a lot of work to con­fig­ure an EC2 VM to have 200k IOPS, and you will pay $10k/month for the priv­i­lege. My MacBook has 500k IOPS. Why are we hob­bling our cloud in­fra­struc­ture with slow disk?

Finally net­work­ing. Hyperscalers have great net­works. They charge you the earth for them and make it mis­er­able to do deals with other ven­dors. The stan­dard price for a GB of egress from a cloud provider is 10x what you pay rack­ing a server in a nor­mal data cen­ter. At mod­er­ate vol­ume the mul­ti­plier is even worse. Sure, if you spend $XXm/month with a cloud the prices get much bet­ter, but most of my pro­jects want to spend $XX/month, with­out the lit­tle m. The fun­da­men­tal tech­nol­ogy here is fine, but this is where lim­its are placed on you to make sure what­ever you build can­not be af­ford­able.

Finally, clouds have painful APIs. This is where pro­jects like K8S come in, pa­per­ing over the pain so en­gi­neers suf­fer a bit less from us­ing the cloud. But VMs are hard with Kubernetes be­cause the cloud makes you do it all your­self with lumpy nested vir­tu­al­iza­tion. Disk is hard be­cause back when they were de­sign­ing K8S Google did­n’t re­ally even do us­able re­mote block de­vices, and even if you can find a com­mon pat­tern among clouds to­day to pa­per over, it will be slow. Networking is hard be­cause if it were easy you would pri­vate link in a few sys­tems from a neigh­bor­ing open DC and drop a zero from your cloud spend. It is tempt­ing to dis­miss Kubernetes as a scam, ar­ti­fi­cial make work de­signed to avoid do­ing real prod­uct work, but the truth is worse: it is a prod­uct at­tempt­ing to solve an im­pos­si­ble prob­lem: make clouds portable and us­able. It can­not be done.

You can­not solve the fun­da­men­tal prob­lems with cloud ab­strac­tions by build­ing new ab­strac­tions on top. Making Kubernetes good is in­her­ently im­pos­si­ble, a pro­ject in putting (admittedly high qual­ity) lip­stick on a pig.

We have been mud­dy­ing along with these mis­er­able clouds for 15 years now. We make do, in the way we do with all the un­pleas­ant parts of our soft­ware stack, hold­ing our nose when­ever we have to deal with and try­ing to min­i­mize how of­ten that hap­pens.

This how­ever, is the mo­ment to fix it.

This is the mo­ment be­cause some­thing has changed: we have agents now. (Indeed my co-founder Josh and I started tin­ker­ing be­cause we wanted to use LLMs in pro­gram­ming. It turns out what needs build­ing for LLMs are bet­ter tra­di­tional ab­strac­tions.) Agents, by mak­ing it eas­i­est to write code, means there will be a lot more soft­ware. Economists would call this an in­stance of Jevons para­dox. Each of us will write more pro­grams, for fun and for work. We need pri­vate places to run them, easy shar­ing with friends and col­leagues, min­i­mal over­head.

With more to­tal soft­ware in our lives the cloud, which was an an­noy­ing pain, be­comes a much big­ger pain. We need a lot more com­pute, we need it to be eas­ier to man­age. Agents help to some de­gree. If you trust them with your cre­den­tials they will do a great job dri­ving the AWS API for you (though oc­ca­sion­ally it will delete your pro­duc­tion DB). But agents strug­gle with the fun­da­men­tal lim­its of the ab­strac­tions as much as we do. You need more to­kens than you should and you get a worse re­sult than you should. Every per­cent of con­text win­dow the agent spends think­ing about how to con­tort clas­sic clouds into work­ing is con­text win­dow is not us­ing to solve your prob­lem.

So we are go­ing to fix it. What we have launched on exe.dev to­day ad­dresses the VM re­source iso­la­tion prob­lem: in­stead of pro­vi­sion­ing in­di­vid­ual VMs, you get CPU and mem­ory and run the VMs you want. We took care of a TLS proxy and an au­then­ti­ca­tion proxy, be­cause I do not ac­tu­ally want my fresh VMs dumped di­rectly on the in­ter­net. Your disk is lo­cal NVMe with blocks repli­cated off ma­chine asyn­chro­nously. We have re­gions around the world for your ma­chines, be­cause you want your ma­chines close. Your ma­chines are be­hind an any­cast net­work to give all your global users a low la­tency en­try­point to your prod­uct (and so we can build some new ex­cit­ing things soon).

There is a lot more to build here, from ob­vi­ous things like sta­tic IPs to UX chal­lenges like how to give you ac­cess to our au­to­matic his­tor­i­cal disk snap­shots. Those will get built. And at the same time we are go­ing right back to the be­gin­ning, rack­ing com­put­ers in data cen­ters, think­ing through every layer of the soft­ware stack, ex­plor­ing all the op­tions for how we wire up net­works.

So, I am build­ing a cloud. One I ac­tu­ally want to use. I hope it is use­ful to you.

Are you a robot?

www.bloomberg.com

Please make sure your browser sup­ports JavaScript and cook­ies and that you are not block­ing them from load­ing. For more in­for­ma­tion you can re­view our Terms of Service and Cookie Policy.

Why I Cancelled Claude: Token Issues, Declining Quality, and Poor Support

nickyreinert.de

Prefix Note

As this post is gain­ing more at­ten­tion than ex­pected on HN, I want to make some things clear - al­though I thought they are ob­vi­ous.

It sounds like a rant about Claude’s qual­ity in gen­eral - if you don’t read to the end. But my con­cerns are more fo­cused on the sup­port per­for­mance and to­ken is­sues - fully aware of the chal­lenges a com­pany this size faces and as­sum­ing the peo­ple at Anthropic are work­ing hard to make things bet­ter. I am point­ing at some bad de­sign de­ci­sions” they prob­a­bly made. The quality is­sues” are just the cherry on top of the cake.

After all, Claude Code is de­liv­er­ing and I use it to build stuff. Still, I ex­pe­ri­enced a degra­da­tion in qual­ity. It just takes longer. Which is a rel­a­tive ob­ser­va­tion. However I know that this is highly sub­jec­tive, too. That’s what that com­ment in a para­graph means: The fail­ure usu­ally ap­pears in front of the screen”. Of course the agent is only as good as the op­er­a­tor and their in­struc­tions.

I am cod­ing for a cou­ple of decades now, I like to get my hands dirty. Three years ago I im­ple­mented AI into my work­flow. It started with code com­ple­tion and now I am at the point where I barely write code. For me software en­gi­neeer­ing” is not con­sti­tuted by the sim­ple act of writ­ing code. It’s about con­duct­ing tools, be­ing cre­ative, un­der­stand­ing the prob­lem and de­liv­er­ing a so­lu­tion. Still - and that what this com­ment in an­other para­graph means: While I was brows­ing the mod­el’s think­ing log - which I strongly sug­gest do­ing not only oc­ca­sion­ally” - I am es­cort­ing the agent while it’s work­ing. I still have to fig­ure out a con­cept, think about a data model and ver­ify it’s im­ple­men­ta­tion. That’s what soft­ware en­gi­neer­ing is about. It’s not n LOC…

Having said that - en­joy this post and stay happy, fel­low de­vel­op­ers.

First en­thu­si­asm

A cou­ple of weeks ago I sub­scribed to Claude Code, and dur­ing the first few weeks I had a re­ally nice ex­pe­ri­ence. It was fast, the to­ken al­lowance was fair, and the qual­ity was good.

I learned they had

raised the to­ken al­lowance for non-rush hours

, and since they op­posed some gov­ern­men­tal rules, it felt good to sup­port the right cause.

(づ  ̄ ³ ̄)づ

However… for about three weeks now my ini­tial en­thu­si­asm has been rapidly wan­ing.

It be­gan with an is­sue three weeks ago. I started work­ing in the morn­ing af­ter about a ten-hour break; enough time for my to­kens to re­fresh.

I sent two small ques­tions to Claude Haiku. They were sim­ple ques­tions, not even re­lated to the repos­i­tory.

Suddenly, to­ken us­age spiked to 100%.

Have a nice break…

I con­tacted their AI sup­port bot”, which re­turned some de­fault sup­port non­sense and did­n’t re­ally un­der­stand the prob­lem. So I asked for hu­man sup­port. A cou­ple of days later a - what ap­peared to be - hu­man sup­port per­son sent a re­ply. It be­gan like this:

Our sys­tems are de­tect­ing your in­quiry is re­gard­ing us­age lim­its on your Pro or Max plan.”

Yeah, well — it’s the Pro plan. Seems like your sys­tems weren’t ac­tu­ally queried; it was just a de­fault in­tro and prob­a­bly a de­fault an­swer, be­cause:

This was fol­lowed by an ex­ten­sive what seems to be copy-and-paste an­swer from their docs ex­plain­ing how daily and weekly lim­its work.

And it closed with the typ­i­cally frus­trat­ing line, that no cus­tomer likes to read at the end of an e-mail and which is just the clas­si­cal mid­dle-fin­ger of cus­tomer sup­port - we don’t care if your prob­lem is solved or not, we de­clared it closed.

Note that fur­ther replies to this ticket may not be mon­i­tored. If your re­quest is not re­gard­ing us­age lim­its on your Pro or Max plan, or you need ad­di­tional sup­port, please visit our help page at”

Great! Sending an au­to­mated e-mail that does not re­fer to the ac­tual prob­lem and then clos­ing the chan­nel. Thanks for noth­ing, I guess? Or was I wrong. I asked Claude Haiku:

@Haiku:

See the cus­tomer’s re­quest here and the re­sponse from the AI and later W***** - did they an­swer the con­cern/​ques­tion of the cus­tomer?

See the cus­tomer’s re­quest here and the re­sponse from the AI and later W***** - did they an­swer the con­cern/​ques­tion of the cus­tomer?

(╯°_°)╯︵ ┻━┻

Declining qual­ity

In the fol­low­ing days and weeks, the qual­ity was far from sat­is­fy­ing my needs or match­ing my ini­tial ex­pe­ri­ence. While I used to be able to work on up to three pro­jects at once, now the to­ken limit was ex­hausted af­ter two hours on a sin­gle pro­ject.

And the qual­ity was de­grad­ing. I am fully aware this is quite sub­jec­tive and that the qual­ity of the agent is al­ways heav­ily im­pacted by the op­er­a­tor. The fail­ure usu­ally ap­pears in front of the screen. But hey, I also de­velop us­ing Github’s Copilot, OpenAI’s Codex and I am run­ning my own in­fer­ence with OMLX and Continue us­ing Qwen3.5 – 9B. I’m not the ex­pert, I’m lazy some­times but I prob­a­bly know a thing or two.

Let me give you this won­der­ful ex­am­ple: yes­ter­day I asked Claude Opus to refac­tor a pro­ject.

While I was brows­ing the mod­el’s think­ing log - which I strongly sug­gest do­ing not only oc­ca­sion­ally - I found this:

Rather than edit­ing every slider in JSX, I’ll add a generic ini­tial­izer in ui-events.js that auto-in­jects value dis­plays for all range in­puts that lack one.

Rather than edit­ing every slider in JSX, I’ll add a generic ini­tial­izer in ui-events.js that auto-in­jects value dis­plays for all range in­puts that lack one.

This is clearly bad prac­tice. It’s a cheap workaround you would­n’t ex­pect even from a ju­nior dev; it reads like some­one who just does­n’t want to de­liver a good re­sult. My re­sponse:

you can’t be se­ri­ous — is this how you fix things? just WORKAROUNDS????”

At least Opus ad­mit­ted:

You’re right, that was lazy. Let me do it prop­erly — add the la­bels di­rectly in the JSX and wire them ex­plic­itly.”

Needless to say, this short­cut cost me around 50% of my five-hour to­ken al­lowance.

(ง •̀_•́)ง

And even more…

Now this cache topic comes up

-

among oth­ers

. at least they are talk­ing about it openly. The prob­lem was: when you get back to work af­ter some time, your con­ver­sa­tion cache is gone and the model starts read­ing your code­base again. Cost-wise this is smart. But ex­pe­ri­ence-wise? It means you paid to­kens for the ini­tial load and, af­ter a forced break be­cause the five-hour to­ken win­dow hit its limit, you pay again for the same load.

Think that’s all? Wait, I also got this funny anec­dote: all of a sud­den the weekly win­dow changed from to­day to Monday. OK, I was thank­ful be­cause it came with a re­set to zero. But still: what is go­ing on, Anthropic? Not only that — while I was work­ing on my pro­ject, watch­ing to­ken us­age with Argus-eyed vig­i­lance, this lit­tle warn­ing popped up:

Wait, what? I’m nei­ther part of an or­ga­ni­za­tion nor do I see any hint why I sud­denly have to worry about a monthly us­age limit” — also the hourly and weekly lim­its were still not ex­ceeded. What is hap­pen­ing right now?

Turns out — two hours later - it al­lowed me to con­tinue work­ing. The warn­ing was gone.

At least

this doc­u­men­ta­tion

does not men­tion a monthly us­age limit. And the set­tings page only lists the lim­its for the cur­rent ses­sion and week.

So… what is this monthly limit all about, Anthropic?

Sorry to let you down, Anthropic

I am a huge fan of the prod­uct. Theoretically every­thing just works like a charm; it of­fers so many op­por­tu­ni­ties. I built my

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

If you like 10HN please leave feedback and share

Visit pancik.com for more.