TheDaily Front

In 2025, homes paid 17.8¢ a kilowatt-hour at investor-owned utilities, 14.5¢ at public utilities and 14.1¢ at co-ops. Since 2020, investor-owned prices rose 34% and public ones 19%, against 24% inflation.

Average home price by utility owner

Change since 2020 against inflation, or cents per kilowatt-hour since 2015.

Year	Investor-owned	Public	Co-op	Inflation since 2020	Investor-owned, monthly bill	Public, monthly bill	Co-op, monthly bill
2025	17.8¢ +34%	14.5¢ +19%	14.1¢ +19%	+24%	$146	$130	$159
2024	16.9¢ +28%	13.9¢ +14%	13.5¢ +14%	+21%	$137	$125	$149
2023	16.6¢ +25%	13.4¢ +10%	13.2¢ +12%	+18%	$133	$120	$145
2022	15.4¢ +17%	13.3¢ +9.4%	13.1¢ +11%	+13%	$130	$124	$150
2021	13.9¢ +5.1%	12.4¢ +1.8%	12.1¢ +2.2%	+4.7%	$116	$113	$136
2020	13.3¢	12.2¢	11.8¢	–	$111	$112	$133
2019	13.1¢	12.0¢	11.9¢	–	$109	$109	$136
2018	13.1¢	12.0¢	11.8¢	–	$111	$112	$139
2017	13.3¢	11.8¢	11.9¢	–	$106	$106	$130
2016	12.9¢	11.6¢	11.6¢	–	$107	$106	$131
2015	12.9¢	11.6¢	11.6¢	–	$108	$107	$133

Every year since 2015: home revenue, kWh sold, homes, price and bill by utility owner, for the US and each state, as a gzipped CSV.

Download CSV (gzip)

Source: EIA annual survey of utilities (Form 861), homes buying supply and delivery from their utility; BLS CPI.

Home prices in 2025

Share of homes by their utility's average price per kilowatt-hour, in 2-cent bands.

Investor-owned 67% of homes paid 12 to 20 cents, and 11% paid 30 cents or more.

Public 61% paid under 14 cents. The bump at the high end is LADWP and Long Island Power Authority, 13% of public homes.

Co-op 52% paid under 14 cents.

Price a kWh	Investor-owned	Public	Co-op
Under 10¢	0.1%	3.9%	1.2%
10 to 12¢	3.8%	13.2%	10.4%
12 to 14¢	13.9%	43.8%	40.0%
14 to 16¢	20.3%	12.7%	30.8%
16 to 18¢	20.0%	3.2%	11.7%
18 to 20¢	12.4%	6.5%	2.4%
20 to 22¢	9.1%	1.5%	1.0%
22 to 24¢	2.7%	0.9%	0.8%
24 to 26¢	3.4%	0.6%	0.9%
26 to 28¢	1.3%	13.3%	0.0%
28 to 30¢	1.6%	0.0%	0.0%
30¢ or more	11.4%	0.5%	0.6%

Source: EIA annual survey of utilities (Form 861), homes buying supply and delivery from their utility.

Price change by state, 2020 to 2025

States sorted by how far investor-owned prices pulled ahead of nonprofit (public and co-op) prices. The gap is widest at the top.

State	Investor-owned	Nonprofit	Investor-owned, 2025	Nonprofit, 2025
Alabama	+33%	+22%	17.9¢	13.9¢
Alaska	+20%	+15%	17.8¢	26.5¢
Arizona	+29%	+21%	16.6¢	14.0¢
Arkansas	+22%	+26%	13.1¢	12.6¢
California	+62%	+28%	33.9¢	22.7¢
Colorado	+37%	+18%	16.1¢	15.3¢
Connecticut	+34%	+23%	30.0¢	19.5¢
Delaware	+48%	+17%	18.2¢	14.7¢
Florida	+40%	+21%	15.7¢	13.8¢
Georgia	+31%	+15%	16.3¢	13.3¢
Hawaii	+37%	+14%	41.7¢	38.4¢
Idaho	+19%	+20%	12.0¢	11.3¢
Illinois	+39%	+15%	17.3¢	15.5¢
Indiana	+30%	+13%	16.6¢	14.5¢
Iowa	+7.3%	+13%	13.6¢	13.3¢

Source: EIA annual survey of utilities (Form 861), homes buying supply and delivery from their utility.

Price gap after accounting for location

Average home price per kilowatt-hour in 2025. Hydro states get the most power from dams: WA, VT, ID, OR, MT, AK and SD.

	Investor-owned	Compared with	Gap
Public, all states	17.8¢	14.5¢	+22.7%
Public, no hydro states	17.9¢	14.9¢	+19.8%
Public and co-ops, same state	18.5¢	15.7¢	+17.3%
Co-ops, most rural	17.8¢	14.1¢	+26.2%

Source: EIA annual survey of utilities (Form 861), homes buying supply and delivery from their utility.

Largest utilities, 2020 to 2025

Change in the average home price at utilities with 250,000 or more homes: investor-owned, public and co-op.

Utility	State	Owner	2020	2025	Change
New York State Electric & Gas	NY	Investor-owned	11.5¢	22.6¢	+97%
San Diego Gas & Electric (SDG&E)	CA	Investor-owned	25.5¢	45.8¢	+79%
Potomac Electric Power	DC	Investor-owned	11.8¢	20.8¢	+76%
Rochester Gas & Electric	NY	Investor-owned	12.6¢	22.0¢	+75%
Southern California Edison (SCE)	CA	Investor-owned	18.2¢	31.5¢	+73%
Tampa Electric	FL	Investor-owned	10.1¢	17.3¢	+72%
Ameren Illinois	IL	Investor-owned	9.7¢	16.7¢	+72%
Central Maine Power	ME	Investor-owned	16.2¢	27.4¢	+69%
Baltimore Gas & Electric	MD	Investor-owned	12.1¢	20.2¢	+67%
Pacific Gas and Electric (PG&E)	CA	Investor-owned	23.6¢	37.5¢	+59%
Appalachian Power (AEP)	VA	Investor-owned	10.8¢	17.2¢	+59%
Puget Sound Energy	WA	Investor-owned	10.8¢	17.0¢	+57%
National Grid (Niagara Mohawk)	NY	Investor-owned	12.6¢	19.9¢	+57%
Duke Energy Ohio	OH	Investor-owned	11.0¢	16.8¢	+52%
Portland General Electric	OR	Investor-owned	12.5¢	18.8¢	+50%

Source: EIA annual survey of utilities (Form 861), homes buying supply and delivery from their utility; BLS CPI.

Outage minutes a year by utility owner

Minutes without power for the average home, not counting major storms.

Year	Investor-owned	Public	Co-op
2025	120 min	80 min	166 min
2024	123 min	84 min	188 min
2023	116 min	85 min	167 min
2022	127 min	83 min	161 min
2021	121 min	80 min	164 min
2020	121 min	76 min	150 min
2019	120 min	73 min	153 min
2018	119 min	71 min	152 min
2017	114 min	78 min	150 min
2016	119 min	69 min	149 min
2015	114 min	68 min	152 min

Source: EIA annual survey of utilities (Form 861), reliability.

About the data

• Public power is common in cities and near federal dams, where power is cheap, and public utilities pay no income tax and borrow tax-free. That explains some of the gap, not why it grew.
• Most of the gap opened from 2020 to 2023, during the energy price spike: 25% at investor-owned utilities, 11% at public utilities and co-ops. Before and since, both rose at about the same pace.
• After inflation, investor-owned prices rose 7.9%. Public and co-op prices fell 4.3%.
• Co-op homes have the highest bills, $159 a month in 2025, because they use the most power.
• Homes that buy power from a retail supplier aren't in the investor-owned figures. Counting them, prices on investor-owned lines rose 36%.
• Price is what homes paid divided by the kilowatt-hours they used, from EIA's yearly survey of utilities. Federal utilities and the smallest ones are left out.
• The data shows what homes paid, not why. Investor-owned utilities earn a return for shareholders on what they build. Public utilities and co-ops have no shareholders. See the rate cases for increases utilities are asking for now.

70 days until lockdown

Starting in 2027*, a silent update, nonconsensually pushed by Google, will block every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID.

Every app and every device, worldwide, with no opt-out.

What Google is doing

In August 2025, Google announced a new requirement: starting in 2027, every Android app developer must register centrally with Google before their software can be installed on any device. Not just Play Store apps: all apps. This includes apps shared between friends, distributed through F-Droid, built by hobbyists for personal use. Independent developers, church and community groups, and hobbyists alike will all be frozen out of being able to develop and distribute their software.

Registration requires:

• Paying a fee to Google
• Agreeing to Google's Terms and Conditions
• Surrendering your government-issued identification
• Providing evidence of your private signing key
• Listing all current and all future application identifiers

If a developer does not comply, their apps get silently blocked on every Android device worldwide.

Who this hurts

You

You bought an Android phone because Google told you it was open. You could install what you wanted, and that was the deal.

Google is now rewriting that deal, retroactively, on hardware you already own. After the update lands, you can only run software that Google has pre-approved. On your phone: your property, that you paid for.

Independent developers

A teenager's first app, a volunteer's privacy tool, or a company's confidential internal beta. It doesn't matter. In 2027, none of these can be installed without Google's blessing.

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

Governments & civil society

Google has a documented track record of complying when authoritarian regimes demand app removals. With this program, the software that runs your country's institutions will exist at the pleasure of a single unaccountable foreign corporation.

The EFF calls app gatekeeping "an ever-expanding pathway to internet censorship."

Google's "escape hatch" is a trap door

Google says "power users" can "still install" unverified apps. Here's what that actually looks like:

1. Delve into System Settings, find About Phone
2. Tap the build number seven times to enable Developer Mode
3. Dismiss scare screens about coercion
4. Enter your PIN
5. Restart the device
6. Wait 24 hours
7. Come back, dismiss more scare screens
8. Pick "allow temporarily" (7 days) or "allow indefinitely"
9. Confirm, again, that you understand "the risks"

Nine steps. A mandatory 24-hour cooling-off period. For installing software on a device you own.

Worse: this flow runs entirely through Google Play Services, not the Android OS. Google can change it, tighten it, or kill it at any time, with no OS update required and no consent needed.

This is bigger than Android

If Google can retroactively lock down billions of devices that were sold as open platforms, every hardware manufacturer on the planet is watching.

The principle being established: the company that made your device gets to decide, after you've bought it, what software you're allowed to run. In software, this is called a "rug pull"; but at least you could always install competing software. In hardware, it is a fait accompli that strips you of your agency and renders you powerless to the whims of a single unaccountable gatekeeper and convicted monopolist.

Android's openness was never just a feature. It was the promise that distinguished it from iPhone. Millions chose Android for exactly that reason. Google is now revoking that promise unilaterally, on devices already in people's pockets, because they've decided they have enough market dominance and regulatory capture to get away with it.

Ars Technica: "Google's Apple envy threatens to dismantle Android's open legacy."

But wait, isn't this...

"...just about security?"

The security rationale is a smokescreen. Google Play Protect already scans for malware independent of developer identity. Requiring a government ID doesn't make code safer. It makes developers identifiable and controllable. Malware authors can register. Indie developers and dissidents often can't. The EFF is blunt: identity-based gatekeeping is a censorship tool, not a security one.

"...still sideloading if you use the advanced flow?"

Nine steps, 24-hour wait, buried in Developer Options, delivered through a proprietary service that Google can revoke whenever they want. That's not sideloading. That's a deterrence mechanism built to ensure almost nobody completes it. And since it runs through Play Services rather than the OS, Google can tighten or kill it silently.

"...only a problem if you have something to hide?"

Whistleblowers, journalists, and activists under authoritarian governments will be the first victims. People in domestic abuse situations are next. All these groups have legitimate reasons to distribute or use software without putting their legal identity in a Google database. Anonymous open-source contribution is a tradition older than Google itself. This policy ends it on Android.

"...the same thing Apple does?"

Apple has been a walled garden from day one. People chose Android because it was different. "Apple does it too" is a race to the bottom and a weak tu quoque argument. And under regulatory pressure (the EU's Digital Markets Act), even Apple is being forced to open up. Google is moving in the opposite direction: attempting to further entrench its gatekeeping status.

"...just $25 and some paperwork?"

Maybe, if you're a developer in the US with a credit card and a driver's license. Try being a student in sub-Saharan Africa, or a dissident in Myanmar, or a volunteer maintaining a community health app. The cost isn't only financial: you're surrendering government ID and evidence of your signing keys to a company that routinely complies with government demands to remove apps and expose developers.

Fight back

Everyone

• Install F-Droid on every Android device you own. Alternative stores only survive if people actually use them.
• Contact your regulators. Regulators worldwide are genuinely concerned about monopolies and the centralization of power in the tech sector, and want to hear directly from individuals who are affected and concerned.
• Share this page. Link to keepandroidopen.org everywhere.
• Push back on astroturfers. The "well, actually..." crowd is out in force. Don't let them set the narrative.
• Sign the change.org petition and join the over 100,000 signatories who have made their voices heard.
• Read and share our open letter
• Tell Google what you think of this through their own developer verification survey (for all the good that will do).

Developers

Do not sign up. Don't join the program by signing up for the Android Developer Console and agreeing to their irrevocable Terms and Conditions. Don't verify your identity. Don't play ball.

Google's plan only works if developers comply. Don't.

• Talk other developers and organizations out of signing up.
• Add the FreeDroidWarn library to your apps to warn users.
• Run a website? Add the countdown banner.

Google employees

If you know something about the program's technical implementation or internal rationale, contact tips@keepandroidopen.org from a non-work machine and a non-Gmail account. Strict confidence guaranteed.

Disney+ Originals Can’t Crack the Emmys or Nielsen’s Top 20, But the Streamer Makes Sure Nobody Misses Out on Ads, Even on Premium

Twice a year, Nielsen pulls back the curtain on what America has actually been watching, and the numbers for the first-half of 2026 were revealed recently.

It is a genuinely encouraging picture for streaming overall: Stranger Things and The Pitt are duking it out at the top, shows like One Piece, Invincible and Shrinking are pulling healthy numbers and cracking the Top 20 Most-Watched Originals, and kids remain the single biggest force in the ecosystem, with Bluey outpacing Grey’s Anatomy outright. Even The Big Bang Theory is having a bit of a renaissance. Streaming, in other words, is working.

Here is the breakdown of the biggest original from each major streamer by total minutes viewed in the first half of 2026:

• Netflix: Stranger Things — 23.261 billion minutes
• HBO Max: The Pitt — 21.118 billion minutes
• Paramount+: Landman — 12.400 billion minutes
• Prime Video: The Boys — 9.597 billion minutes
• Peacock: The Traitors — 7.737 billion minutes
• Hulu: Paradise — 5.660 billion minutes
• Apple TV+: Shrinking — 5.246 billion minutes

Disney+ is conspicuously absent from this list, as it does not have an original show in the Top 20 of Nielsen this year so far, which is worth highlighting given the streamer’s size and the fact that it has aired shows like Percy Jackson, Daredevil: Born Again, Star Wars: Maul – Shadow Lord, and Wonder Man already this year.

These are shows with real built-in audiences and brand recognition most competitors would auction organs for. None of them managed to break into Nielsen’s Top 20 Original Series chart for the half. None of them cracked the weekly Top 10 either, at any point, not even for a single week this year.

Stranger Things, at 23.261 billion minutes, remains the most-watched show in the country so far this year. The Pitt sits close behind at 21.118 billion, a remarkable number for a show only in its second season with 30 episodes, compared to Stranger Things’ 42. If every one of those minutes belonged solely to Season 2 of The Pitt, that is roughly 29.5 million complete binges of the season. Numbers that stay astonishing no matter how you slice them. Disney+ has nothing in that conversation.

Disney’s internal data via Luminate does manage to tell a story for its original shows that is marginally more flattering, but only marginally.

Daredevil: Born Again leads Disney+’s original series chart for H1 2026 with 3.6 billion minutes across its combined seasons, followed by Percy Jackson at 2.6 billion and The Mandalorian at 2.4 billion. Wonder Man pulled 1.9 billion minutes in its debut season. Star Wars: Maul — Shadow Lord landed at 1.1 billion. Andor sits at 918.1 million. The Punisher: One Last Kill at 586.2 million. The Book of Boba Fett and Loki both trail under 400 million.

Season views, the actual number of unique viewers tuning in, however, are not quite in Disney’s favour. Wonder Man scored 7 million season views, while Daredevil: Born Again Season 2 sits at just 5.8 million. Meanwhile, Percy Jackson and the Olympians Season 2 only managed 5.3 million views.

These are not mass cultural phenomena. They are shows with dedicated pockets of fandom, titles that provoke enthusiasm within a specific audience and indifference beyond it.

These numbers for flagship Disney+ shows in 2026 are closer to Arrowverse shows like The Flash, which averaged 4.6 million viewers for its 23-episode seasons on The CW, broadcast television of all places, than they are to the expensive prestige shows they’re supposed to be.

It doesn’t help that Disney+ doesn’t make the kind of original content that wins at the Emmys. In fact, despite all the money at their disposal, none of their shows won a single award at the main ceremony this year.

All streaming services ask you to pay money for access to their libraries as well as the original programming they have lined up; among all of them, Disney+ is probably the least interesting streamer out there and offers very little in terms of original programming.

The already sparse original programming will likely shrink even more now to protect the brand value of Marvel and Star Wars following their box-office woes with movies like Thunderbolts, Captain America: Brave New World, and The Mandalorian (which is the least successful Star Wars movie ever).

Against that backdrop of declining cultural relevance and underwhelming viewership numbers, Disney has managed to pull off two unpopular moves in the same breath: charging more for its subscriptions while rewriting, in the fine print, exactly what its most expensive tier actually buys you.

Starting Wednesday, September 23rd, Disney+ Premium and Hulu Premium, the ad-free plans, are both jumping from $18.99 to $21.49 a month, a 13% increase.

The pricing clearly aims to funnel subscribers toward bundles: the Disney+/Hulu Premium bundle only ticks up two dollars, from $19.99 to $21.99 a month, nearly half what buying the two services separately would now cost. The ad-supported standalone plans are rising too, from $11.99 to $12.49 a month, though the Disney+ and Hulu bundle with ads stays flat at $12.99, just 50 cents above buying either service alone.

Disney has also raised prices on its Hulu + Live TV packages and the Disney+/Hulu bundles that include ESPN Select, and separately hiked ESPN Unlimited from $29.99 to $31.99 a month, effective September 17th. New subscribers see the higher Disney+ and Hulu prices immediately; existing customers get hit on their next billing cycle.

That price hike arrives just days after Disney redefined what “Premium” and “Ad-free” are even supposed to mean, stripping the word of most of the promise it is meant to carry.

Starting this week, Disney+ updated its Subscriber Agreement to allow promotional content, sponsorships and advertisements across every single service plan, including the premium tier that was previously sold, explicitly and repeatedly, as a fully commercial-free experience.

The change was confirmed in an email to subscribers stating that all service plans may now include “promotional content,” “sponsorships,” and “advertisements before/after playback of Content and in channels, live/as-live, special events, and any third-party services content.”

Let us be precise about what this means. Subscribers on the cheaper ad-supported tier will not notice any difference. They have always seen ads and will continue to. But anyone paying the premium price for the commercial-free experience will now encounter promotional material, trailers, branded content and Disney-specific offers before or after their shows and films.

Full mid-show ad breaks during playback remain, for now, exclusive to the lowest tier.

Disney is framing the change as a “clarification” of existing terms rather than a new policy, noting that language covering live-content ad breaks, interface notifications, sponsorships and product placement has technically existed in the terms of service for some time. What is new, and what Disney is being careful not to emphasise, is the explicit allowance for ads to run before and after content playback within the ad-free tiers specifically, something the company has not previously done at scale and something its premium subscribers were reasonably led to believe they were paying to avoid.

Part of the shift is tied to Disney+’s expanding sports footprint. Since ESPN’s integration into the platform, including its international rollout to Europe in April with NBA and NHL coverage, ads have run across ESPN’s linear channels and during reruns regardless of subscription tier. That structural carve-out likely made it easier to justify loosening the broader ad language internally.

None of this is happening out of nowhere, and treating it that way would be letting Disney off easy.

Disney+’s premium subscribers have already had a difficult year. The platform temporarily lost HDR and 4K resolution entirely during a legal dispute with InterDigital, a lapse serious enough that Disney had to offer affected subscribers a special early-termination window.

Meanwhile, the shows haven’t shown up on Nielsen’s charts. They haven’t shown up at the Emmys either. And now the one thing premium was actually supposed to buy, freedom from ads, has been rewritten in the fine print and mailed out as a “clarification,” as though nobody would notice the tier they’re paying extra for just got quietly hollowed out from the inside.

Since the early days of automatic computing we have had people that have felt it as a shortcoming that programming required the care and accuracy that is characteristic for the use of any formal symbolism. They blamed the mechanical slave for its strict obedience with which it carried out its given instructions, even if a moment's thought would have revealed that those instructions contained an obvious mistake. "But a moment is a long time, and thought is a painful process." (A.E.Housman). They eagerly hoped and waited for more sensible machinery that would refuse to embark on such nonsensical activities as a trivial clerical error evoked at the time.

Machine code, with its absence of almost any form of redundancy, was soon identified as a needlessly risky interface between man and machine. Partly in response to this recognition so-called "high-level programming languages" were developed, and, as time went by, we learned to a certain extent how to enhance the protection against silly mistakes. It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.) The (abstract) machine corresponding to a programming language remained, however, a faithful slave, i.e. the nonsensible automaton perfectly capable of carrying out nonsensical instructions. Programming remained the use of a formal symbolism and, as such, continued to require the care and accuracy required before.

In order to make machines significantly easier to use, it has been proposed (to try) to design machines that we could instruct in our native tongues. this would, admittedly, make the machines much more complicated, but, it was argued, by letting the machine carry a larger share of the burden, life would become easier for us. It sounds sensible provided you blame the obligation to use a formal symbolism as the source of your difficulties. But is the argument valid? I doubt.

We know in the meantime that the choice of an interface is not just a division of (a fixed amount of) labour, because the work involved in co-operating and communicating across the interface has to be added. We know in the meantime —from sobering experience, I may add— that a change of interface can easily increase at both sides of the fence the amount of work to be done (even drastically so). Hence the increased preference for what are now called "narrow interfaces". Therefore, although changing to communication between machine and man conducted in the latter's native tongue would greatly increase the machine's burden, we have to challenge the assumption that this would simplify man's life.

A short look at the history of mathematics shows how justified this challenge is. Greek mathematics got stuck because it remained a verbal, pictorial activity, Moslem "algebra", after a timid attempt at symbolism, died when it returned to the rhetoric style, and the modern civilized world could only emerge —for better or for worse— when Western Europe could free itself from the fetters of medieval scholasticism —a vain attempt at verbal precision!— thanks to the carefully, or at least consciously designed formal symbolisms that we owe to people like Vieta, Descartes, Leibniz, and (later) Boole.

The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.

Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve. (This was evidently not understood by the author that wrote —in 1977— in the preface of a technical report that "even the standard symbols used for logical connectives have been avoided for the sake of clarity". The occurrence of that sentence suggests that the author's misunderstanding is not confined to him alone.) When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.

It may be illuminating to try to imagine what would have happened if, right from the start our native tongue would have been the only vehicle for the input into and the output from our information processing equipment. My considered guess is that history would, in a sense, have repeated itself, and that computer science would consist mainly of the indeed black art how to bootstrap from there to a sufficiently well-defined formal system. We would need all the intellect in the world to get the interface narrow enough to be usable, and, in view of the history of mankind, it may not be overly pessimistic to guess that to do the job well enough would require again a few thousand years.

Remark. As a result of the educational trend away from intellectual discipline, the last decades have shown in the Western world a sharp decline of people's mastery of their own language: many people that by the standards of a previous generation should know better, are no longer able to use their native tongue effectively, even for purposes for which it is pretty adequate. (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.) This phenomenon —known as "The New Illiteracy"— should discourage those believers in natural language programming that lack the technical insight needed to predict its failure. (End of remark.)

From one gut feeling I derive much consolation: I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.

Growing up as a kid in rural Bavaria, I always dreamed of moving to the US to run a startup. Many kids in my generation shared that dream. To me, it felt like the only way to combine my two greatest passions: writing code and building things.

As I got older, I became disillusioned with the narrative surrounding Silicon Valley. The hockey stick growth, the VC money, the “get rich quick” mentality – it was all one big illusion. For a long time, I couldn’t put my finger on what exactly bothered me about it.

Part of what made me increasingly uncomfortable was the glorification of hustle culture – the idea that you have to work yourself to the bone to make it big against all odds.

The other part was the “winner takes all” mentality and the mindset that you have to “move fast and break things” to succeed.

I don’t believe that has to be the case.

As it turns out, I’ve always been drawn to the exact opposite: sustainable growth, robust solutions, and a long-term mindset. That’s why I’ve been contributing to open source for 15 years, why I only run small, bootstrapped businesses or non-profits, and why I focus on writing and knowledge sharing.

Paul Graham and his VC buddies would have you believe that your ultimate goal as a founder should be to build a unicorn. But when I look at the Ubers, Facebooks, and Googles of this world, I see greed, gatekeeping, systemic exploitation, user tracking, excessive resource consumption, and lawsuits against competitors. These companies will do anything in their power to stay on top – even if it means bending the law or finding legal loopholes. What kind of role model is that?

The Other Side

Who’s on the “other side”? It’s the humble minority building small but meaningful things. These people advocate for privacy, develop civic tech, try to live within their means, move deliberately, and fix what’s broken. They fly under the radar because their success isn’t measured in dollars, and they lack big marketing budgets. Instead, they focus on their product, doing a lot with very little. I find that far more inspiring.

It’s incredibly rewarding to build something people love that can provide you with a comfortable living. There’s no need to risk it all, drop out of college, work insane hours, and leave a trail of destruction in your wake. You can build something small and useful instead, without a venture capitalist breathing down your neck. It’s still hard work, but you’re leaving the campsite a little better than you found it.

Note that moving slowly doesn’t mean you can’t make quick decisions. It’s just that the execution should be deliberate. Don’t wreak havoc along the way. Because the time to fix what you might break rarely comes.

VCs Are Not Your Friends

In “Why to Not Not Start a Startup”, Paul Graham writes:

So, paradoxically, if you’re too inexperienced to start a startup, what you should do is start one. That’s a way more efficient cure for inexperience than a normal job. In fact, getting a normal job may actually make you less able to start a startup, by turning you into a tame animal who thinks he needs an office to work in and a product manager to tell him what software to write.

Let me be blunt: that’s nonsense. It paints a black and white picture of the world that simply doesn’t exist. You don’t have to choose between starting a startup and working a soul-crushing job as a “tame animal” in a cubicle. There’s a whole spectrum of possibilities in between! For instance, you could work for yourself or with a small team, making use of your creativity and coming up with your own ideas.

Paul wants you to start a startup because he wants to fund you and profit from your hard work. His motives are purely egoistical.

If you happen to hit the startup jackpot, Paul gets even richer and you might become wealthy too. If you don’t, you’re left with nothing while Paul, already rich, gets to write an essay about your failure.

That’s a whole lot of risk for very little upside.

You might wonder why I’m picking on Paul Graham so much. It’s because I once looked up to him and valued his essays. He represents a worldview I used to believe in, but now consider harmful. Most of his essays seem true on the surface, but dig deeper and you’ll find his claims are based on a narrow worldview and rarely supported by evidence.

Misleading young, impressionable people is dangerous.

Startup founders bear all the downside risk, while venture capitalists are well-insulated from failure. VCs spread their bets across numerous startups, ensuring they profit regardless of individual outcomes. For you, the founder, it’s an all-or-nothing gamble with your time, energy, and often your financial stability.

Is All VC Money Bad?

Of course not. But I’d argue it’s becoming less and less relevant in today’s world. Take building a software product, for example. You don’t need a fortune to get started anymore. There are website builders, cloud hosting solutions, and open source software at your fingertips. Why take on VC money when you’re just starting out? Some might argue that you profit from valuable networking opportunities and business advice along with the funding. But most of that information is freely available online these days. There’s an abundance of podcasts, videos, and books on the subject if you’re willing to learn.

It’s trickier, of course, if you’re building a physical product. But even that has become much easier in recent years. Could you sell a 3D printed prototype before scaling up production? Or launch a Kickstarter campaign to fund your first batch of products? There are now print-on-demand services for t-shirts, mugs, posters, and books. Plus, there are plenty of brick-and-mortar stores you could approach with your business idea if you’re looking to collaborate.

Let’s say you do become wildly successful and urgently need capital to scale. Maybe then VC money is one way to go. Or you could take out a loan. Either way, remember that money always comes with strings attached. Funding might force you to do things you’re not comfortable with, like compromising your users’ privacy or your own values. And even if not, you’ll constantly be pressured to find new avenues for growth. Wouldn’t it be nicer to focus on making your product better instead? That’s often far more rewarding. But often, if you spend enough time thinking through a problem, you might find a way to prove your concept at a smaller scale.

There Is No Infinite Growth

Ask yourself: What truly motivates you? Is it power, money, or fame? If so, there are more meaningful things in life. Your self-worth isn’t tied to building a unicorn. I don’t know who needs to hear this, but it’s perfectly fine to be 23 and not be a millionaire founder. If you’re a high school or college student dreaming of running a startup, know that there’s another path.

Don’t sell out your moral compass for a quick buck. You don’t have to jump on the AI bandwagon just because it’s the flavor of the month. At least 144 out of 251 companies from the YC W24 batch are building products with “AI”. That’s 57% of the batch. How many of them are actually doing something meaningful with it? How many will still be around in 5 years? What lasting value do these companies bring to the world? We’re accumulating a massive amount of tech debt while rewarding short-term thinking and profit over sustainability.

Sure, Paul will benefit if one of them hits it big. You can read all about it in his next essay.

But maybe there’s another way. Maybe it’s okay to have a small business with a loyal user base that pays the bills. Maybe you don’t need to grow exponentially.

Maybe you can move slow and fix things instead.

The last week has seen a flurry of severe and critical software vulnerabilities affecting thousands of major sites and sending people into a panic. What’s going on here, and what can we do about it?

The bugs

If we want to understand what’s going on in the world of software security at the moment, we need to understand what’s going on with all these bugs. I’m not a cybersecurity expert, so I’m going to link to external explanations instead of going into the gory technical details myself as these people are always going to do a better job at that.

PHP2Shell – CVE-2026-109618 and CVE-2026-109619 (a.k.a. “the big one in the news”)

Two different security teams, one from California security company Calif (as part of OpenAI’s “Patch the Planet” program) and another from Israeli-U.S. cloud security company Wiz (they’re part of Google Cloud, apparently), both found these two Remote Code Execution (RCE) bugs in PHP. They were both using frontier AI models (a.k.a. LLMs, specifically GPT-5.6 Sol/Gemini 4 Argon) to find these vulnerabilities and build the exploits.

Interestingly, one of the bugs (CVE-2026-109618) was found by a security audit the PHP Foundation did in 2024 (funded by the Sovereign Tech Agency which is coincidentally one of the most interesting things happening in the open source space at the moment) but they basically ignored it because they had bigger concerns and couldn’t agree on a fix. The reasoning behind it was that no-one could really figure out how to create an actual exploit based on the theoretical issue.

One thing LLMs are very good at is taking a theoretical security vulnerability, even if that vulnerability is a vague description of what the issue could be, and building it into a full exploit. This has become a major issue in recent months as any notice of a security patch will immediately result in people pointing their LLMs at the codebase, whereupon the agents can very quickly read through diffs until they find something that looks like a security patch, then go backwards to the vulnerability it covers, and follow this all the way to an exploit.

This happens so fast, in fact, that at this point I think it is a reasonable that the moment you announce a security patch should be taken as a last possible date that the full exploit is not being publicly or privately distributed.

This PHP2Shell (as it’s being marketed, vulnerabilities seem to come bundled with their own marketing departments now) is estimated to affect upwards of 70% of the internet, with thousands of websites from Wikimedia Foundation to DeviantArt to much of the UK government and Japanese banking systems to The Traitors BBC programme website. Vulnerabilities do get found, but they don’t normally cause half the internet to shut their servers down, so what’s going on?

To understand this, let’s look at the original post from the PHP Group:

Someone called petecooper posted on Hacker News about the CVEs, apparently unaware that there even was an embargo. This (and other apparent leaks) prompted this hurried statement from the PHP Group and bringing the patch forward from Thursday 22nd to Wednesday 21st. However, the patch still wasn’t going to be available till the next day. This unintentional leak included CVSS scores of 10.0 (i.e. bad, although weirdly the actual scores were 9.2 instead).

Pretty much immediately, this news spread like wildfire and people started panicking. Even though this was found by “responsible security researchers” at “respectable companies”, by the time the security patch actually got released, it was already being exploited in the wild1. The PHP Foundation blamed Calif and a company called Chainguard by saying that Calif leaked a video of the exploit in action (with weird background music and a dancing anime girl) while Chainguard published fixes 6 hours before the embargo was due to lift, both allowing attackers to beat the systems administrators to the punch. The timeline is confusing, but it seems like multiple interconnected things have gone wrong here, all within the space of about 17 hours.

There’s been lots of discussion about whether AI really is the game changer that completely revolutionises computer security or not. The big AI companies (and they are big) obviously want you to think that it is. Some people argue that PHP2Shell is overblown because LLMs tend to be paranoid about vulnerabilities and come up with “exploits” that make bad assumptions (like that the server will run PHP code you upload yourself via some existing file inclusion vulnerability) or cheat in some way. As LiveOverflow points out, LLMs make it very easy to create exploit slop that proves nothing and doesn’t work, but that doesn’t mean that the vulnerability isn’t real and easy to exploit using AI. You can have 10,000 bad slop exploits that don’t work but if there’s one that does, that’s all that matters. Maybe we just need to get used to wading through slop to find the important stuff now.

Others point out that lots of governments (UK2, EU, Japan, USA) got overexcited and released urgent announcements saying everyone had to unplug their computers immediately, so people panicked. I think the reason everyone panicked is that everyone kind of knows that PHP is intensely insecure and they use it anyway, so they’re kind of primed for bad news and to overreact. Also, it actually is really quite bad, so maybe panicking is kind of the correct reaction?

The big takeaway for me from this is that – because of LLMs – the time from “hey I heard there’s a bad RCE in this project” to “there are sophisticated, automated, and concerted attacks using an exploit targeting this vulnerability” has gone from weeks/months to hours/minutes. The fact that there’s loads of non-working exploit slop just shows how genuine expertise is still required to make these things – if you don’t know what you’re looking at, you can’t tell whether the AI has cheated or made bad assumptions.

Links:

• Hacker News: “Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming” (petecooper, 20 Oct 2026)
• PHP2Shell – official website – why does every vulnerability need a name, slogan, and website now?
• Wiz Research: “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet” – these are one of the companies who found the bugs.
• PHP News Archive: “Upcoming Critical PHP Security Release” (20 Oct 2026) – how The PHP Group announced the vulnerability. Note the timelines.
• Wikipedia: PHP2Shell – not too detailed but at least they’re not trying to sell you anything.
• AWS Security Blog: “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot” – they are trying to sell you something, but they’re still doing some interesting analysis.

eMudhra (CVE-2026-111943 for Golang response)

On the exact same day (20th October 2026), Mozilla announced that they were blocking 8 intermediate certificates signed by Indian certificate authority eMudhra. This happened after a pseudonymous security researcher known only as “Wayne” reported to several big tech firms (such as Mozilla, Apple, Google, Microsoft, etc.) that the certificate authority were using laughably poor quality private keys for their intermediate certificates. Where a secure key might be a 100 digit number, eMudhra were using keys like “115”, “56”, and “4”. They must’ve been following RFC 1149.5:

Alt: RFC 1149.5 specifies 4 as the standard IEEE-vetted random number. From xkcd #221, licensed under CC BY-NC 2.5.

There are no indications that this was found or exploited using AI or LLMs, although researcher Scott Helme notes that given a single prompt, Claude was able to recover the private keys of the intermediate certs.

At the time of writing (23rd Oct), eMudhra has announced that it will be retiring from the certificate authority space. In unrelated news, a farmer has announced that he has shut his stable door, following reports of an escaped horse.

Links:

• Mozilla Security Blog: “Protecting Firefox users following the compromise of eMudhra intermediate certificates”
• Scott Helme: “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds”
• eMudhra press release: “eMudhra to Exit global SSL/TLS Certificate Business”
• eMudhra Intermediate CA Compromise – research announcement and trust store checker

Railway bug

The next day, cloud provider Railway announced that they found evidence that hackers had accessed and even decrypted environment variables from their platform, which often hold secrets such as database credentials, API keys, etc. In their statement, they said that they believed that this was part of a concerted effort aimed at compromising companies that provide AI inference.

What would the end goal be here? At the time of writing (23rd Oct), we have very little information to go on. Is this “unauthorized third party” (official announcements of “some randos got into our computers” always find a way to make it seem like a terms of service agreement, maybe that way they think people won’t pay attention to it) trying to spy on people using AI inference to see what they’re doing, even stealing new models or research? Or maybe they’re trying to build a network of compromised inference providers for their own nefarious generative AI purposes (like finding more PHP bugs).

Links:

• Railway Blog: “Security Disclosure: Wednesday October 21st”
• Hacker News discussion of the Railway security disclosure

GitLab (CVE-2026-97229 and CVE-2026-110264)

On 12th October 2026, GitLab warned of a max severity bug in GitLab CI/CD’s regular expression parsing that could enable attackers to execute arbitrary code (another RCE) using a specially crafted regex. This is a CVSS score of 10.0 which is the maximum possible, meaning “this is pretty much as bad as they come”3. This was followed on 21st October 2026 by yet another regex integer overflow RCE, another 10.0.

This follows hot on the heels of yet another 10.0 CVSS CVE from last month (CVE-2026-85706), that time related to path traversal. All three of these bugs were reported through GitLab’s HackerOne bug bounty program. When it became clear that LLMs could research vulnerabilities and write exploits, there was a lot of talk about shutting down bug bounty programs because they didn’t make sense anymore. I’m sure GitLab are glad they didn’t do that now.

Although GitLab is used very widely across academia, government, and private companies, this doesn’t seem to have got as much attention. CVEs in GitLab are obviously very serious, especially for private companies, as a lot of their vitally important intellectual property is stored in there, and having that leak could be disastrous. Often, companies put their GitLab instance behind a VPN/firewall so that they aren’t publicly accessible, which greatly reduces the risk associated with this. It’s also not entirely clear whether these CVEs require specific conditions like publicly accessible projects, user self-registration, etc. It does seem like CVE-2026-110264 requires at least one public project, but I can’t find any information on the conditions around the earlier CVE.

There’s no indication that these were discovered using AI or LLMs. They may have been, but there’s no reason at this point to think they were.

Links:

• GitLab Docs: “GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8”
• GitLab Docs: “GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13”
• Hacker News discussion: “GitLab critical patch release”
• BleepingComputer: “GitLab warns of max severity code execution vulnerability”
• Lobsters discussion: “GitLab warns of max severity code execution vulnerability”
• GitLab Security detection rule: Org-mode render error burst
• GitLab Security detection rule: Onigmo native worker crash

musl libc bug

On 21st October, a bug in musl’s libc related to regex (libc has regex? Apparently…) was announced that leads to denial of service at least, if not code execution. As far as I can tell, this is entirely coincidental in timing and not related to the GitLab bugs, which both also seem to be integer overflows when parsing untrusted regular expressions, one reported on the exact same day. Who knew a regex engine was such a security issue – is regex the new font rendering? The GitLab bugs were both found by a Swede called Johan Carlsson (joaxcar) while the musl bug was reported by Julien Voisin, a French self-proclaimed “open sourcerer”.

Links:

• oss-security: “CVE-2026-107891: musl libc: multiple integer overflow in regcomp”
• Lobsters discussion of the musl regcomp CVE

LiteLLM

Ah, hello my old friend LiteLLM. Proving that, when you’re made of metal and 200 feet tall, lightning can in fact strike twice. It’s not a good sign that when someone asks whether you’ve heard of the big 2026 LiteLLM compromise, you have to ask “which one?” In a piece of good fortune, the whole PHP2Shell and all the others have cannibalised much of the attention, meaning this isn’t getting quite the same traction as last time in March, despite being similarly bad.

This time, it’s a malicious version on the Python Package Index (PyPI) and Docker images. For those who don’t remember, LiteLLM had a very similar thing happen back in March, where a malicious package was uploaded to the litellm package on PyPI that used the .pth files to autoload malicious code (yeah, it was bad).

This compromise again took advantage of .pth files and this time also the sitecutomize.py file for autoloading malicious payloads, running in the preload step as soon as the Python interpreter starts up. According to the analysis from Wiz, the payload has “strong indications of LLM-aided development” – things like overly verbose variable names, overly defensive error handling, brittle edge cases, and all the comments saying “this is where it really bites”, “it’s worth sitting with that”, “lean into that”, and “that stays yours” repeatedly4.

According to LiteLLM, the incident occurred because the attacker had access to credentials for GitHub CLI which allowed them to run CI jobs. LiteLLM note that Claude Code will apparently sometimes embed a user’s GitHub CLI OAuth token into response bodies which could cause them to appear in LiteLLM logs.

Links:

• Wiz Blog: “LiteLLM Compromised, Steals Credentials”
• LiteLLM: “Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised”
• Hacker News discussion: “Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor”

PingCAP

On October 19th 2026, an enterprise software company called “PingCAP” that develops a database called “TiDB” revealed “unauthorised access to PingCAP” with “no evidence that data stored in TiDB was impacted”. At the same time, a cyber extortion group called “FulcrumSec” (a.k.a. the “Threatspians”5) said they had exfiltrated 10.6 TB of data from PingCAP and publicly released a torrent with 200 GB of data, as a “stage one release” (you’ve gotta get people invested in the sequel).

They also posted full details of what they took and some of the excellent security practices of PingCAP, including putting client AWS secret access keys inside Jira tickets and attaching massive unredacted logs to Jira tickets including OpenAI, Anthropic, Gemini, xAI API keys. Yikes. If you’re willing to visit the cyber extortion group’s website, they do a pretty interesting write-up of it. Gone are the days of shoddy broken English back when the Russians had to write these things up without LLMs to do it for them and remind them of definite and indefinite articles.6

The good news for PingCAP is that not finding evidence of data extraction is actually incredibly easy. In fact, I’m doing it for thousands of companies right now, for free. I’m sure there’s a business proposal in there somewhere. All you have to do is not look (see also: U+1F648). To be fair, I think their argument is that no data inside TiDB instances was compromised. 10.6 TB seems like a lot of data if that’s the case. There’s clearly still tons of customer data.

Links:

• Hacker News discussion: “PingCap TiDB Leaks”
• PingCAP: “October 2026 Security Incident Report: Unauthorized Access to PingCAP Cloud Resources” – PingCAP’s detailed and highly reliable analysis of the incident.
• FulcrumSec: “The PingCAP TiDB Cloud Leaks” – heads up, this is the website of a known cyber extortion group. Don’t say I didn’t warn you. It is pretty interesting, though.

Linux vulnerabilities accidentally posted in wrong group chat

Linux kernel development all happens through mailing lists. Naturally, some of those are about security sensitive things, so these are private. Over the night of 21st-22nd October 2026, the Zero Day Initiative (ZDI), a software vulnerability initiative owned by Trend Micro, reported a bunch of high severity (upwards of 9.0 CVSS) CVEs to the public mailing list, instead of the private one. Naturally, the assumption is that anyone with an LLM and a heart full of dreams will then be able to take those reports and turn them into active exploits within a matter of minutes. This isn’t quite as bad as that time Pete Hegseth accidentally texted details of upcoming military strikes in Yemen to The Atlantic7, but it’s still interesting how seriously people take this now.

Links:

• Phoronix: “Several Linux Kernel Vulnerabilities Accidentally Posted To Public Kernel Mailing List”

Is this the new normal?

I think it’s fair to say these last few days have been abnormally active in terms of all of these cyber incidents and security disclosures. There are many commenters on the Hacker News discussions for these incidents that say that this is nothing and it’s only going to get worse. Honestly, I’ve not decided yet. To be honest, if you’d asked me 4 years ago how far LLMs would go, I’d never have guessed they’d get as good as they are right now. Even so, people do tend to get overexcited by these announcements and suggest that we are going to live in a world where no software is secure and everyone is vulnerable.

It’s worth noting that while a lot of the online discussion around this focusses on AI and LLMs, only some of these disclosures were researched or created with LLMs. We don’t know about some of them like the PingCAP one, but there’s clear evidence that many criminal and state-sponsored groups are using AI to do more hacking and faster. Why wouldn’t they? It seems to be pretty good at it. Many of these vulnerabilities were good old fashioned software vulnerabilities found and written using human meat fingers, but the online conversation focusses on the exciting, scary new thing. Why wouldn’t it?

You can see why organisations like NHS England decided to take all of their open source code private (even though that was a silly decision). When these LLMs are so good that anyone can point their agent at some open source code and find tons of vulnerabilities, then write full exploits for them, that is concerning for many. So what’s the solution here?

What can we do about it?

The NHS approach: close source everything. (A.k.a. the Madagascar approach)

Pros:

• Your code isn’t online anymore, so people can’t point their LLMs at it and do things like analyse every commit for security fixes, find tons of previously unknown critical bugs, etc.

Cons:

• The open source community and the future of computing are slightly worse off for every open source repository taken offline.
• You can’t close source every codebase in the world – some things like programming languages (which are often the source of critical bugs) rely on open source to function. Making Python a closed source project would be catastrophic to the world of computing.
• It’s only closed source until someone leaks it. And they probably will eventually. And when they do, you won’t have had the years of public scrutiny on the codebase that keeps it clean and secure in the first place.
• Sometimes you use a programming language where this doesn’t really matter, like Python and Java where you can recover source code from bytecode.
• LLMs can even reverse engineer compiled binaries pretty effectively.
• If the code used to be online, that old version still is. You have to assume that someone will have it somewhere. Shellshock was in GNU Bash from 1989 until 2014 before it was fixed, and that’s one of the most widely used programs on the planet.
• It makes me sad :(

The AI-embracer approach: if you can’t beat ‘em, join ‘em. In other words, they can’t use LLMs to find vulnerabilities if we’ve already run our better LLMs on our code faster and with more money and better models.

Pros:

• Makes a few very wealthy tech CEOs very happy.
• Will find tons of bugs.

Cons:

• Makes a few very wealthy tech CEOs very happy.
• Will find tons of bugs. (Someone is gonna have to fix those.)
• Costs loads of money.
• Even though AI makes it easier, it still requires expertise and deep technical knowledge to do this stuff properly (for now).

The optimist approach: universally better, standardised approaches to reporting, handling, and mitigating security vulnerabilities followed by all companies having top-notch security postures, well-understood risks, well-documented processes, and so on.

Pros:

• Lovely idea.
• Why didn’t anyone else think of this?
• Gee, we are so clever. Have we just solved this?

Cons:

• We do not live in this world. We will never live in this world.
• Did I mention this is actually quite hard? And possibly impossible?
• Expensive.

There are some easy wins we could get from this moving forwards, like “never announce details of a critical vulnerability before the patch is ready to install”, but in this case unintentional leaks meant everyone knew about the vulnerabilities even before the official announcement. Maybe even that’s asking too much. In this case, it was a series of mistakes from multiple people and companies that led to or accelerated the exploit being in active use hours before the patch was available, hence everyone taking their servers offline. AWS have since said they saw someone trying out this vulnerability from 17th October, before any of these leaks happened.

Even something like minimum release age which gained popularity after shalk/debug, Shai-Hulud, & March LiteLLM incidents, as it means big updates that fix widely exploited vulnerabilities don’t get patched for a few days, giving attackers ample time to hack you to pieces. At the very least, we could maybe do with some better client management to avoid everyone panicking and taking all their servers offline.

Maybe we just need to accept that if you expose something to the wider internet, it will get hacked, and plan accordingly. Maybe it’s our expectations that are at fault.

Conclusion

There’s definitely a story about AI and security here. It’s changing the world of software, and it’s not yet clear whether that’s for the better or the worse. Money has a way of warping truth like matter warps spacetime, and there’s enough money in AI to cause whatever the truth equivalent of a medium-sized black hole is. There’s an incredible amount of money being spent on AI and it all wants you to think that it’s going to change everything about your life, including software and security. That doesn’t mean it’s not true, of course.

Some people say automated analysis tools led to loads of new bugs being found back in the ’10s, and now the same thing is happening again. It feels categorically different to me, but perhaps there will be an initial period of escalating bug reports before it all settles down and goes back to how it was. I suspect not. Some people say this is only happening because humans wrote all the dodgy code in the first place – once AI is writing all of the code to start with, there’ll be no vulnerabilities because LLMs are better at writing secure code than humans. I am not convinced by this argument.

While I’m not making many predictions about the future (because I don’t want to look like an idiot in 12 months’ time when I’m inevitably proven wrong), I will say that the software industry is going to change, and open source is going to change, and it is our collective responsibility as members of the software community to make sure that this change is for the benefit of all of us, not special interests and private corporations.

Updates

This is a developing story – I’ll note any updates in here. I wrote this in somewhat of a hurry, so I may also make some incremental improvements to the wording and evidencing behind some bits.

Footnotes

1. There is some discussion and disagreement about whether any real, working attempts at exploiting this were made before the patch was released.
2. Disclaimer: I kind of work for the UK government.
3. GitLab is using CVSS 3.1 while PHP is using CVSS 4.0 here, which means they’re following slightly different metrics to calculate the CVSS score, meaning you can’t directly compare them.
4. Ok, maybe not this last point.
5. If these reprehensible criminals are ever brought to justice, I propose their longest sentence be for crimes against wordplay. Truly atrocious.
6. To clarify, there’s no evidence that this group are Russian hackers. They seem to be primarily financially motivated, so they could be from anywhere and everywhere. You get my point though – back in the day, you could tell the Russian phishing campaigns from their grammatical peculiarities. Nowadays it’s lost all of its charm, all because of AI.
7. Fortunately, being the upstanding and trustworthy citizen that he is and someone who bases his administrative recruitment decisions on what’s best for the country as opposed to personal loyalty and piety to the president’s personal agenda of emolument, the president ensured that all those responsible were swiftly removed from his administration, never to be seen in Washington again.

Estimates based on the average emissions intensity of each regional electricity grid

STOCKHOLM, 21 October 2026. Swedish AI provider Berget AI today releases an open-source method for calculating the carbon emissions of every individual AI request, developed with researchers from Stockholm Environment Institute (SEI) and the tech non-profits WattTime and Klimatkollen. Berget AI's customers can follow their own emissions in the company's console as they use the service. By making the method free for anyone to use, Berget AI wants more AI providers to report emissions per request, so that buyers can compare providers on real figures and choose lower-carbon options.

"Most companies today have no way of knowing what their use of AI emits. With this method our customers can follow their emissions request by request and compare providers on data instead of marketing. We know most European buyers would choose differently if they could see the numbers," says Andreas Lundmark, CEO of Berget AI.

A typical request to the open model Kimi K3 emits about 0.4 grams of CO₂ in Sweden, 1.6 grams in Ireland, 2.5 grams in Germany and 3.2 grams in Texas, on identical hardware — 8.5 times more in Texas than in Sweden. The result also depends on the model, the time of day and whether part of the prompt is cached, so the method calculates each request separately instead of applying an average. Berget AI reports location-based figures, using the average grid mix where the servers run, and includes the emissions from manufacturing the hardware.

Buyers rarely get emission figures from their AI providers, and the public figures that exist are mostly averages estimated from the outside. Open-weight models, which can run in any data centre, handle a growing share of AI traffic: 29% of tokens on Vercel's AI Gateway in June 2026, up from 11% in April. For those models, where a request runs is the buyer's choice, provided the emissions are visible.

"Most of the alarming figures about AI's footprint come from multiplying an average by a guess at the volume, and nobody can check them. The only fair comparison is to calculate each request and add them up. We have published our judgement calls so anyone can check and use them," says Christian Landgren, CTO and co-founder of Berget AI.

"The International Energy Agency projects data-centre electricity consumption to more than double to about 945 TWh by 2030, with AI as the principal driver. Any promise of efficiency gains is likely to be outweighed by higher demand, negating any emission reductions from renewables. Methodologies like this offer a transparent basis for informed decisions. Their strength is that they clearly demonstrate how the location of the grid and critical infrastructure matter when it comes to how sustainable AI can be," says Somya Joshi, Research Director at SEI.

About the method

The partners mapped and measured the environmental impact of Berget AI's infrastructure, including energy, water and hardware, as well as the carbon footprint of Klimatkollen's Garbo AI, which runs on it. They combined the data with current research on translating it into carbon emissions and broader environmental impact.

The method follows the Green Software Foundation's SCI for AI specification and is available under the MIT licence on GitHub. The calculator at co2.berget.ai applies it to any model and region. It builds on open-source estimators such as EcoLogits and the Sustainable AI Group's CLEER dashboard, which estimate emissions from outside the provider. As far as we know, Berget AI is the first inference provider to calculate emissions for every request on its own infrastructure and publish the method. The partners will keep developing it, for example to cover the water and energy footprint of chip manufacturing, which the current version does not include.

Emissions estimates are based on the current average emissions intensity of each regional electricity grid, which has been the norm in greenhouse gas accounting. An emerging approach uses marginal emission rates, which estimate the impact of additional load on both the use of existing power plants and the new generators built to meet increased demand. Marginal estimates will be added to the calculator next month and may significantly change the measured greenhouse gas intensity of data centres in Sweden.

Correction, 21 October 2026: an earlier version of this release, distributed under embargo, stated 1.2 g (Ireland), 2.1 g (Germany) and 3.9 g (Texas) per request and a ten-fold difference between Texas and Sweden. A source review of the grid intensities published with this release corrected them to Ireland ~224, Germany ~337 and Texas ~333 g CO₂e/kWh; the corrected per-request figures appear above and the Texas–Sweden difference is 8.5×. Sweden's figure is unchanged.

Facts

Grid intensity: Sweden ~8 g CO₂e/kWh (IEA 2024) · Ireland ~224 (SEAI 2024) · Germany ~337 (Ember 2024) · Texas (ERCOT) ~333 (EPA eGRID 2023) · global average ~470 (Ember 2024)

Embodied hardware: ~1,000 kg CO₂ per data centre GPU; refurbished counted as zero

Idle power: An idle B300 still draws 236 W (measured over seven days in production)

Cooling: Nordic free air: PUE ~1.15, no water. Hot climates: toward 1.8, up to 2 L water/kWh

Scope: Training excluded: self-reported figures vary ±50%

Open-model traffic: 29% of tokens on Vercel AI Gateway, June 2026 (about 11% in April); ~69% of named-model tokens on OpenRouter

Kimi K3, one typical request: Sweden 0.38 g CO₂e (89% from hardware manufacturing). Texas 3.2 g (90% from electricity), plus about 6 mL of cooling water. Energy about 4 Wh in both. Calculated with @bergetai/co2-calculator 1.1.1: B300 node, shared deployment, production-typical request of 5,000 input and 387 output tokens, weighted by a typical day's traffic.

About Berget AI

Berget AI champions AI sovereignty to unlock innovation and growth in Europe. Founded in Sweden in 2024, Berget AI offers inference and AI infrastructure for private and public sector organisations. Since 2025 it has reported the CO₂ emissions of every API request.

About SEI, WattTime and Klimatkollen

Partners: Stockholm Environment Institute (knowledge partner), WattTime (scientific partner), Klimatkollen (partner).

Stockholm Environment Institute is an international non-profit research institute that tackles climate, environment and sustainable development challenges. To learn more, visit www.sei.org.

Klimatkollen.se is a Swedish citizen platform that presents climate data about municipalities and companies. The purpose is to contribute to more engaged citizens, a more fact-based climate debate, and measures that reduce emissions in line with the Paris Agreement. Klimatkollen is run by the non-profit association Klimatbyrån.

WattTime is an environmental tech nonprofit that empowers all people, companies, policymakers, and countries to slash emissions and choose cleaner energy. Founded by UC Berkeley researchers, we research, develop, and share data-driven tools and policies that help anyone who is interested to reduce more emissions, faster. www.watttime.org

When timestamps aren’t time-ordered and other oddities

I’m going to call it. UUIDv7 is weird.

Most blog posts about UUIDv7 tout these benefits:

• monotonically increasing IDs
• a helpful timestamp of when the object was created; and
• unguessable IDs

But none of these properties are strictly held. Certain RFC compliant implementations of UUIDv7 violate these properties to extreme degrees. The only useful property UUIDv7 appears to strictly provide is uniqueness and therefore collision resistance. I’ve already discussed how UUIDv7 IDs can be guessable, so this post explores the other properties.

Is the timestamp useful?

Superficially, it seems that embedding a timestamp in the ID can remove the need to track the creation time in a separate database column, providing marginally more efficient database operations. If you need to list things ordered by creation time very often, it’s useful if the primary index gives that behavior, removing the need for another index.

Unfortunately, the timestamp embedded in a UUIDv7 ID may not relate to the object creation time. The Postgres docs for uuid_extract_timestamp helpfully warn that “the extracted timestamp is not necessarily exactly equal to the time the UUID was generated”.

RFC 9562 allows implementations to alter the timestamp field, using values that aren’t strictly derived from the system clock. This relates to the tension between UUID monotonicity and timestamp accuracy. In certain scenarios, the difference between the timestamp and the current time can be arbitrarily large.

Implementations MAY alter the actual timestamp. — RFC 9562 §6.1

This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time. — RFC 9562 §6.1

… implementations MAY increment the timestamp ahead of the actual time … — RFC 9562 §6.2

Incrementing the timestamp ahead of the system clock is an interesting problem. If the generator is seeing so much load that a counter field is regularly overflowing then the timestamp could accelerate into the future. Using a sufficiently large counter would be wise and the RFC says the minimum size SHOULD be 12 bits. A counter overflow would require a pretty aggressive creation rate, over 4,096 IDs per millisecond per node, which is beyond the limits of many systems. This overflow becomes relevant, however, if the timestamp freezes; which I’ll discuss in a later section.

Example: Python uuid.uuid7()

One prominent implementation that increments the timestamp is the Python standard library’s UUIDv7. The increment happens only in certain circumstances, like when the counter overflows. Unfortunately, the generator can get stuck in an increment cycle if the clock ever jumps backwards and the timestamp can race ahead of the system time by an arbitrarily large amount.

Here’s a simple example:

import uuid
from datetime import datetime

# Prime the generator with the current time
t = uuid.uuid7().time
now = datetime.now()
delta = (datetime.fromtimestamp(t/1000) - now).total_seconds()
print("Initial delta: ", delta)
# Ask the user to change the time
input("Set clock back one hour")

while True:
    for _ in range(100000):
        uuid.uuid7()
    t = uuid.uuid7().time
    now = datetime.now()
    delta = (datetime.fromtimestamp(t/1000) - now).total_seconds()
    print("New delta: ", delta)

Which gives:

$ uv run --python 3.14 main.py
Initial delta:  -0.000748
Set clock back one hour
New delta:  3695.277581
New delta:  3795.042411
New delta:  3894.80756
New delta:  3994.573106
^C

We expect the difference to be 3600 seconds (one hour) as the implementation refuses to allow the embedded timestamp to jump backwards and we expect the difference to decrease as the system clock catches up to the frozen timestamp. But when the load is above one ID per millisecond the difference will increase without bound. At lower loads it will take longer for the system clock to catch the timestamp, but we don’t see the runaway effect.

The related issue shows Python developers reasoning that this is consistent with the RFC, is consistent with other implementations, and that there isn’t “much we can do” on a “flawed system”. I think these points are correct as I see this same behavior in other implementations. Nevertheless, it would be helpful if existing UUIDv7 implementations could handle system clock jumps without runaway behavior. There are many real-world examples of clocks jumping backwards, even decades out of sync in time-sensitive environments.

Is leaking a timestamp harmful?

Embedding the timestamp in the ID means that you cannot share the ID without also sharing the timestamp.

It’s pretty difficult to think of an example where this really matters. One example could be a user profile page that doesn’t disclose when the account was created, but the UUIDv7 ID in the URL leaks the high-precision timestamp.

This issue would typically be very low on my list of security concerns because I find much more severe problems when I do security assessments. Nevertheless, there are contexts where this matters and engineering resources would be focused on addressing it. If you’re in the latter camp, be wary of UUIDv7 leaking metadata.

Are UUIDv7s monotonic?

This section is even more pedantic, so skip ahead if you’ve had enough. Briefly: UUIDv7 IDs provide some sort of rough order, which may be suitable for your requirements.

When I was reading the UUIDv7 RFC I was surprised to see it describing a method for creating IDs across different nodes that are monotonically ordered. This was proven impossible back in the 1970s, and lead to the development of vector clocks and similar technology. At a high level, the problem is that system clocks cannot be synchronized to a suitable precision. Ordering things by timestamp only works if you know precisely what time it is. Any uncertainty in the time results in uncertainty of event ordering.

Succinctly: Timestamps are only time-ordered if you know what time it is and you don’t know what time it is.

For this reason, similar ID formats claim to be nearly sorted. It seems odd that UUIDv7 makes a stricter claim and does not deliver on them. At the very least, the challenges of synchronizing clocks across systems make the millisecond and especially the sub-millisecond timestamps quite suspect.

But even on a single node, using a single implementation, UUIDv7 IDs are not strictly monotonic. The easiest way to get out-of-order UUIDv7 IDs is to use an implementation that uses a millisecond timestamp without a counter. This approach trivially generates out-of-order IDs inside a small for loop.

So no, there’s nothing in the UUIDv7 specification that would ensure the IDs are strictly monotonically increasing. Specific implementations may do better than others (with sub-millisecond timestamps, counters, well-synchronized clocks, etc), but we’ve known since the 1970s that this problem is not strictly solvable.

In UUIDv7’s favor, roughly ordered IDs are still quite useful. So don’t rip UUIDv7 out of your systems just yet. Just be wary of what assumptions you have.

Restarting a UUIDv7 generator

The RFC has lots of discussion about the handling of clocks that jump backwards. Timestamps are only time-ordered if clocks tick forwards, so special care is needed.

We’ve already discussed one mitigation: tracking the last generated timestamp to ensure that an earlier timestamp is never used. To do this safely you’ll need to write the last used timestamp to persistent storage, such that you can read it again after a system reboot or a process restart.

I’ve looked at several UUIDv7 implementations I couldn’t find one that writes timestamps to persistent storage. So implementers seems disinterested in addressing the issue and they generate out-of-order IDs when a process restart follows a clock jumping backwards.

Looking at real-world clock synchronization problems, you’ll find many examples of clocks getting set to future dates. When this happens, the backwards jump would align the timestamp to the actual time, but a last-used-timestamp guard would force timestamps to use keep using that incorrect timestamp until the system clock catches up. If the system clock takes a long time to catch up, you may start experiencing counter rollovers.

So what is UUIDv7?

My mental model for UUIDv7 is that it’s a mash-up of a bunch of different ideas which implementations are free to choose as they see fit. There’s a wide variance of properties that UUIDv7 implementations can provide, with varying degrees of certainty they can successfully provide those properties. If you’re building your own implementation you can likely build something that has the properties you need. But most of us want to reach for an off-the-shelf version, especially when standard libraries provide an implementation, so we’re generally at the mercy of someone else’s implementation decisions. Implementations can change over time, making broad changes to their behavior while still being RFC compliant. Distributed systems may have multiple implementations across their subsystems, each with distinct properties. The only thing you can really expect is strong collision avoidance and ID uniqueness.

Be sure to ask these questions when picking a UUIDv7 implementation:

• Is the implementation compliant with the RFC?
• What additional properties does this implementation guarantee?
• Under what limits can those guarantees be met?
• Are there any assumptions required for these properties to hold, such as having an accurate system clock?
• Under what conditions will the implementation alter the timestamp?
• How guessable are the generated IDs?

Unfortunately, this sort of analysis is much more difficult than building an RFC compliant generator. Authors of UUIDv7 generators may not know the answers to these questions and may themselves be surprised that the RFC does handle this for them.

Model summary

Intelligence

#4 / 215

55

Artificial Analysis Intelligence Index

4 out of 4 units for Intelligence.

Speed

#102 / 186

77.1

Output tokens per second

2 out of 4 units for Speed.

Cost

#85 / 113

In $2.00Out $10.00Cache Discount 90%

$2.11

Cost per Intelligence Index task

3 out of 4 units for Cost.

Verbosity

#92 / 116

150M

Output tokens from Intelligence Index

4 out of 4 units for Verbosity.

Comparison Summary

Kimi K3.1 Pro is amongst the leading models in intelligence and reasonably priced when comparing to other models of similar price. It's also slower than average and very verbose. The model supports text and image input, outputs text, and has a 1M tokens context window.

Kimi K3.1 Pro scores 55 on the Artificial Analysis Intelligence Index, placing it well above average among comparable models (median: 27). When evaluating the Intelligence Index, it generated 150M tokens, which is very verbose in comparison to the median of 87M.

Pricing for Kimi K3.1 Pro is $2.00 per 1M input tokens (moderately priced, median: $2.00) and $10.00 per 1M output tokens (moderately priced, median: $10.00). On average, it costs $2.11 per task to evaluate Kimi K3.1 Pro on the Intelligence Index.

At 77 tokens per second, Kimi K3.1 Pro is slower than average (79).

Technical specifications

Reasoning

Yes

This page shows the reasoning version of this model.

A non-reasoning variant may also exist.

Input modality

Supports: text and image

Output modality

Supports: text

Context window

1M

~1500 A4 pages of size 12 Arial font

217 models in this class

Metrics are compared against models of the same class:

• Non-reasoning models → compared only with other non-reasoning models
• Reasoning models → compared across both reasoning and non-reasoning
• Open weights models → compared only with other open weights models of the same size class:
  • Tiny: ≤4B parameters
  • Small: 4B–40B parameters
  • Medium: 40B–150B parameters
  • Large: >150B parameters
• Proprietary models → compared across proprietary and open weights models of the same price range, using a blended 3:1 input/output price ratio:
  • <$0.15 per 1M tokens
  • $0.15–$1 per 1M tokens

  • $1 per 1M tokens

Intelligence

Artificial Analysis Intelligence Index

Artificial Analysis Intelligence Index v4.3.2 incorporates 10 evaluations: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR v1.1

Artificial Analysis Intelligence Index

Artificial Analysis Intelligence Index v4.3.2 includes: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR v1.1. See Intelligence Index methodology for further details, including a breakdown of each evaluation and how we run them.

Artificial Analysis Intelligence Index by Open Weights / Proprietary

Artificial Analysis Intelligence Index v4.3.2 incorporates 10 evaluations: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR v1.1

Open Weights

Indicates whether the model weights are available. Models are labelled as 'Commercial Use Restricted' if commercial use is limited by conditions, and as 'Non-commercial' if the license prohibits commercial use.

Cost per Intelligence Index Task

Weighted average cost per Intelligence Index task. Each evaluation’s cost is calculated from input, cache hit, cache write, reasoning, and answer token prices, divided by task count, and weighted by the Intelligence Index weight.

Artificial Analysis Intelligence Index

Artificial Analysis Intelligence Index v4.3.2 includes: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR v1.1. See Intelligence Index methodology for further details, including a breakdown of each evaluation and how we run them.

Capability Indexes

Measures the performance of models on specific capabilities and industries.

Artificial Analysis Finance & Accounting Index

Incorporates 7 evaluations: AA-Omniscience, GDPval-AA v2.1, AA-Briefcase v1.1, Humanity's Last Exam, AutomationBench-AA, AA-LCR v1.1, GDP.pdf · Higher is better

Benchmarks

Evaluations

Evaluations measured independently by Artificial Analysis · AA-PersonalityBench scores are percentile ranks from 1 to 100.

AA-Briefcase v1.1

Agentic knowledge work, Elo

AA-Omniscience Accuracy

Knowledge

AA-Omniscience Non-Hallucination Rate

1 - hallucination rate

AutomationBench-AA

Agentic SaaS workflows

GDPval-AA v2.1

Agentic real-world work tasks, Elo

Humanity's Last Exam

Reasoning & knowledge

GDP.pdf

Professional document reasoning, All-pass

Terminal-Bench 4.0

Agentic coding & terminal use

AA-LCR v1.1

Long context reasoning

SciCode

Under review

Coding

CritPt

Physics reasoning

Terminal-Bench-Science 0.1

Agentic scientific research workflows in a terminal

FrontierCode 1.1

Agentic software engineering in open-source repositories

AA-AnalystAgent

Quantitative analysis on spreadsheets & documents

Harvey LAB-AA v1.1

Legal agentic work, Hallucination-Gated All-Pass Rate

EnterpriseOps-Gym-AA

Agentic business operations

AA-3D

Agentic interactive 3D experiences, Elo

ITBench-AA

Kubernetes incident root-cause analysis

MLCR-AA

Medical long context reasoning

MMMU-Pro

Visual reasoning

AA-PersonalityBench: Expressiveness Score

Rich, varied, well-crafted language

AA-PersonalityBench: Organization Score

Well-structured, scannable, answer-first

AA-PersonalityBench: Transparency Score

Truthful, acknowledges uncertainty, non-sycophantic

AA-PersonalityBench: Slop Score

Use of filler and generic language

Intelligence Evaluation Relevance

While model intelligence generally translates across use cases, specific evaluations may be more relevant for certain use cases.

Artificial Analysis Intelligence Index

Artificial Analysis Intelligence Index v4.3.2 includes: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR v1.1. See Intelligence Index methodology for further details, including a breakdown of each evaluation and how we run them.

AA-Briefcase v1.1

AA-Briefcase EloAA-Briefcase Rubric Score (%)Analytical Quality & Presentation Elo

AA-Briefcase Elo

AA-Briefcase v1.1 is an agentic knowledge work benchmark developed by Artificial Analysis. AA-Briefcase Elo is a combined metric that aggregates rubric pass rate, analytical quality Elo and presentation Elo · Higher is better

AA-Briefcase Elo

AA-Briefcase Elo is a combined metric that aggregates analytical quality Elo, presentation Elo, and rubric pass rate, with rubric performance converted into Elo via synthetic head-to-head matches. Elo and 95% confidence interval bounds are clamped at 0.

AA-Omniscience

AA-Omniscience Index

AA-Omniscience Index (higher is better) measures knowledge reliability and hallucination. It rewards correct answers, penalizes hallucinations, and has no penalty for refusing to answer. Scores range from -100 to 100, where 0 means as many correct as incorrect answers, and negative scores mean more incorrect than correct.

AA-Omniscience Index

AA-Omniscience Index (higher is better) measures knowledge reliability and hallucination. It rewards correct answers, penalizes hallucinations, and has no penalty for refusing to answer. Scores range from -100 to 100, where 0 means as many correct as incorrect answers, and negative scores mean more incorrect than correct.

AA-PersonalityBench

Communication Characteristics

Intelligence Index Comparisons

Cost per Intelligence Index Task

Weighted average cost per Intelligence Index task. Each evaluation’s cost is calculated from input, cache hit, cache write, reasoning, and answer token prices, divided by task count, and weighted by the Intelligence Index weight.

Artificial Analysis Intelligence Index

Artificial Analysis Intelligence Index v4.3.2 includes: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, AA-LCR v1.1. See Intelligence Index methodology for further details, including a breakdown of each evaluation and how we run them.

Token Use

Output Tokens per Intelligence Index Task

Weighted average number of output tokens used to run one task in the Artificial Analysis Intelligence Index.

Output Tokens per Intelligence Index Task

The number of tokens required per Intelligence Index task. This is calculated by multiplying the output tokens per eval by the relative weights of each benchmark in the Intelligence Index, then dividing by task count (excluding repeats).

Cost

Cost per Intelligence Index Task

Weighted average cost (USD) per Intelligence Index task · Segmented by token type · Lower is better

Cost per Intelligence Index Task

Weighted average cost per Intelligence Index task. Each evaluation’s cost is calculated from input, cache hit, cache write, reasoning, and answer token prices, divided by task count, and weighted by the Intelligence Index weight.

Cost to Run Artificial Analysis Intelligence Index

Cost (USD) to run all evaluations in the Artificial Analysis Intelligence Index.

Cost to Run Artificial Analysis Intelligence Index

The cost to run the evaluations in the Artificial Analysis Intelligence Index, calculated using the model's input, cache hit, cache write, reasoning, and answer token prices and the number of tokens used across evaluations (excluding repeats).

Cache Hit

Price per token for cached prompts (previously processed), typically offering a significant discount compared to regular input price, represented as USD per million tokens. The values shown here are the cache hit price; cache write and cache storage are billed separately and vary by provider — see "Cache pricing by provider" for detail.

Context Window

Context Window

Context window: tokens limit · Higher is better

Context Window for RAG

Larger context windows are relevant to RAG (Retrieval Augmented Generation) LLM workflows which typically involve reasoning and information retrieval of large amounts of data.

Context Window

Maximum number of combined input & output tokens. Output tokens commonly have a significantly lower limit (varied by model).

Speed

Measured by Output Speed (tokens per second).

Output Speed

Output tokens per second · Higher is better

Output Speed

Tokens per second received while the model is generating tokens (ie. after first chunk has been received from the API for models which support streaming).

Model Performance Representation

Figures represent performance of the model's first-party API or the median across providers where a first-party API is not available.

Time per Intelligence Index Task

Weighted average decode time (minutes) per Intelligence Index task · Excludes TTFT and overhead time · Lower is better

Time per Intelligence Index Task

The weighted average time (seconds) per Artificial Intelligence Index task. This is calculated by dividing output tokens per task by output speed, weighted by the relative weights of each benchmark in the Intelligence Index.

Latency

Measured by Time (seconds) to First Token.

Latency: Time To First Answer Token

Seconds to first answer token received · Accounts for reasoning model 'thinking' time

Time to First Answer Token

Time to first answer token received, in seconds, after API request sent. For reasoning models, this includes the 'thinking' time of the model before providing an answer. For models which do not support streaming, this represents the time to receive the completion.

End-to-End Response Time

Seconds to output 500 tokens, calculated based on time to first token, 'thinking' time for reasoning models, and output speed.

End-to-End Response Time

Seconds to receive a 500 token response. Key components:

• Input time: Time to receive the first response token
• Thinking time (only for reasoning models): Time reasoning models spend outputting tokens to reason prior to providing an answer. Amount of tokens based on the average reasoning tokens across a diverse set of 60 prompts (methodology details).
• Answer time: Time to generate 500 output tokens, based on output speed

Model Performance Representation

Figures represent performance of the model's first-party API or the median across providers where a first-party API is not available.

Frequently Asked Questions

Common questions about Kimi K3.1 Pro.

When was Kimi K3.1 Pro released?

Kimi K3.1 Pro was released on October 23, 2026.

Who created Kimi K3.1 Pro?

Kimi K3.1 Pro was created by Kimi.

How intelligent is Kimi K3.1 Pro?

Kimi K3.1 Pro scores 55 on the Artificial Analysis Intelligence Index, placing it well above average among other models in a similar price tier (median: 27).

How fast is Kimi K3.1 Pro?

Kimi K3.1 Pro generates output at 77.1 tokens per second (based on Kimi's API), which is below average compared to other models in a similar price tier (median: 79.4 t/s).

What is the latency of Kimi K3.1 Pro?

Kimi K3.1 Pro has a time to first token (TTFT) of 2.89s (based on Kimi's API), which is better than average compared to other models in a similar price tier (median: 3.65s).

How much does Kimi K3.1 Pro cost?

Kimi K3.1 Pro costs $2.00 per 1M input tokens (better than average, median: $2.00) and $10.00 per 1M output tokens (better than average, median: $10.00), based on Kimi's API.

What is Kimi K3.1 Pro API pricing?

Kimi K3.1 Pro costs $2.00 per 1M input tokens and $10.00 per 1M output tokens (based on Kimi's API). For a blended rate (7:2:1 cache hit/input/output ratio), this is $1.54 per 1M tokens. Pricing may vary by provider. Compare provider pricing

How verbose is Kimi K3.1 Pro?

When evaluated on the Intelligence Index, Kimi K3.1 Pro generated 150M output tokens, which is at the higher end compared to other models in a similar price tier (median: 87M).

Is Kimi K3.1 Pro a reasoning model?

Yes, Kimi K3.1 Pro is a reasoning model. It uses extended thinking or chain-of-thought reasoning to work through complex problems before providing an answer.

What input modalities does Kimi K3.1 Pro support?

Kimi K3.1 Pro supports text and image input.

What output modalities does Kimi K3.1 Pro support?

Kimi K3.1 Pro supports text output.

Can Kimi K3.1 Pro process images?

Yes, Kimi K3.1 Pro supports image input and can analyze, describe, and answer questions about images.

Is Kimi K3.1 Pro multimodal?

Yes, Kimi K3.1 Pro is multimodal. It can process text and image input and generate text output.

What is the context window of Kimi K3.1 Pro?

Kimi K3.1 Pro has a context window of 1.0M tokens. This determines how much text and conversation history the model can process in a single request.

Is Kimi K3.1 Pro open source?

No, Kimi K3.1 Pro is proprietary. The model weights are not publicly available.

How many parameters does Kimi K3.1 Pro have?

Kimi K3.1 Pro has 2.8 trillion parameters.

How does Kimi K3.1 Pro perform on benchmarks?

Kimi K3.1 Pro achieves a score of 55 on the Artificial Analysis Intelligence Index. This composite benchmark evaluates models across reasoning, knowledge, mathematics, and coding.

Is Kimi K3.1 Pro available via API?

Yes, Kimi K3.1 Pro is available via API through 2 providers. Compare API providers

Where can I use Kimi K3.1 Pro?

Kimi K3.1 Pro is available through 2 API providers. Compare providers