Marco Orta — Blog

Meta Banned General-Purpose AI Chatbots on WhatsApp: What It Means for Your Business (and What It Doesn't)

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

Since January 15, 2026, you can no longer talk to ChatGPT, Copilot or Perplexity on WhatsApp from most of the world. A lot of people read that as “Meta banned AI bots”, and articles are circulating that warn businesses their numbers will be suspended for using AI. That isn’t what happened. Meta’s rule targets companies that offer a general-purpose AI assistant as the product, not businesses that use AI to serve their own customers. That is still allowed, and Meta’s own documentation says so.

What does change for a business are three other things, none of them about the ban. From October 1, Meta charges for customer-service replies, AI replies included, beyond 1,000 a month. Meta now sells its own AI agent for businesses. And the terms are being reorganized on September 23. Each one is below with its source. One caveat up front: in the European Economic Area and Brazil, regulators forced Meta to carve out an exception, so the ban applies everywhere else, including Mexico, the US and the rest of Latin America.

What the rule says, word for word

The clause is in the WhatsApp Business Solution Terms (last modified March 6, 2026), under “AI Providers”:

Providers and developers of artificial intelligence or machine learning technologies, including but not limited to large language models, generative artificial intelligence platforms, general-purpose artificial intelligence assistants, or similar technologies as determined by Meta in its sole discretion (“AI Providers”), are strictly prohibited from accessing or using the WhatsApp Business Solution, whether directly or indirectly, for the purposes of providing, delivering, offering, selling, or otherwise making available such technologies when such technologies are the primary (rather than incidental or ancillary) functionality being made available for use.

And two sentences later comes the one that matters to a business:

Notwithstanding the foregoing, you may retain an AI Provider as your Third Party Service Provider in accordance with these WhatsApp Business Solution Terms.

In other words: OpenAI can’t use WhatsApp to offer you ChatGPT. Your business can hire OpenAI (or anyone else) so its model answers your customers about your business. Meta’s pricing documentation is blunt about it: service messages “can be powered by a person, like a customer service representative, or by a 3rd-party AI solution.” And the European Commission, when it opened its investigation, put it the same way: businesses may still use AI tools “for ancillary or support functions, such as automated customer support offered via WhatsApp.”

The rule applied to new providers from October 15, 2025 and to existing ones from January 15, 2026, according to the European Commission.

Who left WhatsApp (and who came back)

Assistant	What happened
ChatGPT	It had more than 50 million users on WhatsApp. It left on January 15; OpenAI asked people to link their accounts because conversations wouldn’t transfer (OpenAI). It came back on July 13, for European numbers only (release notes)
Microsoft Copilot	Left on January 15, without keeping chat history
Perplexity	Announced it was shutting down its WhatsApp number
Luzia	Big in Spain and Latin America. Moved users to its own app, and on June 30 launched a new WhatsApp assistant on a Spanish number, which fits the European exception
Meta AI	Stays. Since January 15 it has been the only AI assistant available inside WhatsApp, according to the European Commission

Why ChatGPT is back in Europe and Brazil

Because regulators there made Meta back down, and the current version of the clause now includes the exception: general-purpose AI may be offered to users whose numbers have a European Economic Area or Brazil country code.

Date	What happened
Dec 24, 2025	Italy’s competition authority (AGCM) orders the terms suspended in Italy (AGCM)
Jan 12, 2026	Brazil’s CADE opens an inquiry and suspends the terms as a preventive measure (CADE)
Feb 9, 2026	The European Commission, investigating since December 4, sends its Statement of Objections
Mar 4, 2026	Meta lets rivals back in within Europe, but charges them per message
Apr 23, 2026	CADE upholds a daily fine of 250,000 reais because Meta was charging chatbots (CADE)
Jun 9, 2026	The European Commission orders free access restored within five working days (Commission); Meta says it will appeal

Outside those two regions nothing comparable has happened. In Mexico, the new National Antitrust Commission, which replaced COFECE in October 2025, hasn’t published any investigation of these terms.

What your business can still do with AI on WhatsApp

Everything that is serving your customers about your business: answering hours and prices, recommending products from your catalogue, booking appointments, taking orders, sending a payment link, following up. With three conditions that come from Meta’s own documents:

There has to be a way to reach a person. The WhatsApp Business Messaging Policy allows automated replies but requires “prompt, clear, and direct escalation paths”: a human agent in the chat, a phone number, an email, a support form or a store visit. A bot that never lets anyone talk to a human breaks the policy, even though that has nothing to do with the AI clause.
Conversations can’t be used to train other people’s models. The terms forbid using your customers’ data to create or improve AI systems, except a model fine-tuned for your exclusive use. Ask your vendor whether it trains on your data: OpenAI, for instance, says that on its API it does not train on it by default.
The bot talks about your business. The grey zone is a number whose main offering is “ask me anything”, even if a shop runs it. Meta hasn’t published where “primary” ends and “ancillary” begins, and it reserves the call to its “sole discretion”. A bot that answers about your store is clearly on the allowed side; a ChatGPT with your logo that also helps with homework is not.

A note on what’s circulating: I found no documented case of a business number being suspended under this clause. The articles that talk about “mass suspensions” don’t cite any.

And if what you want is more customers messaging you, that doesn’t depend on AI: a QR code that opens your chat with a message already typed, on the counter or the receipt, works from day one.

What does change for you (and has nothing to do with the ban)

1. From October 1, service replies are billed

According to Meta’s pricing page, from October 1, 2026 service messages (your replies when the customer writes first) are charged at the same rate as utility messages, with 1,000 free per phone number per month, not rolled over. AI replies are service messages, so they count exactly like a person’s. And if your account has no payment method on file by September 30, Meta stops delivering your replies from the 1,001st of the month. The technical detail, including what changes in the webhook, is in what changes in your code on October 1.

2. Meta now sells its own AI agent

On June 3 Meta announced Meta Business Agent, and it promises a lot: answering questions about your business, recommending products from your catalogue, booking appointments, qualifying leads and closing sales. Getting started is free, but Meta has said access will move to paid subscriptions. On the API it has been billed since August 1 at $2 per million tokens, which Meta estimates at about 4 to 5 US cents per message. And on September 15 it introduced Meta One, with a plan starting at $14.99 a month that includes more use of the agent; pricing and availability vary by region.

The question isn’t whether it’s good, but whether you want your customer service to depend on the rules and prices of the same company that owns the channel, which is exactly what regulators in Europe are investigating.

3. The terms are being reorganized on September 23

That day WhatsApp splits its terms into two documents, one for the WhatsApp Business app and one for the platform (the API). Its help center describes it as a reorganization, but the new text isn’t published yet. I’ll check it when it is and update this post if the AI clause changes.

Meta’s agent, or one connected to your business?

It depends on what you need it to do:

	Meta’s agent	Your own agent on the API
Setup	From the app, in minutes	Days or weeks
Where its answers come from	Your catalogue and what you configure in Meta	Your systems: inventory, calendar, payments
Which model	Meta’s	The one you choose, with a no-training guarantee
What you pay	Meta’s tokens or subscription, plus messages	Meta’s messages plus the model you use
Rules and prices	Meta decides	Messages: Meta. Everything else: you

For a business that sells what’s in its catalogue and answers repeated questions, Meta’s agent may be enough. When the answer depends on something that lives outside Meta (whether it’s in stock today, whether the doctor has a free slot, what shipping costs to your neighbourhood), you need one connected to your own systems. That’s how the AI automation I build for businesses works, and I covered the technical side in building an AI WhatsApp agent for small businesses with Laravel and OpenAI.

Five questions to ask your bot vendor

Does my number use the official WhatsApp API or an unofficial app? (Unofficial ones can be blocked by Meta even without AI.)
Does the bot answer only about my business, or anything at all?
How does a conversation get handed to a person, and how fast?
Are my conversations used to train any model?
Does my Meta account have a payment method before September 30, and who pays for messages beyond 1,000 a month?

If any answer is “I don’t know”, that’s the one to fix first.

Frequently asked questions

Did Meta ban AI chatbots on WhatsApp?

It banned AI providers from offering general-purpose assistants (like ChatGPT, Copilot or Perplexity) through the WhatsApp Business API when AI is the primary functionality of the service. It applies from January 15, 2026 for existing providers and from October 15, 2025 for new ones. It did not ban businesses from using AI to serve their own customers.

Can my business use an AI chatbot on WhatsApp in 2026?

Yes. WhatsApp's terms let a business retain an AI provider as its third-party service provider, and Meta's pricing documentation says service messages can be powered by a person or by a third-party AI solution. The conditions: a clear way to reach a person, conversations not used to train other companies' models, and a bot that serves customers about your business.

Why does ChatGPT work on WhatsApp in Europe but not in Mexico or the US?

Because Italy's competition authority, the European Commission and Brazil's CADE ordered Meta to suspend the restriction, and the current terms (dated March 6, 2026) allow general-purpose AI for numbers with a European Economic Area or Brazil country code. ChatGPT returned to WhatsApp in Europe on July 13, 2026. Everywhere else the restriction still applies.

Can my WhatsApp number be suspended for using AI?

Meta can close accounts that break its terms, and it decides at its sole discretion where AI stops being ancillary and becomes the primary functionality. A bot that serves customers about your business is on the allowed side; a number whose main offering is a general question-answering assistant is at risk. There are no documented public cases of business numbers suspended under this clause.

How much does Meta's AI agent for businesses cost?

Meta Business Agent was announced on June 3, 2026 and getting started is free, but Meta has said access will move to subscriptions. On the API it has been billed since August 1, 2026 at $2 per million tokens, about 4 to 5 US cents per message according to Meta. The Meta One plan introduced on September 15 starts at $14.99 a month and includes more use of the agent; price and availability vary by region.

Are AI chatbot replies on WhatsApp billed?

From October 1, 2026, yes, like any service message: Meta gives 1,000 free per phone number per month and charges the rest at each country's utility rate. It makes no difference whether a person or an AI replies. If the account has no payment method, Meta stops delivering replies from the 1,001st of the month.

Why Online Stores Crash During Mexico's Buen Fin (and How to Prevent It): The 2026 Technical Guide

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

El Buen Fin, Mexico’s answer to Black Friday, runs from Friday November 13 to Tuesday November 17, 2026. Almost everything published about getting a store ready for it is about banners, coupons and email. This guide is the other half: what breaks technically when the visitors you paid to attract all show up at once, and what to do beforehand. Nearly all of it is written down in your host’s, your payment gateway’s and your platform’s documentation, and almost nobody reads it until the store is already down.

Last year’s numbers show why it matters. According to Mexico’s Ministry of Economy, the 2025 edition sold 219.2 billion pesos, and digital commerce was 21% of the total, growing 31% year over year. The public AMVO report (Mexico’s online sales association) counted 1.686 billion page views on e-commerce sites and traffic 56% higher than the previous edition (which went from four days to five). The retailers’ association ANTAD reports that the last day alone took 26.1% of online sales. The peak doesn’t spread out: it arrives, and it arrives all at once.

If you sell into Mexico from abroad, or build stores for Mexican clients, the local details are what catch people out: the cash-at-OXXO payment method, the Mexican shared-hosting plans small businesses actually run on, and a gateway landscape where Mercado Pago matters as much as Stripe. I’ve built WooCommerce stores with catalogues in the thousands, Mercado Pago payments and WhatsApp checkout. This is what I check on each one before a date like this, with a source for every limit.

What those five days look like

Buen Fin 2025	Figure	Source
Total sales	219.2 billion pesos	Ministry of Economy
Online sales	21% of the total, +31% YoY (45.9 billion per AMVO)	Economy / AMVO
Traffic to online stores	+56% over the 5 days, +24% on comparable days	AMVO (Similarweb data)
Average ticket	$1,063 MXN online vs $780 overall	Mexican Banking Association, cited by Economy
How people paid online	Credit 48%, debit 43%, store cards 17%, card-free instalments 12%, cash at retail chains 12%	AMVO
Consumer agency complaints	220 filed, 205 settled; mostly unhonoured prices and refused delivery	Profeco

Two rows matter for the technical side. One in eight online buyers paid cash at a retail chain (OXXO and similar), which has a consequence for your inventory that I explain below. And 37% of consumers, per the AIMX survey the ministry cites, fear a data leak: an expired-certificate warning or a checkout page that looks off on your busiest day costs sales even if the site stays up.

Not everything that fails is yours, either. During Buen Fin 2024, Santander and BBVA customers reported card payment failures; during Hot Sale in May 2026 BBVA confirmed on X that its systems were down, with over five hours of Downdetector reports. And on November 18, 2025, the day after Buen Fin ended, Cloudflare had a global outage of more than three hours. You can’t stop your customer’s bank from going down. You can have a second payment method ready when it does.

1. Shared hosting has a ceiling, and it’s in writing

The shared hosting plan that costs a few hundred pesos a year isn’t “slow”: it has exact limits, and when you hit them it doesn’t slow down, it returns errors. Hostinger publishes its limits on its plan parameters page and says reaching them produces “503 – Service temporarily unavailable”:

Hostinger plan	CPU	RAM	Concurrent PHP workers	MySQL connections
Web Single	1	1 GB	20	25
Web Premium	1	2 GB	40	50
Unlimited (formerly Business)	2	3 GB	60	75

HostGator Mexico puts it differently in its help centre: a cap of 25% CPU sustained for 90 seconds or more, and 25 concurrent processes per cPanel account.

Do the maths with your own store. An uncached WooCommerce product page holds a PHP worker while it renders. If it takes one second and you have 20 workers, your ceiling is about 20 pages per second; visitor number 21 doesn’t wait in line, they get an error. That’s why caching, next, isn’t an optimization: it decides whether those limits ever reach you.

2. Caching: what can be cached and what can’t

The idea is simple: most visitors, the ones just browsing, should get a prebuilt copy of the page and cost your server nothing. Only the cart, checkout and account pages need to reach the server every time.

What almost nobody knows is that Cloudflare doesn’t cache HTML by default, on free or paid plans. Its documentation is explicit: “The Cloudflare CDN does not cache HTML or JSON by default.” If you put your store behind Cloudflare and configured nothing else, images, CSS and JavaScript are cached, but every page still hits your host. The free plan gives you up to 10 Cache Rules and one is enough. This expression is for a Spanish-language WooCommerce store (adjust the paths to yours):

(http.host eq "tutienda.mx"
 and not starts_with(http.request.uri.path, "/wp-admin")
 and not http.request.uri.path contains "/carrito"
 and not http.request.uri.path contains "/finalizar-compra"
 and not http.request.uri.path contains "/mi-cuenta"
 and not http.cookie contains "woocommerce_items_in_cart"
 and not http.cookie contains "wordpress_logged_in")

With the “Eligible for cache” action and a short edge TTL (5 to 10 minutes), browsers get the cached copy, and anyone with something in the cart or a logged-in session goes straight to your server. Two warnings:

Purge the cache when prices change. If your discounts start at midnight on the 13th, a copy cached at 11:58 pm still shows the old price, and “the price wasn’t the advertised one” is among the complaints Profeco receives most. Purge when you switch the offers on.
A cookie on every page breaks everything. Cloudflare won’t cache a response carrying Set-Cookie, and some plugins (currency switchers, geolocation, popups) send one on every visit. Check it like this:

curl -sI https://tutienda.mx/producto/tu-mas-vendido/ | grep -iE "set-cookie|cf-cache-status"

What you want to see, from the second request on, is cf-cache-status: HIT and no set-cookie. If you see DYNAMIC or BYPASS, that page is still hitting your server.

Two things look like safety nets and aren’t. Always Online is on every plan, but it only kicks in on 52x errors, serves Internet Archive snapshots and can’t serve dynamic content: nobody checks out from an archived copy. And Cloudflare’s Waiting Room, the virtual queue big retailers use, only exists on Business and Enterprise plans.

On WooCommerce, also check cart fragments: the script that updates the cart counter by calling the server on every page. WooCommerce acknowledges that on heavily trafficked stores “this could severely impact the load on the server”, and since version 7.8 it no longer loads on every page, but plenty of themes and plugins turn it back on. Open a product page with your browser’s dev tools and look for a request to ?wc-ajax=get_refreshed_fragments. If it fires on pages without a mini cart, that’s one server request per visit that caching can’t remove.

And slim down your product photos: they’re most of a store’s page weight, and on mobile, where most Mexican shoppers buy, every megabyte shows.

3. Your payment gateway has a limit too

The server isn’t the only thing that can say no. Stripe publishes its rate limits: 100 requests per second in live mode, with most individual endpoints capped at 25. And it says plainly that “a sudden increase in charge volume, such as a flash sale, might result in rate limiting”; if you expect a spike, it asks you to contact support beforehand. Mercado Pago doesn’t publish a number, but its Orders API answers 429 Too Many Requests with a Retry-After header when you exceed it.

For a small business, 100 charges a second is plenty. The problem shows up when the integration makes several calls per purchase (create customer, create payment intent, poll status) or retries without backing off: a badly handled 429 becomes “we couldn’t process your payment” for a customer who had the funds.

Bank verification (3-D Secure, the “confirm in your app” screen) changes the flow too. Mexico has no regulatory mandate for it, but Mercado Pago recommends enabling it in optional mode, and when the bank asks for a challenge the payment sits in pending with detail pending_challenge. If your integration treats “pending” as “declined”, you’re cancelling good orders. AMVO lists “payment method rejected” among the barriers to buying online.

4. The problem nobody mentions: cash at OXXO locks your inventory

This is what worries me most for a store with limited stock, and I didn’t see it in any Buen Fin guide I read. When a customer chooses to pay cash, the gateway issues a voucher with an expiry date, and until they pay, the item is in limbo:

Gateway	Voucher validity	If they pay late
Stripe (OXXO)	5 days by default, configurable from 1 to 7; confirmation arrives the next business day	The voucher expires (docs)
Mercado Pago (OXXO, Paycash)	Configurable from 1 to 30 days; they recommend 3. Crediting takes up to 2 business hours	“The amount will be refunded” (docs)
Conekta	Set by your integration with `expires_at`; signalled by the `order.expired` webhook	Up to your integration (docs)

Now the WooCommerce side. Its “Hold stock” setting reserves items for orders pending payment for as long as you configure (60 minutes is the recommended value) and then cancels them, according to its guide. But the same guide says delayed payment methods leave the order on hold, where that automatic cancellation doesn’t apply. If your gateway plugin doesn’t cancel the order when the voucher expires, the item stays reserved for days by someone who may never pay, while you tell the customer holding a card that it’s sold out.

Before the 13th:

Shorten voucher validity for the campaign. One or two days instead of five or thirty.
Check that your plugin cancels the order on expiry. Place a test cash order with the minimum validity, don’t pay it, and check the next day that the order was cancelled and the stock came back.
If you sell over WhatsApp with payment links, give them a short expiry. Clip, for example, lets a link expire the same day.

5. Overselling: two people buy the last unit

Since version 4.3, WooCommerce reserves stock during checkout to stop two simultaneous purchases taking the same unit (PR #26395). Even so, issue #44273, where the team confirms that “a race condition like this is possible”, is still open today. On a normal day it almost never happens. During Buen Fin, with hundreds of people on your best seller, is when it does.

For low-stock products: keep a buffer (list 18 if you have 20), cap quantity per customer, and decide in advance what you’ll do if it happens, with an apology and a fast refund. Refused delivery was among the complaints that dominated Profeco’s 2025 figures. Shopify’s flash sale guide recommends switching to manual payment capture for the same reason: charge only for what you can actually ship.

6. What runs in the background

Order confirmation emails, payment webhooks and stock updates in WooCommerce go through Action Scheduler, which by default processes batches of 25 actions for 30 seconds, triggered by WP-Cron. And WP-Cron only runs when someone visits the site. With caching done right, hardly anyone reaches the server, and tasks can pile up. The result: customers who paid and don’t get their confirmation, and message you asking whether the order went through.

The fix is a real server cron instead of the visit-driven one: set DISABLE_WP_CRON in wp-config.php and schedule a call to wp-cron.php every minute from your hosting panel. Almost every shared host allows it.

7. Test it first with fake traffic

All of the above can be checked without waiting for the 13th. A load test simulates many visitors at once and shows you where errors start. Two free options:

k6, by Grafana: free on your own machine, and its free cloud tier includes 500 virtual user hours a month.
Loader.io: the free plan allows 10,000 clients per test for one minute, run from US data centres.

A minimal k6 script that visits the home page and your best seller:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 }, // ramp to 50 concurrent visitors
    { duration: '5m', target: 50 }, // hold
    { duration: '1m', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],     // under 1% errors
    http_req_duration: ['p(95)<2000'],  // 95% under 2 seconds
  },
};

export default function () {
  check(http.get('https://tutienda.mx/'), { home: (r) => r.status === 200 });
  sleep(3);
  check(http.get('https://tutienda.mx/producto/tu-mas-vendido/'), { product: (r) => r.status === 200 });
  sleep(5);
}

Run it with k6 run test.js. Three rules: test pages, never your payment gateway; on shared hosting, tell your provider first, because a load test looks a lot like an attack; and aim at three to five times your normal peak hour. There’s no public figure for how much a small store’s traffic rises during Buen Fin compared with an ordinary day; if your analytics kept last year’s, use that. If the test fails at 50 visitors, you know what to fix, and you have seven weeks to do it.

If your store runs on Shopify or Tiendanube

Infrastructure isn’t your problem: Shopify handled 489 million requests per minute at its edge over Black Friday and Cyber Monday 2025, and its guide says special preparation is only needed if you expect “tens of thousands of customers” starting checkout within minutes. Yours are the other sections: theme weight and the apps you load on every page, the gateway and its pending states, cash voucher validity, and your stock buffer.

The two-weeks-before checklist

What	How you verify it
HTML caching on for browsers	`cf-cache-status: HIT` on the second request to a product page
No page sends `Set-Cookie` to visitors	The same `curl -sI` as above
Cart, checkout and account excluded from cache	Add something to the cart in another window and check the counter updates
New prices visible	Purge the cache when offers go live and check in a private window
Short cash-voucher validity	Test OXXO order you don’t pay: on expiry, order cancelled and stock back
“Pending” payments treated as pending	Test purchase with 3-D Secure that you don’t complete
Real server cron	`DISABLE_WP_CRON` in `wp-config.php` and a task every minute
Buffer on best sellers	Listed stock below real stock
SSL certificate valid past November 17	SSL lookup
Load test passed	k6 or Loader.io with no errors at three times your peak
Plan B for payments	Payment link and WhatsApp ready in case the gateway or the bank fails

If you need a store or site in Mexico built to survive a date like this, that’s what I do.

Frequently asked questions

When is Buen Fin 2026?

From Friday November 13 to Tuesday November 17, 2026. It is the 16th edition and runs five days because it includes Monday November 16, the observed Revolution Day holiday. Business registration is free at elbuenfin.org, from September 8 to November 12.

Why do online stores crash during Buen Fin?

Usually because every visit reaches the server uncached and the host runs out of the processes it allows. Shared plans have fixed limits (20 PHP workers on Hostinger's entry plan, 25 processes per cPanel account on HostGator Mexico) and return a 503 error past them. The payment gateway can also fail when it rate-limits, or the customer's bank, which is out of your hands.

Does Cloudflare's free plan protect a store from Buen Fin traffic?

It helps, but not just by switching it on. Cloudflare does not cache HTML by default, so without a Cache Rule every page still hits your host. The free plan allows up to 10 rules, and one is enough to cache pages for browsers while excluding cart, checkout and account. The virtual queue (Waiting Room) only exists on Business and Enterprise plans.

Does a pending OXXO payment lock my inventory?

It can, for days. Stripe OXXO vouchers expire after 5 days by default (configurable from 1 to 7) and Mercado Pago's after 1 to 30. In WooCommerce, delayed-payment orders go on hold and the 60-minute hold-stock setting only cancels orders pending payment, so the item stays reserved until the gateway plugin cancels the order when the voucher expires. Shorten validity for the campaign and test it with an order you do not pay.

How do I load test an online store?

With k6, free and open source, or Loader.io, whose free plan runs up to 10,000 clients in a one-minute test. Simulate visitors on the home page and best sellers, never on the payment gateway, aim at three to five times your peak hour, and warn your shared hosting provider first, because a load test looks like an attack.

Laravel Octane + FrankenPHP: What Actually Breaks (I Reproduced Every Leak)

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

Octane keeps your Laravel application in memory between requests. That is where the speed comes from, and it is where everything that breaks comes from. Almost every “Octane gotchas” article repeats the same warning: a singleton that receives the request in its constructor captures the first request forever. I built a Laravel 13 app on Octane with FrankenPHP in Docker and reproduced each failure with curl, and that warning is wrong as usually stated. The leaks that do happen come from somewhere else.

Three results surprised me. A request-capturing singleton resolved during a request does not leak, because Octane handles every request on a clone of the application. --max-requests=0, which means “unlimited” on Swoole and RoadRunner, stops FrankenPHP from starting at all. And the features the docs mark as Swoole-only don’t throw on FrankenPHP: most of them silently do something else. Everything below comes with the command and the output.

If you haven’t decided whether Octane is worth it for your app, start with the Laravel performance guide; this post is for the step after “let’s turn it on”.

The lab

Component	Version
Laravel	13.32.0 (skeleton requires PHP ^8.3)
laravel/octane	2.19.1
FrankenPHP	1.12.7, PHP 8.5.10 ZTS, Caddy 2.11.4
Image	`dunglas/frankenphp:latest` (Debian 13) + `pcntl` + Composer
Load tool	`wrk`, pinned to separate CPUs

A fresh skeleton, nine small classes and a route file. Octane runs with php artisan octane:frankenphp; the comparison mode is FrankenPHP’s classic php-server, which boots Laravel on every request the way PHP-FPM does.

Before it even starts: pcntl, zip and the musl binary

Three things got in the way before the first request:

The official FrankenPHP image has no pcntl. Without it, octane:frankenphp dies immediately:
```
Error  Undefined constant "Laravel\Octane\Commands\Concerns\SIGINT"
at vendor/laravel/octane/src/Commands/Concerns/InteractsWithServers.php:174
```
The Dockerfile in the Octane docs runs install-php-extensions pcntl for exactly this reason. Copy that line.
It has no zip or unzip either, so composer require fails inside it. Install dependencies in a Composer stage and copy vendor/ over.
On Alpine, octane:install downloads the musl binary. When there’s no frankenphp on the PATH, Octane downloads one, and it picks the glibc build only if getconf GNU_LIBC_VERSION succeeds. On Alpine it doesn’t, so you get the 173 MB musl build. FrankenPHP’s own performance guide says to “avoid musl in production” because PHP is slower on it, especially in ZTS mode. On my trivial benchmark route I couldn’t measure a difference (5,900 req/s against 5,800-6,100 on glibc), but the known-issues page lists concrete gaps, such as GLOB_BRACE not being available. Prefer the Debian images.

1. Singletons: the leak everyone describes isn’t the one that bites

The binding every article uses as its example:

// AppServiceProvider::register()
$this->app->singleton(RequestEcho::class,
    fn (Application $app) => new RequestEcho($app['request']));

Resolved inside a route, with one worker so every request hits the same one:

?user=alice → {"query_user":"alice","singleton_sees":"alice"}
?user=bob   → {"query_user":"bob","singleton_sees":"bob"}
?user=carol → {"query_user":"carol","singleton_sees":"carol"}

No leak. The reason is in Octane’s Worker::handle(): every request runs on $sandbox = clone $this->app, and a singleton resolved on that clone dies with it at the end of the request. The famous warning is true only in two situations, and they’re what you should be looking for.

The singleton is resolved during boot. The Octane docs phrase it precisely: the problem is when the instance “is resolved during the application boot process”. I resolved the same class in boot(), as an eager package would:

?user=alice → {"query_user":"alice","singleton_sees":null,"singleton_url":"http://localhost:8000"}

It doesn’t capture the first request. It captures the fake console request that Laravel binds while booting (URL = APP_URL, no input), and keeps it for every request.

Something resolves it through the base application. This is the one that really captures the first request. A listener registered in boot() that resolves lazily through $this->app, which is the original application Octane clones, not the clone:

// AppServiceProvider::boot(). Nothing is resolved here yet.
Event::listen('lab.who',
    fn () => $this->app->make(RequestEchoViaProvider::class)->user());

?user=alice → "alice"
?user=bob   → "alice"
?user=carol → "alice"

The first request resolved the singleton on the base app, and it stayed there for the life of the worker. Adding the class to flush in config/octane.php fixed it (alice, bob, carol).

The same mechanism turns stateful singletons into a data leak between users. A CurrentTenant singleton that lives on the base app (because something resolved it at boot), with a middleware that sets it only when the request carries X-Tenant:

-H 'X-Tenant: acme' → {"singleton_tenant":"acme","scoped_tenant":"acme"}
(no header)         → {"x_tenant_header":null,"singleton_tenant":"acme","scoped_tenant":null}

The anonymous request inherited acme. With four workers it’s worse to debug: only the worker that served acme leaked, so one request in four came back wrong. The same class registered with scoped() instead of singleton() returned null on every request without the header.

What to do:

Use scoped() for anything that holds per-request state (tenant, current user, locale).
Don’t resolve request-dependent services in boot(), and look for listeners and macros registered in boot() that call $this->app->make().
For anything you can’t change (a package), add it to flush in config/octane.php.
For services that need the request or config, inject a resolver, fn () => Container::getInstance(), instead of the object.

2. Static state grows until the worker restarts

A static array that gets 10 KB per request, which is what a naive in-memory cache or a registry of “already processed” items does:

req#1    worker dcb87b  items 1    mem_kb 5667
req#100                 items 100  mem_kb 7001
req#300                 items 300  mem_kb 9410
req#500                 items 500  mem_kb 11810
req#501  worker c5125d  items 1    mem_kb 1253   ← restart at --max-requests=500

About 12 KB per request, reset only when Octane restarts the worker after 500 requests, which is the default. The restart doesn’t appear in the logs, and it costs little: 1.85 ms before, 4.40 ms on the first request of the new worker, 2.19 ms after.

A trap when you test this yourself: my first version used str_repeat('x', 10240) and memory stayed flat over 500 requests. OPcache folds that constant expression into a single interned string, so every array item pointed at the same memory. With Str::random() the leak showed. If your leak test comes back clean, check that the data is actually different on each request.

3. `--max-requests=0` doesn’t mean “unlimited” on FrankenPHP

On OpenSwoole, max_request 0 means no limit, and on RoadRunner “zero (or nothing) means no limit” for max_jobs. On FrankenPHP:

php artisan octane:frankenphp --max-requests=0

Error: loading initial config: … frankenphp app module: start: failed to initialize workers:
too many consecutive failures: worker public/frankenphp-worker.php has not reached frankenphp_handle_request().

The container exits with code 1. Octane’s worker script loops while ($requestCount < $maxRequests …), so with 0 it never serves a request; FrankenPHP sees six consecutive workers fail to reach frankenphp_handle_request() and gives up. Through octane:start --server=frankenphp --max-requests=0 the server does start, but the worker gets MAX_REQUESTS=500: a ?: in the command replaces the 0 with the config default without telling you. The two pull requests that would have made 0 mean unlimited were closed without merging.

If you want effectively unlimited, pass a large number (--max-requests=1000000 measured the same throughput as 500). But the restarts are what protect you from section 2, so I’d keep the default.

4. Config injected into a singleton goes stale, and can poison the worker

A singleton that receives the config repository in its constructor, and a request that changes a value at runtime (per-tenant config, say):

?set=changed-in-request → {"config_helper":"changed-in-request","injected_repo":"original",
                           "resolver_closure":"changed-in-request"}

The injected repository is the base app’s, so within the request it doesn’t see the change. The worse case is the reverse: a request that writes through that injected repository ($service->config->set(...)) changes the base app’s config, and from then on every later request on that worker reads mutated-via-service. In classic mode none of this survives the request. The fix is the one the docs give: inject a resolver closure, or call config() when you need the value.

5. What FrankenPHP adds: threads, `$_ENV` and `exit()`

Threads, not processes. Four workers all reported the same PID, and /proc showed a single frankenphp process with 67 threads. FrankenPHP’s docs say so (“threads instead of processes”), and it matters for two reasons: extensions that aren’t thread-safe can’t be used (the known-issues page lists imap, newrelic and pcov, and warns that imagick in the Docker images can crash because of its OpenMP threads), and a crash in any thread takes down the whole process, every worker included.

$_ENV and putenv() survive between requests. FrankenPHP resets $_GET, $_POST, $_SERVER and the rest, but its worker docs say “$_ENV is currently not reset between requests”. I tested it with putenv():

?v=secret-from-alice → {"prev_getenv":null}
(next request)       → {"prev_$_ENV":"secret-from-alice","prev_$_SERVER":null,
                        "prev_getenv":"secret-from-alice"}

With four workers, only the thread that set it saw the value. If any code writes request data into the environment (some SDKs set credentials that way), it leaks to whoever that thread serves next.

exit() returns 200. exit(0) and exit(1) both sent the output so far with HTTP 200 and rebooted the worker. Twelve exit(1) in a row: twelve 200s, and the server survived. dd() returned 500 and also rebooted. A health check that only looks at the status code won’t see a script that dies halfway.

The 30-second limit is per request. Octane sets max_execution_time to 30 seconds. Two 20-second requests in a row on the same worker both returned 200; a 35-second one returned 500 after 31.2 s with “Maximum execution time of 30 seconds exceeded” in the log, and the worker rebooted.

Open issues worth knowing before you deploy (from php/frankenphp, still open in September 2026):

#2588: Octane worker segfault (exit 139). The reporter fixed it by switching opcache.jit from tracing to function, pointing at a tracing-JIT regression in PHP 8.5.5 and later.
#1074: concurrent file uploads hang over HTTPS; the maintainer reproduced it in July with 30 multipart uploads over one HTTP/2 connection.
#2388: the Alpine image segfaults with hundreds of environment variables (Kubernetes service links are the usual source).

And update Octane: before 2.18.0, a multipart/form-data POST without a boundary killed the request. With the old worker script I got a silent 500 with nothing in laravel.log; on 2.19.1 it’s handled normally.

6. The Swoole-only features fail silently

The docs mark concurrent tasks, ticks, the Octane cache and tables as Swoole features. What they do on FrankenPHP:

Feature	On FrankenPHP
`Octane::concurrently()`	Runs the tasks one after another: two 300 ms tasks took 600 ms
`Cache::store('octane')`	Works, but it’s a separate cache per worker: a value written on one of four workers was missing on the other three
`Octane::tick()`	Registers without error and never fires
`Octane::table()`	Throws “Tables may only be accessed when using the Swoole server.”

Only the last one tells you. If you’re moving from Swoole to FrankenPHP, grep for the first three: the code will keep running, just not doing what it did.

7. Packages: mostly fine in 2026

Octane ships its own reset listeners for Livewire, Inertia, Scout and Socialite. Current versions of the usual suspects handle it themselves: Filament resets its component managers on each request, Telescope listens to Octane’s request events, Debugbar 4 “works out of the box with Octane” (if you’re coming from 3.x, remove its entry from flush in config/octane.php), and Inertia 3 fixed its dev tools under Octane. The one to configure is spatie/laravel-permission: its Octane reset listener is off by default, and its docs say to turn it on if cached permissions look stale or cross between requests.

Is it worth it? The numbers

A laptop micro-benchmark, not a production claim: a route that returns a small JSON body, APP_ENV=production, the server pinned to 4 CPUs (8 workers) and wrk on separate CPUs, 20 seconds per run.

Mode	Connections	Requests/s	Median latency
Octane (FrankenPHP worker)	16	~6,000	2.5 ms
FrankenPHP classic, with `optimize`	16	~2,900	5 ms
FrankenPHP classic, without config/route cache	16	1,345	11 ms
Octane	64	~5,150	12 ms
FrankenPHP classic, with `optimize`	64	~2,490	24 ms
`php artisan serve`	64	~315	204 ms

Octane doubled throughput against a properly cached classic setup, and gave 4.5 times more against one without php artisan optimize. The honest comparison is the first: if your production doesn’t cache config and routes, fix that before reaching for Octane. And on a real app the gain depends on how heavy your boot is compared to your I/O; a route that waits 200 ms on the database gains little from saving 3 ms of boot.

The checklist before you switch

# Services that hold state or receive request/config in the constructor
grep -rnE "singleton\(|->instance\(" app/Providers/
grep -rnE "__construct\([^)]*(Request|Repository|Container)" app/

# Static properties that accumulate
grep -rnE "static (array|\\\$)" app/ | grep -v "function"

# Resolution through the base app from boot()
grep -rnE "\\\$this->app->(make|get)\(" app/Providers/

# Things FrankenPHP treats differently
grep -rnE "putenv\(|\\\$_ENV\[|\bexit\(|\bdie\(" app/ routes/

# Swoole-only APIs that degrade silently
grep -rnE "Octane::(concurrently|tick|table)|store\('octane'\)" app/

Then, in order: install pcntl in the image, use a Debian-based image, run your test suite, load-test the Octane server with at least four workers (single-worker tests hide the leaks that only happen on one worker in four), and keep --max-requests at its default. If you’re also moving to Laravel 13, what breaks upgrading to Laravel 13 covers the framework side.

Frequently asked questions

Does a singleton that receives the request leak between requests in Laravel Octane?

Not if it is resolved during a request: Octane handles each request on a clone of the application, and singletons resolved on the clone are discarded at the end. Tested on Laravel 13.32 with Octane 2.19.1 and FrankenPHP 1.12.7. It leaks when it is resolved during boot (it captures the console request Laravel binds while booting) or through the base application, for example from a listener registered in boot() that calls $this->app->make(); in that case it keeps the first request for the life of the worker. Use scoped(), add the class to flush in config/octane.php, or inject a resolver closure.

What does --max-requests=0 do with Octane and FrankenPHP?

It stops the server from starting. With php artisan octane:frankenphp --max-requests=0, the worker script never reaches frankenphp_handle_request() and FrankenPHP exits with "too many consecutive failures". With octane:start the server starts but silently uses the default of 500. On Swoole and RoadRunner, 0 means unlimited. Use a large number if you want to avoid restarts, but the default 500 is what clears memory leaks.

Which Octane features do not work with FrankenPHP?

Concurrent tasks, ticks, the Octane cache and tables are Swoole features. On FrankenPHP, Octane::concurrently() runs tasks sequentially, the octane cache store is a separate array per worker, Octane::tick() registers but never fires, and only Octane::table() throws an exception. The first three fail silently.

Why does Laravel Octane fail with Undefined constant SIGINT on FrankenPHP?

Because the official dunglas/frankenphp Docker image does not include the pcntl extension, and Octane uses its signal constants. Install it with install-php-extensions pcntl, as the Dockerfile in the Octane documentation does. The image also lacks zip and unzip, so install Composer dependencies in a separate stage.

Is $_ENV reset between requests in FrankenPHP worker mode?

No. FrankenPHP resets $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER and $_REQUEST between requests, but its documentation says $_ENV is currently not reset. In testing, a value set with putenv() in one request was visible to the next request on the same thread. Do not store request-specific or sensitive data in the environment.

How much faster is Laravel Octane with FrankenPHP?

In a laptop micro-benchmark with a minimal JSON route, Octane served about 6,000 requests per second against about 2,900 for FrankenPHP classic mode with config and route caches, roughly double, and 4.5 times more than classic mode without caches. The real gain depends on how much of each request is framework boot versus waiting on the database or other I/O.

OpenAI Shuts Down GPT-4, o1 and o3-mini on October 23: What Breaks in Your Code (It's Not Just the Model Name)

Marco Orta — Mon, 21 Sep 2026 00:00:00 GMT

On October 23, 2026 OpenAI shuts down gpt-3.5-turbo, gpt-4, gpt-4-turbo, o1, o1-pro, o3-mini, o4-mini, gpt-4.1-nano, one gpt-4o snapshot and gpt-image-1. The deprecations page makes the fix look like a string swap: put gpt-5.6-sol, -terra or -luna where the old name was. That swap is the easy part, and for a lot of code it isn’t even where the problem is.

Four things break after you change the name, and one breaks in code where the name never appears: LangChain and LlamaIndex still default to gpt-3.5-turbo, so a project that never wrote a model name is using one that dies in 32 days. Below is everything, checked against OpenAI’s docs as they were served on September 21 and against the libraries’ source code. Where a claim comes from user reports rather than from OpenAI, I say so.

If what you need is the full calendar across providers (Anthropic, Gemini, Azure) and how to tell whether a business chatbot is affected, that’s in the AI model retirements guide. This post is the code side.

What shuts down, and what OpenAI says to use instead

From the deprecations page, section “2026-04-22: Legacy GPT model snapshots”. OpenAI announced it by email on April 22; the substitute column was edited later, since it names models released in July. Prices are standard tier, per million tokens, input / output, from the pricing page:

Shuts down Oct 23	Price	Substitute	Price	Change
`gpt-3.5-turbo` (`-0125`, `-completions`)	$0.50 / $1.50	`gpt-5.6-terra`	$2 / $12	4× / 8×
`gpt-4` (`-0613`, `-completions`)	$30 / $60	`gpt-5.6-sol`	$4 / $20	cheaper
`gpt-4-turbo` (`-2024-04-09`)	$10 / $30	`gpt-5.6-sol`	$4 / $20	cheaper
`gpt-4o-2024-05-13`	$5 / $15	`gpt-5.6-sol`	$4 / $20	≈ / 1.3×
`gpt-4.1-nano`	$0.10 / $0.40	`gpt-5.6-luna`	$0.20 / $1.20	2× / 3×
`o1`	$15 / $60	`gpt-5.6-sol`	$4 / $20	cheaper
`o1-pro`	$150 / $600	`gpt-5.6-sol`, pro mode	$4 / $20 + more tokens	cheaper
`o3-mini`	$1.10 / $4.40	`gpt-5.6-sol`	$4 / $20	3.6× / 4.5×
`o4-mini`	$1.10 / $4.40	`gpt-5.6-terra`	$2 / $12	1.8× / 2.7×
`gpt-image-1`	$10 / $40 (image tokens)	`gpt-image-2`	$8 / $30	cheaper

Three details the table hides:

The gpt-4o alias is not on the list. It points to gpt-4o-2024-08-06 according to its model page, and only the May 2024 snapshot dies. gpt-4o-mini and gpt-4.1 (without -nano) aren’t on it either.
Sol’s $4 / $20 is a promotion. OpenAI says it is “available at least through November 21, 2026” and describes it as a 20% cut on input and 33% on output, which puts the regular price at about $5 / $30. Budget with that.
Fine-tunes go the same day: ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano-2025-04-14, ft-babbage-002 and ft-davinci-002. More on that below, because they have no real successor.

What the failure looks like

OpenAI’s only official statement is that “the model or endpoint will no longer be accessible.” It doesn’t document the error payload. What users reported after the July and August shutdowns this year (here and here) is consistent:

404 invalid_request_error / model_not_found
The model `gpt-5.1-codex` has been deprecated, learn more here:
https://platform.openai.com/docs/deprecations

The Python SDK raises it as openai.NotFoundError. Two practical consequences:

It isn’t retryable. If your wrapper retries on any exception with backoff, on October 23 it will spend its retry budget on a request that can never succeed, and your users will wait for it. Retry on 429 and 5xx, not on 404.
A health check that lists models will lie to you. According to those same reports, retired IDs keep showing up in GET /v1/models after they stop working. A startup check that confirms “my model is in the list” passes on a dead model. The only reliable check is a real one-token request.

The Responses API words it differently (“Model not found …”), so if you match on the message text, match on code: model_not_found instead.

1. The model you never wrote: library defaults

This is the one that catches teams who think they are safe because grep gpt-3.5 finds nothing. I checked the source of the libraries that most tutorials from 2023 and 2024 use:

Library	Default when you don’t pass a model	Source
LangChain Python, `ChatOpenAI`	`"gpt-3.5-turbo"`	`base.py#L733`
LangChain.js, `ChatOpenAI`	`"gpt-3.5-turbo"`	`base.ts#L286`
LlamaIndex, `OpenAI` LLM	`"gpt-3.5-turbo"`, and it’s what core falls back to when no LLM is configured	`DEFAULT_OPENAI_MODEL` in `llama-index-llms-openai`
Vercel AI SDK	no default model, but `openai.completion()` “currently only” supports `gpt-3.5-turbo-instruct`	OpenAI provider docs

So this, which appears in countless READMEs, is a gpt-3.5-turbo call:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0)   # no model= → "gpt-3.5-turbo"

And with LlamaIndex it can be less visible still: if you never set Settings.llm, a query engine builds an OpenAI() on its own, with the same default. LlamaIndex’s OpenAIResponses class defaults to gpt-4o-mini, which survives.

The Vercel case has an earlier date: gpt-3.5-turbo-instruct shuts down September 28, together with babbage-002 and davinci-002, so anything using openai.completion() or the legacy /v1/completions endpoint has one week, not a month. Those three are the only models the endpoint’s reference still names.

The fix is always the same: pass the model explicitly, and read it from configuration so the next shutdown is an environment variable, not a deploy.

For contrast, laravel/ai 1.x already defaults to gpt-5.6-terra, -luna, -sol and gpt-image-2. Newer libraries got this right; the problem is code built on the ones from 2023.

2. Tools on Chat Completions now need reasoning turned off

Every substitute in the table is a reasoning model, and that changes the contract of Chat Completions. From the GPT-5.6 upgrade guide:

For GPT-5.6, function tools in Chat Completions are compatible only with effective reasoning none. Reasoning with tools should use the Responses API.

The default reasoning effort is medium. So a function-calling chatbot that worked on gpt-4-turbo, with the model string changed and nothing else, fails on its first request. This is the error one team hit on gpt-5.6-luna:

400 - Function tools with reasoning_effort are not supported for gpt-5.6-luna

You have two ways out. The minimal one keeps Chat Completions and turns reasoning off, which is the closest thing to how gpt-4-turbo behaved:

const res = await openai.chat.completions.create({
  model: 'gpt-5.6-sol',
  reasoning_effort: 'none',     // required if you pass tools
  messages,
  tools,
});

The one OpenAI recommends is moving that call to the Responses API, where reasoning and tools do work together. It’s more than a rename: the system prompt goes to instructions, structured outputs move from response_format to text.format, and function definitions lose a nesting level:

// Chat Completions
tools: [{ type: 'function', function: { name: 'get_order', parameters } }]

// Responses
tools: [{ type: 'function', name: 'get_order', parameters }]

The strictness default also flips. According to the migration guide, functions are non-strict by default in Chat Completions, while in Responses omitting strict makes it attempt strict mode. If your JSON schemas were written loosely, set strict explicitly instead of inheriting the new default.

Chat Completions itself is not deprecated. OpenAI’s wording is that it “remains supported” and Responses “is recommended for all new projects”. You don’t have to migrate the endpoint on October 23, only decide about reasoning.

3. `max_tokens`: renamed, and now it has to pay for thinking

The Chat Completions reference marks max_tokens as “deprecated in favor of max_completion_tokens” and “not compatible with o-series models”. The docs don’t state whether GPT-5.6 rejects max_tokens outright; the team in the issue above reports that all their calls needed the new name. Rename it either way.

The part that actually changes behavior is what the new parameter counts. max_completion_tokens covers “visible output tokens and reasoning tokens”, and reasoning tokens “are billed as output tokens” (reasoning guide). The classic gpt-3.5-turbo classifier with max_tokens: 50 to force a short label, moved to gpt-5.6-terra at its default medium effort, can spend the whole budget thinking and come back truncated or empty, and you pay for the reasoning anyway. OpenAI recommends reserving at least 25,000 tokens for reasoning and output.

For short, deterministic tasks the fix is not a bigger budget but no reasoning:

client.chat.completions.create(
    model="gpt-5.6-terra",
    reasoning_effort="none",        # a label doesn't need to think
    max_completion_tokens=50,       # was max_tokens
    messages=messages,
)

temperature and top_p are a similar trap. For GPT-5.2 and 5.4 the docs say they’re only supported with reasoning effort none; for 5.6 I couldn’t find the rule written down. If you pass them, test with and without reasoning before the 23rd instead of finding out in production.

4. Fine-tuned models have no successor

The substitute column sends ft-gpt-3.5-turbo to gpt-5.6-terra and ft-gpt-4 to gpt-5.6-sol. Those are base models. The GPT-5.6 model pages list fine-tuning as not supported, and from January 6, 2027 existing customers can no longer create fine-tuning jobs at all.

In practice, whatever your fine-tune learned (tone, output format, domain labels) has to move into the prompt: few-shot examples, a strict schema through structured outputs, or retrieval. Plan that work now. It’s the only item on this list that is a project rather than a patch, and the training data you’ll need to write examples from is what you used to build the fine-tune.

5. `o1-pro` and `gpt-image-1`: different parameters, not new names

o1-pro → gpt-5.6-sol in pro mode. The guide is explicit: “do not search for or invent a separate gpt-5.6-pro slug”. Pro mode is a reasoning setting on Sol and only works through Responses, not Chat Completions. o1-pro was already Responses-only, so the endpoint doesn’t change; the model name and the reasoning setting do. OpenAI warns that pro mode “performs more model work”, so the per-token price is lower than o1-pro but the tokens per request go up.
gpt-image-1 → gpt-image-2. The image guide says to omit input_fidelity for gpt-image-2, so if your edit calls pass it, remove it. And if you depend on transparent backgrounds, gpt-image-2 has only offered them in preview since August 20.

6. The bill

For the GPT-4 family and o1, the switch saves money, even more so if you were still paying $30 / $60 for gpt-4-0613. For everything that was chosen because it was cheap, it costs more:

A classifier or router on gpt-3.5-turbo processing 1M input and 200K output tokens a day costs $0.80. On gpt-5.6-terra with reasoning off, $4.40. That’s 5.5× before counting a single reasoning token.
o3-mini → gpt-5.6-sol is 3.6× on input and 4.5× on output, and more once the promotion ends.
gpt-4.1-nano → gpt-5.6-luna doubles input and triples output.

If one of those lines matters to you, test a cheaper tier than the table suggests before accepting the substitute: the column says what OpenAI considers equivalent, not what your task needs. I break down per-task cost across providers in how much the OpenAI, Claude and Gemini APIs cost. And no, the table doesn’t point to gpt-6-astra, even though the reasoning guide now says “start with” it: at $10 / $50 and without temperature, top_p or top_logprobs it’s a different decision, which I cover in GPT-6 Astra for developers.

The audit: three greps and a real request

From the repository root. The first looks for the dead IDs as exact quoted strings, so it skips gpt-4o, gpt-4o-mini and gpt-4.1, which survive:

# 1. Model IDs that die on Oct 23 (and Sep 28), as quoted strings
grep -rnE "['\"\`](gpt-3\.5-turbo[a-z0-9-]*|gpt-4|gpt-4-0613|gpt-4-turbo[a-z0-9-]*|gpt-4-1106-preview|gpt-4o-2024-05-13|gpt-4\.1-nano[a-z0-9-]*|o1|o1-pro[a-z0-9-]*|o1-2024-12-17|o3-mini[a-z0-9-]*|o4-mini[a-z0-9-]*|gpt-image-1|babbage-002|davinci-002)['\"\`]" \
  --exclude-dir={node_modules,vendor,.git} .

# 2. The same in environment files, where names go unquoted
grep -rnE "=(gpt-3\.5|gpt-4(-|$)|o1|o3-mini|o4-mini|gpt-image-1$)" .env* 2>/dev/null

# 3. Constructors that inherit a library default
grep -rnE "ChatOpenAI\(|llama_index\.llms\.openai|openai\.completion\(" \
  --include=*.py --include=*.ts --include=*.js --exclude-dir=node_modules . | grep -v "model"

The third one gives false positives by design (a multi-line constructor with model= on another line will appear), but the list is short and it’s worth reading it by eye.

Then the test that counts: for every model you end up using, one real request with your production parameters (tools, max_completion_tokens, temperature if you pass it) against the new name. Not GET /v1/models, for the reason above.

Model names in configuration also live outside the repo: Make, Zapier or n8n workflows, a vendor’s chatbot panel, a Google Sheet with a script. The retirements guide has the checklist for those.

The rest of OpenAI’s calendar this year

All from the same deprecations page:

Date	What shuts down
Sep 24	Videos API, `sora-2` and `sora-2-pro` (no substitute)
Sep 28	`gpt-3.5-turbo-instruct`, `babbage-002`, `davinci-002`, `gpt-3.5-turbo-1106`
Oct 1	`gpt-5.4-cyber` → `gpt-5.6-cyber` (20 days’ notice)
Oct 23	Everything in this post
Oct 31	Evals go read-only
Nov 30	Evals dashboard and API, the `v1/prompts` API and reusable prompts, Agent Builder
Dec 1	`gpt-image-1-mini`, `gpt-image-1.5`, `chatgpt-image-latest` → `gpt-image-2`
Dec 11	`gpt-5`, `gpt-5-mini`, `gpt-5-nano`, `gpt-5-pro`, `o3` and `o3-pro` snapshots

The last row deserves a note: the gpt-5 and o3 model pages each list only the snapshot being retired, so the aliases very likely die with them. The openai-php/laravel README still uses 'model' => 'gpt-5' as its example. The Assistants API was already shut down on August 26.

Frequently asked questions

Which OpenAI models shut down on October 23, 2026?

gpt-3.5-turbo (including gpt-3.5-turbo-0125 and the -completions variant), gpt-4 and gpt-4-0613, gpt-4-turbo and gpt-4-turbo-2024-04-09, gpt-4-1106-preview, gpt-4o-2024-05-13, gpt-4.1-nano, o1, o1-pro, o3-mini, o4-mini and gpt-image-1, plus the fine-tuned models ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002 and ft-davinci-002. OpenAI announced it on April 22, 2026. The gpt-4o alias, gpt-4o-mini and gpt-4.1 are not on the list.

What should I replace gpt-4 and gpt-3.5-turbo with?

OpenAI lists gpt-5.6-sol as the substitute for gpt-4, gpt-4-turbo, gpt-4o-2024-05-13, o1, o1-pro (in pro mode) and o3-mini; gpt-5.6-terra for gpt-3.5-turbo and o4-mini; gpt-5.6-luna for gpt-4.1-nano; and gpt-image-2 for gpt-image-1. They are reasoning models, so changing the name is not enough: tools in Chat Completions need reasoning_effort none, max_tokens becomes max_completion_tokens and counts reasoning tokens.

What error does the OpenAI API return for a retired model?

OpenAI does not document the payload. Users who hit the July and August 2026 shutdowns report HTTP 404 with type invalid_request_error and code model_not_found, raised by the Python SDK as openai.NotFoundError. It is not retryable. Retired IDs may keep appearing in GET /v1/models, so the only reliable check is a real request.

Does LangChain still use gpt-3.5-turbo by default?

Yes. As of September 2026, ChatOpenAI in both LangChain Python and LangChain.js defaults to gpt-3.5-turbo when no model is passed, and LlamaIndex's OpenAI LLM does too (it is also what LlamaIndex falls back to when Settings.llm is not set). Code that never names a model will fail on October 23. Pass the model explicitly.

Why does gpt-5.6 fail with "Function tools with reasoning_effort are not supported"?

Because in Chat Completions, GPT-5.6 only accepts function tools when the effective reasoning effort is none, and the default is medium. Either add reasoning_effort: none to the request, which behaves closest to gpt-4-turbo, or move the call to the Responses API, where tools and reasoning work together.

Is the gpt-5.6 migration more expensive?

It depends on what you had. From gpt-4, gpt-4-turbo or o1 it is cheaper: gpt-5.6-sol lists at $4 input and $20 output per million tokens, a promotional price available at least through November 21, 2026. From gpt-3.5-turbo to gpt-5.6-terra it is 4 times the input and 8 times the output price, and from o3-mini to sol about 3.6 and 4.5 times, before counting reasoning tokens, which are billed as output.

What happens to my fine-tuned gpt-3.5-turbo model?

It shuts down on October 23, 2026 with the base models. The listed substitute is the base gpt-5.6-terra, and GPT-5.6 does not support fine-tuning; from January 6, 2027 existing customers cannot create fine-tuning jobs. What the fine-tune learned has to move into the prompt: few-shot examples, structured outputs or retrieval.

Chrome Removes XSLT: What Breaks in Sitemaps, Feeds and CFDI Invoice Tools

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

Chrome 158 reaches Stable on 17 November 2026 and stops running XSLT: XSLTProcessor goes away, and so does processing of <?xml-stylesheet type="text/xsl"?>. For most sites that only changes the decoration. The sitemap or feed a human used to see as a table goes back to raw XML, with no error and no change to the file. Where real code breaks is a very Mexican corner of the web: invoice viewers and validators that build a CFDI’s original string in the browser with the tax authority’s XSLT stylesheet. There, the function throws ReferenceError: XSLTProcessor is not defined.

I tested both in Chrome 152 with the switch that turns XSLT off early. For the invoice part I went further: I generated the original string of a test invoice with five different engines and checked every result against the invoice’s own digital seal. A JavaScript XSLT library produces a string the seal does not verify against, the polyfill Chrome recommends fails if the stylesheet keeps its includes, and the official stylesheet as published does not even run in the browser.

The dates

Everything comes from the Chrome for Developers announcement and the Chrome Platform Status entry, with Stable dates checked against Chromium Dash:

Milestone	Version	Date
Console warnings	Chrome 142	28 Oct 2025
Official deprecation (console and Lighthouse)	Chrome 143	2 Dec 2025
Origin Trial to keep using it starts	Chrome 152	25 Aug 2026
Beta of the removing version	Chrome 158	28 Oct 2026
XSLT stops working on Stable	Chrome 158	17 Nov 2026
Origin Trial and the `XSLTEnabled` enterprise policy end	Chrome 176	17 Aug 2027

One detail shortens the runway more than it looks: since Chrome 153 (8 September) a new Stable version ships every two weeks, not every four. Between today and 158 there are nine weeks and five releases.

What about Firefox and Safari? Same direction, no date. Mozilla took a positive position, and its tracking bug has already closed the console warning (Firefox 147) and an enterprise policy (Firefox 151), but disabling it by default is still open. WebKit said it is “cautiously supportive” and would probably wait for one engine to remove it fully. The HTML standard marked XSLT deprecated on 25 August 2026. In practice, what Chrome 158 does is what most of your users will see in November.

What breaks, what you see, how to fix it

What you use	What happens in Chrome 158	Fix
XML sitemap with an XSL stylesheet (WordPress core, Yoast, Rank Math, `xslURL` in `@astrojs/sitemap`)	A human sees Chrome’s XML viewer instead of the table. No error, and the served file does not change	Nothing, if nobody looks at it. If it matters, drop the instruction or serve a separate HTML version
RSS/Atom feed with an XSL stylesheet (a `.xsl` `stylesheet` in `@astrojs/rss`)	Opened in the browser, it shows raw XML. Feed readers do not notice	`<link rel="alternate" type="application/rss+xml">` in your HTML, or the one-line polyfill
JavaScript that calls `new XSLTProcessor()`	`ReferenceError: XSLTProcessor is not defined`	Move the transform to the server, or use a JS/WASM XSLT engine
CFDI viewer or validator that builds the original string in the browser	The string is never produced, so the seal cannot be verified	Server-side ext-xsl, xslt-polyfill with a flattened stylesheet, or SaxonJS (details below)
`<?xml-stylesheet type="text/css"?>`	Nothing: still supported	—
XSLT on your server (PHP ext-xsl, Saxon, xsltproc)	Nothing: this only affects the browser	—

Sitemaps and feeds: the decoration breaks, not the file

I opened the yoast.com sitemap index in Chrome 152 twice. With XSLT on, Chrome applies the stylesheet and renders a page titled “XML Sitemap” with its table. With --disable-features=XSLT, the same URL lands in Chrome’s XML viewer: the tree of <sitemap>, <loc> and <lastmod> with the xml-stylesheet instruction visible, no styling and no error. According to the announcement, Chrome also shows a banner linking to extensions when XSLT is off; in headless mode I could not see it.

This will hit a lot of people, because the XSL stylesheet ships by default across most of the ecosystem:

WordPress core adds <?xml-stylesheet type="text/xsl" href=".../wp-sitemap.xsl" ?> to wp-sitemap.xml since 5.5. Ticket #65593 to remove it sits in the 7.2 milestone, with PR #12448 open and an alternative (#12584) that renders an HTML version on the server. As of 13 September neither is merged.
Yoast SEO still emits it in trunk, which the changelog labels 28.5 for 15 September, and the yoast.com sitemap carries it today.
Rank Math still emits it in trunk, and the rankmath.com sitemap carries it today too.
Astro: @astrojs/sitemap has an xslURL option, and @astrojs/rss sets type="text/xsl" when you pass a stylesheet ending in .xsl. Neither is on by default.

What about Google?

I am not going to write “Googlebot is unaffected” as if Google had said so: I found no Google Search statement about XSLT and sitemaps. What is verifiable is that the change lives in the browser. Your server sends exactly the same bytes before and after 17 November, and Chrome’s announcement says it is not removing XML, only XSLT. A crawler that already read your sitemap without running the stylesheet keeps receiving the same file.

What to do with the sitemap

If no human ever opens your sitemap, do nothing. If people use it as a page, you have three paths:

Drop the instruction. It saves the request for the .xsl and the console warnings. WordPress core has official filters: per its own source, returning a falsy value means “the raw XML of the sitemap will be displayed”:
```
// In an mu-plugin or functions.php
add_filter( 'wp_sitemaps_stylesheet_url', '__return_false' );
add_filter( 'wp_sitemaps_stylesheet_index_url', '__return_false' );

// Yoast: the filter says "url", but it receives the full declaration
add_filter( 'wpseo_stylesheet_url', '__return_empty_string' );
```
In Rank Math the filter is per sitemap type (rank_math/sitemap/{type}_stylesheet_url). In Astro, just remove xslURL or stylesheet.
Serve HTML separately. That is what WordPress PR #12584 proposes: the same transform, done on the server, published at a .html URL. The .xml stays for machines.
CSS instead of XSL. <?xml-stylesheet type="text/css"?> is still supported, but the WordPress ticket pointed out the limit: CSS can style the XML, but the <loc> entries do not become clickable links.

For feeds, Chrome recommends advertising the feed with <link rel="alternate"> in your HTML instead of a visible link to the .xml, or adding a single polyfill line to the feed.

CFDI invoices: where code actually breaks

Context for anyone who does not invoice in Mexico: a CFDI is the electronic invoice format mandated by Mexico’s tax authority, the SAT, and every one is a signed XML file. The signature (the Sello attribute) is not computed over the whole XML but over the original string (cadena original): the invoice’s values in a fixed order, separated by |. To verify a seal you need that string. To print the tax stamp’s own string on a PDF representation, you need it too.

The SAT publishes that sequence as an XSLT stylesheet: on its Annex 20 page, the “Secuencia de cadena original” document links to cadenaoriginal_4_0.xslt, last modified on 17 April 2026. The tax stamp has its own, cadenaoriginal_TFD_1_1.xslt. Three details of that file matter here:

It declares version="2.0", but browsers only implement XSLT 1.0. It still works with 1.0 processors: the CfdiUtils docs say so for PHP, which uses the same engine as Chrome (libxslt), and I confirmed it in the browser below.
It pulls in 33 xsl:include files (utilities and complements), all by absolute URL to http://www.sat.gob.mx.
The output is plain text (method="text").

That is why building the string in the browser was tempting: XSLTProcessor came built in, and the XML never left the user’s machine. I looked for real code doing it and found two patterns:

An npm library of Mexican validators and catalogues, with a release published at the end of August 2026, whose original-string function uses new XSLTProcessor() when it detects window and falls back to a JavaScript engine in Node. In Chrome 158 the detection is still true (DOMParser is not going anywhere), so it takes the browser branch and throws the ReferenceError.
A public JavaScript e-signature repository that loads cadenaoriginal_3_3.xslt from a file input, stores it in localStorage and builds the string with XSLTProcessor.transformToDocument to verify the seal of a CFDI 3.3 invoice.

The SAT stylesheet does not run as-is in the browser

I found this while testing and have not seen it documented anywhere. Hand XSLTProcessor the official stylesheet and Chrome refuses to load the 33 includes (the URL below is my test page):

Unsafe attempt to load URL http://www.sat.gob.mx/sitio_internet/cfd/2/cadenaoriginal_2_0/utilerias.xslt
from frame with URL http://localhost:8765/native.html. Domains, protocols and ports must match.

The result is null. So anyone building the string in the browser with XSLTProcessor today has to serve the stylesheet and its includes from their own origin, or flattened into a single file. That helps detection: the copy lives in your repository, so searching for cadenaoriginal finds it.

Why this site’s CFDI viewer does not break

The CFDI 4.0 XML viewer I wrote for this site, which now lives on Siempre Contable (in Spanish), does not use XSLT, and not by luck. It reads the XML with DOMParser, walks Comprobante, Emisor, Receptor, Conceptos, Impuestos and the TimbreFiscalDigital, translates the catalogue codes and checks the arithmetic. It does not build the original string or validate the seal, and the tool says so on screen. DOMParser is one of the APIs Chrome cites as the modern way to read XML, so it is not at risk. I grepped the whole repository: not a single XSLTProcessor or xml-stylesheet. The site’s sitemaps and RSS feed carry no stylesheet either. The open-source mx-fiscal-mcp-server, which reads CFDI invoices for AI agents, runs in Node on @xmldom/xmldom and does not use XSLT either.

The alternatives, tested against a real seal

Claiming “SaxonJS solves it” is easy. To check it, I took cfdi40-valid.xml from the CfdiUtils test suite, a CFDI 4.0 invoice signed with a SAT test certificate. I generated the string with each engine and accepted it only if the XML’s Sello verifies against it with the public key of its own Certificado:

# cert.pem = the base64 Certificado attribute, wrapped as PEM
# sello.bin = the Sello attribute, base64-decoded
openssl x509 -in cert.pem -pubkey -noout > pub.pem
openssl dgst -sha256 -verify pub.pem -signature sello.bin cadena.txt
# Verified OK  → the string is correct

The reference was Saxon-HE 12.5 (Java, MPL 2.0) with the official stylesheet: Verified OK. The rest:

Engine	Runs in	License	Result with the SAT stylesheet
Native `XSLTProcessor`, official stylesheet	Browser	—	Fails: blocks cross-origin includes
Native `XSLTProcessor`, local copy	Browser	—	`Verified OK`. Gone in Chrome 158
xslt-polyfill 1.0.28, stylesheet flattened into one file	Browser (WASM)	BSD-3-Clause	`Verified OK` with native XSLT turned off
xslt-polyfill 1.0.28, copy with includes	Browser (WASM)	BSD-3-Clause	Fails: `Error: Unknown mime type undefined`
SaxonJS 2.7 (`saxon-js` + `xslt3`), stylesheet compiled to SEF	Node; per its docs the SEF also runs in the browser	Free of charge, not open source	`Verified OK` in Node
xslt-processor 5.1.2	Pure JS	LGPL-3.0	Different string, seal does not verify

The xslt-processor string starts with ||||| (five pipes instead of two). With the flattened stylesheet, the output shrinks to three pipes. It may be fine for other jobs, but it does not produce the SAT’s original string as-is.

The polyfill’s failure with includes is not a random bug; it is in its README. It resolves xsl:include with fetch(), which is asynchronous, while XSLTProcessor’s methods are synchronous, so they fail when the stylesheet has includes. Flattening fixes it: replace each <xsl:include> with the contents of the included stylesheet, in the same order. With the current 4.0 stylesheet you do not need to add namespaces, because the main root already declares every one the includes use.

Option 1: on the server (the boring one, which is why it wins)

PHP’s ext-xsl is still in the PHP manual, built on libxslt, and Chrome’s removal does not touch it. With CfdiUtils (eclipxe/cfdiutils, MIT, 3.0.4 from 11 September 2026):

use CfdiUtils\XmlResolver\XmlResolver;
use CfdiUtils\CadenaOrigen\DOMBuilder;

// XmlResolver downloads the SAT stylesheets and rewrites their dependencies to local copies
$resolver = new XmlResolver();
$location = $resolver->resolveCadenaOrigenLocation('4.0');

$cadena = (new DOMBuilder())->build($xmlContent, $location);

A correction to something that gets repeated: CfdiUtils does not build the string without XSLT. DOMBuilder is an ext-xsl XSLTProcessor; it also ships GenkgoXslBuilder (XSLT 2.0 in PHP) and SaxonbCliBuilder. Its author explains that building the string without XSLT is possible, but it means a lot of code to write and test, and that code has to change along with every complement’s specification.

From the browser, it becomes one request:

const res = await fetch('/api/cfdi/original-string', {
  method: 'POST',
  headers: { 'Content-Type': 'application/xml' },
  body: xmlText,
});
const cadena = await res.text();

The cost is privacy: if your viewer promised “the XML never leaves your browser”, that stops being true and the copy has to change.

Option 2: stay in the browser with the polyfill

If local processing is the product, xslt-polyfill replaces XSLTProcessor with libxslt compiled to WebAssembly. It weighs about 1.4 MB minified. With a flattened stylesheet, your existing code does not change:

<script src="/vendor/xslt-polyfill.min.js"></script>
<script>
  const xsl = new DOMParser().parseFromString(flattenedStylesheet, 'application/xml');
  const cfdi = new DOMParser().parseFromString(xmlText, 'application/xml');
  const p = new XSLTProcessor(); // the polyfill's, once the browser has no XSLT
  p.importStylesheet(xsl);
  const cadena = p.transformToFragment(cfdi, document).textContent;
</script>

While the browser still has native XSLT, the polyfill does not install itself. To try it in today’s Chrome, set window.xsltUsePolyfillAlways = true before loading the script.

Option 3: SaxonJS

SaxonJS implements the mandatory parts of XSLT 3.0, which is more than enough for a stylesheet declaring 2.0. The documented flow is to compile the stylesheet to a SEF file and run that:

npx xslt3 -xsl:cadenaoriginal_4_0_flat.xslt -export:cadena.sef.json -nogo

import SaxonJS from 'saxon-js';

const { principalResult: cadena } = SaxonJS.transform({
  stylesheetFileName: 'cadena.sef.json',
  sourceText: xmlText,
  destination: 'serialized',
});

In my test, compiling took 2.4 s and the SEF weighed 3.65 MB, which matters if you ship it to the browser. Check the license before redistributing: Saxonica offers it free of charge, but it is not open source.

How to find out if you depend on XSLT

1. Search the code. Server-side hits in PHP, Java or .NET do not affect you; JavaScript that runs in the browser does:

grep -rnE "XSLTProcessor|transformToFragment|transformToDocument|importStylesheet|xml-stylesheet|cadenaoriginal" \
  --include=*.{js,mjs,ts,tsx,jsx,vue,svelte,astro,html,xml,php} \
  --exclude-dir={node_modules,vendor,.git} .
find . -name "*.xsl" -o -name "*.xslt" | grep -v node_modules

2. Search what you built. The npm library above hides XSLTProcessor inside node_modules, so the grep above misses it. Run the same pattern over your build output (dist/, build/, .next/, public/build/).

3. Check what you serve.

curl -s https://yoursite.com/wp-sitemap.xml | head -c 300 | grep -o 'xml-stylesheet[^?]*'
curl -s https://yoursite.com/feed/ | head -c 300 | grep -o 'xml-stylesheet[^?]*'

4. Test with XSLT off. No need to wait for November or install Canary. In Stable Chrome, go to chrome://flags/#xslt and set it to Disabled, or start Chrome with --disable-features=XSLT (I verified it on Chrome 152). For a headless check:

chrome --headless=new --disable-features=XSLT --dump-dom \
  'data:text/html,<script>document.write(typeof XSLTProcessor)</script>'
# undefined  → this is how your app will look in Chrome 158

5. Let production tell you. Chrome reports the deprecation through the Reporting API with the id XSLT:

new ReportingObserver((reports) => {
  for (const r of reports) {
    if (r.body.id === 'XSLT') navigator.sendBeacon('/telemetry/xslt', r.body.sourceFile ?? '');
  }
}, { types: ['deprecation'], buffered: true }).observe();

And open the console: every use prints “XSLTProcessor and XSLT Processing Instructions have been deprecated by all browsers”.

Who actually needs to act

You run a CFDI viewer, validator or PDF generator that builds the original string in the browser: you are the audience for this post. You have until 17 November. Pick server-side (and update your privacy copy) or the polyfill with a flattened stylesheet, and validate against a real seal as above before shipping.

You use XSLTProcessor for anything else on the front end: same deadline, same options. If you cannot migrate in time, the Origin Trial buys you until August 2027. If what uses XSLT is an XML document, there is no <head> for the meta tag, so the token goes in the Origin-Trial HTTP header.

You have a WordPress, Yoast, Rank Math or Astro site with a styled sitemap: nothing that matters for indexing breaks. Drop the instruction if the warning bothers you, or serve HTML separately if people read that sitemap.

Your company runs an internal app or device that serves XML with XSL and you cannot change it: the XSLTEnabled enterprise policy and the extension Chrome recommends are for you. The policy expires in August 2027. The extension applies the polyfill, so it does not depend on native XSLT.

You only build the string in PHP, Java or .NET on the server: not your problem. This is a browser change.

Further reading:

Validate Mexican RFC, CURP and CFDI invoices from Claude: the open-source MCP server that reads CFDI 4.0 and validates RFC, CURP and CLABE, and the six details a regex gets wrong.
Best MCP servers for SEO in 2026: if you audit sitemaps with agents, which tool does what.
What breaks upgrading to Node 26: the same format for the runtime.

Frequently asked questions

When does Chrome remove XSLT support?

In Chrome 158, which reaches Stable on 17 November 2026. From that version XSLTProcessor and processing of xml-stylesheet instructions with type text/xsl stop working, except for sites enrolled in the Origin Trial and machines with the XSLTEnabled enterprise policy. Both exceptions end in Chrome 176, on 17 August 2027. The Chrome 158 beta ships on 28 October 2026.

Does my XML sitemap with an XSL stylesheet break in Chrome 158?

The file does not. What changes is how a person sees it in Chrome: instead of the table generated by the XSL stylesheet, the browser shows its raw XML viewer, with no error. I tested it in Chrome 152 with XSLT disabled on the yoast.com sitemap index. The server keeps sending exactly the same bytes. Google has not published anything specific about XSLT and sitemaps, but the change is in the browser, not in the XML document.

How do I remove the XSL stylesheet from a WordPress sitemap?

In WordPress core, return false from the wp_sitemaps_stylesheet_url and wp_sitemaps_stylesheet_index_url filters, for example with __return_false; the core source says that displays the raw XML. In Yoast, the wpseo_stylesheet_url filter receives the full declaration and you can return an empty string. In Rank Math the filter is per type: rank_math/sitemap/{type}_stylesheet_url. WordPress core has ticket 65593 open to remove the stylesheet in version 7.2.

Why do CFDI invoice viewers that use XSLT in the browser break?

Because the original string of a CFDI 4.0 invoice is defined by the SAT through the cadenaoriginal_4_0.xslt stylesheet, and the convenient way to run it in the browser was XSLTProcessor. In Chrome 158 that class no longer exists and the code throws ReferenceError: XSLTProcessor is not defined. Without the original string you cannot verify the invoice's digital seal. Reading the XML with DOMParser, as this site's CFDI viewer does, keeps working.

Which alternative correctly builds the SAT original string without browser XSLT?

I tested several against the seal of a CFDI 4.0 test invoice. Saxon-HE in Java, SaxonJS 2.7 with the stylesheet compiled to SEF, and xslt-polyfill 1.0.28 in the browser with the stylesheet flattened into one file all produced the correct string. xslt-polyfill fails if the stylesheet keeps its 33 xsl:include files, and xslt-processor 5.1.2 produced a different string that the seal does not verify against. On the server, PHP with ext-xsl, which is what CfdiUtils uses, is unaffected.

Does CfdiUtils build the CFDI original string without XSLT?

No. Its DOMBuilder uses XSLTProcessor from PHP's ext-xsl extension with the SAT stylesheet, and it also offers GenkgoXslBuilder and SaxonbCliBuilder. Its documentation notes that the stylesheet declares XSLT 2.0 but the PHP transform produces the expected result. Because it runs on the server, Chrome's XSLT removal does not affect it.

How can I test my site today as if it were Chrome 158?

In Stable Chrome, go to chrome://flags/#xslt and set it to Disabled, or start the browser with --disable-features=XSLT. With that, typeof XSLTProcessor returns undefined and XML files with an XSL stylesheet render raw. To catch uses in production, register a ReportingObserver for deprecation reports and filter the ones with id XSLT.

Portainer 3.0 Is Kubernetes-First: What Changes If You Run Docker (and Which Alternative to Pick)

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

Portainer 3.0 will not break your Docker host at the end of the month. What ends is something else: there will be no Community Edition of the 3.x line. CEO Neil Cresswell said so himself in the official announcement on 11 September 2026: CE “will continue on the 2.x codebase” and “will not receive the 3.x changes.” 3.x stays free for the community only through the 3 Nodes Free program, which is a Business Edition license. And 3.x is, in his words, “a Kubernetes-first codebase.”

If you run Docker — not Kubernetes — with Portainer CE, the decision is not urgent, but it is real: stay on 2.x for as long as it lasts, take the free three-node license and accept a product built around Kubernetes, or leave. Below are the facts checked against primary sources, what breaks on each path, and which tool fits which setup. I run Coolify in production on two VPSes, so at the end I also share what has bitten me.

What the announcement actually says

Topic	What Portainer published
Last 2.x release	2.45 LTS (GitHub release `2.45.0`, 27 August 2026) is the last release in the 2.x line
3.0	Ships as 3.0.0 STS “from the end of this month”; the next LTS is 3.3.0, in December
Direction	3.x is Kubernetes-first: keeping Docker/Podman, Swarm and Kubernetes at parity in one codebase “is no longer viable”
Native Docker, Swarm and Podman environments	You can still add them and “they still work,” but they are ordered second in the UI and will not receive new capabilities from the policy engine, GitOps engine or observability layer
New products	Portainer-Run, IDP, Command and AiGrid are Kubernetes-only
If you stay on 2.x	“Nothing changes”: security updates, bug fixes and selective back-ports of 3.x features continue
Community Edition	Continues on 2.x. No separate CE build of 3.x; 3.x is free through 3 Nodes Free
Official recommendation	Move from Docker to D2K (a synthetic Docker on top of Kubernetes) or native Kubernetes; KubeSolo for single nodes

The Reddit take: “CE is gone, and the only free option is Business up to 3 nodes”

That reading spread on r/selfhosted. It is correct for the 3.x line and incomplete about everything else. Here is what the primary sources confirm:

True: there will be no CE edition of 3.x, and the free way to run 3.x is 3 Nodes Free. The program page says it is a Business Edition license key, sent after you fill in a form, and “limited to one license per organization.”
Incomplete: CE does not vanish tomorrow. It stays on 2.x, the portainer/portainer repository keeps its zlib license, and the lifecycle policy gives 2.45 LTS maintenance until May 2027.
The detail almost nobody mentions: the three-node license expires and has to be renewed. The docs say the new key is not sent until 14 days before the current one expires. CE needed no form and no renewal.
What counts as a node: per the licensing FAQ, on Docker any server running the Portainer Server or the Agent counts. Three Docker hosts (one running the server, two running agents) are three nodes, so you have used up the free tier.

A warning about that May 2027 date: the same lifecycle page still lists a 2.46 STS for September and a 2.51 LTS for February 2027, which the announcement contradicts, since 2.45 is the last 2.x. The table has not been updated since the announcement, so treat May 2027 as the published date, not a guarantee. The announcement itself gives no end date for 2.x.

What breaks (and what doesn’t) on each path

Path 1: you stay on Portainer CE 2.45

Nothing breaks today. There are still two things worth doing this week.

Pin the exact image version. On Docker Hub, the lts, sts and latest tags of portainer/portainer-ce were last updated on 27 August, with 2.45.0. I found nothing documenting where those tags will point once 3.0 STS ships, so if you run Watchtower or anything similar, do not let a floating tag make the call:

services:
  portainer:
    image: portainer/portainer-ce:2.45.0   # not :latest or :sts

Make sure you are on 2.45.0 (or 2.39.7 if you are still on the previous LTS). The 2.45.0 release notes fix a critical authorization bypass in the Docker proxy: unrecognized API version prefixes such as /v1.47.0/ skipped access control entirely, letting non-admin users reach the Docker API directly. 2.39.7 LTS got the same fix on the same day.

To check which image you are running:

docker ps --filter name=portainer --format '{{.Image}}'

Staying costs you new features and buys you time to decide.

Path 2: you move to 3.x on the 3-node license

Your native Docker environments keep working; the announcement is explicit about that. What changes are the terms: a Business license that expires, a three-node cap, a product whose roadmap no longer includes Docker, and a 3.0 that ships as STS (the LTS arrives in December with 3.3.0). If you manage more than three hosts, this path is a paid one.

There is an upside if several people share your Portainer: role-based access control is a Business Edition feature per the roles documentation, so 3 Nodes Free gives you RBAC.

Path 3: you follow Portainer’s advice and move to D2K

This is where things do break, by design rather than by bug. D2K (MIT licensed) exposes the Docker Engine API and translates every call into Kubernetes objects inside one namespace. Its own README lists what it does not support and says it “will not be added”:

What you use on Docker today	What happens on D2K
`build:` in your compose file	Ignored: images must be pre-built and pushed to a registry
`docker build`, `docker load`, `docker save`, `buildx`	Not supported
`macvlan` / `ipvlan` networks	Not supported: those workloads “must remain on a native Docker host”
`--network host`, `--ip`, `--mac-address`, `--link`	No equivalent
Separate networks per stack	`docker network create` is synthetic: network isolation is not enforced, and all pods share the namespace network
Bind mounts like `./data:/app/data`	Become `hostPath` volumes, “unreliable in multi-node clusters”
`--device` (for example `/dev/video0`), `--ulimit`	Not translated
`docker stats`	Needs metrics-server to return real data

If your compose file builds its image on the same server, if you isolate your database on an internal network, or if anything runs with network_mode: host, D2K is not a migration. It is a redesign, and there is still a Kubernetes cluster underneath to operate.

The alternatives, verified

I checked the repository, license and latest release of each one on 13 September 2026.

Coolify: if what you do in Portainer is deploy your own apps

License: Apache-2.0. About 61,700 GitHub stars.
Maturity: stable v4.0.0 shipped on 27 April 2026, and the latest release is v4.3.19, from 10 September. It shipped four releases between 3 and 10 September.
What it is: a self-hosted PaaS, not a container UI. It deploys from git (Nixpacks, Railpack, Dockerfile, Docker Compose or static site), runs the reverse proxy (Traefik or Caddy) with certificates, schedules database backups, ships 280+ one-click services and manages multiple servers over SSH.
Users: teams, 2FA, and OAuth with Azure, Bitbucket, Clerk, Discord, GitHub, GitLab, Google, Authentik, Infomaniak and Zitadel (the list comes from the source code).
Requirements: 2 cores, 2 GB of RAM and 10 GB of disk per its documentation, which also recommends a fresh server to avoid conflicts with whatever is already running.
What it is not: a dashboard for containers you started by hand. Its model is that Coolify does the deploying.
Swarm: deprecated. The notice in its own code says Swarm will be removed in Coolify v5 and that new Swarm deployments are not recommended.

Komodo: the most direct Portainer replacement across many servers

License: GPL-3.0. About 12,200 stars. Latest release: v2.3.3, from 1 September 2026; v2.0.0 shipped on 24 March.
What it does: connects servers (with an agent called Periphery on each), deploys containers and Compose stacks defined in the UI, on the host or in a git repo, with auto-redeploy on push through webhooks. It also builds images, runs scheduled automations and records who changed what and when.
Swarm: supported since v2.0.0 (clusters, nodes, services, stacks, configs and secrets).
Users: username and password with 2FA, OAuth with GitHub, Google and generic OIDC, and granular role-based permissions.
Server limit: none, “and there never will be,” per its README.
Requirements: Docker, plus MongoDB or FerretDB (on Postgres) for Core. It asks for the most infrastructure on this list, and its docs assume you bring your own reverse proxy.

Dockge: if all you want is to edit `compose.yaml` files in a browser

License: MIT. About 24,300 stars. Same author as Uptime Kuma.
Maturity: latest release 1.5.0, from 30 March 2025; the latest commit on master is from April 2026. Maintenance is slow.
What it does: creates, edits, starts and updates Compose stacks with a web terminal, and converts docker run commands to compose. Your files stay on disk (/opt/stacks by default) and keep working with plain docker compose. Since 1.4.0 it manages multiple hosts through agents.
What it doesn’t: it has a single account. Setup refuses to create a second user, and the pull request that added users and groups (#891) was closed unmerged in July 2026. No SSO, no roles, and the README does not mention deploying from git.

Dockhand: the most complete UI, with fine print in the license

It exists and moves fast: the Finsys/dockhand repository was created in December 2025, has about 6,200 stars, and its latest release is v1.0.47, from 12 September 2026.
What it does: containers, Compose stacks with a visual editor, git deployments with webhooks, multiple hosts (over the socket, TCP with TLS, or Hawser, its MIT-licensed agent that connects outbound with no open ports), vulnerability scanning with Grype and Trivy, backups (in beta) and free OIDC/SSO. SQLite by default or PostgreSQL, and they say it runs on a Raspberry Pi 4.
What it doesn’t: Swarm; there is an open issue asking for it. RBAC, LDAP/Active Directory and compliance audit logging are Enterprise features ($1,499 per host per year).
The license contradicts itself. The repository’s LICENSE.txt is the Business Source License 1.1 with an additional use grant that explicitly permits “internal business use” in production, as long as you do not offer it as a Docker management SaaS; it converts to Apache-2.0 on 1 January 2029. The license terms on its website, however, say commercial users need a paid license for production environments or shared instances, and the pricing table places the “commercial usage license” in the SMB plan ($499 per host per year). For a homelab there is no ambiguity. If you are a company, get clarification in writing before you put it in production.

Lazydocker and Yacht, for completeness

Lazydocker (MIT, about 52,800 stars, v0.25.2 from April 2026) is a terminal UI, not a web server: no users, no agents, nothing to expose. If you only used Portainer to read logs and restart containers, it is enough.
Yacht published again in September 2026 (release 1.1) after years without releases; the previous one, v0.0.7-alpha, dates from 2021. Too early to trust with production.

The decision table

Your situation	Pick	Why
Homelab with 1 to 3 hosts; you use Portainer CE to look and restart	Stay on CE 2.45.0 and decide before May 2027	Nothing breaks today and you have runway
You only edit `compose.yaml` files and you are the only user	Dockge	MIT, minimal, and your files stay on disk
You want a modern Portainer-style UI for personal use	Dockhand	Most complete: git, vulnerability scanning and free SSO
A company with several servers, several people and stacks in git	Komodo	GPL, no server limit, roles and OIDC with no license fee
You run Docker Swarm	Komodo, or stay on Portainer 2.45	Coolify deprecated it; Dockge and Dockhand don’t support it
You deploy your own apps from git to one or more VPSes	Coolify	Builds, proxy, certificates and backups included
You already pay for Portainer Business, or 3 nodes with RBAC is enough and you are heading to Kubernetes	Portainer 3.x	That is exactly who it is built for
You only open Portainer to read logs	Lazydocker	Nothing to expose, nothing to license
Your stacks build images on the server or use `network_mode: host` or `macvlan`	Anything but D2K	D2K ignores `build:` and does not support those networks

What I have learned running Coolify on two VPSes

I run Coolify in production on two servers: one hosting this site and client apps, the other running internal tools. Three things no comparison page tells you, and they apply to any tool that talks to the Docker socket, Portainer, Dockge and Dockhand included.

1. After upgrading docker-ce, restart the containers that mount the socket. In May 2026 I upgraded Docker from 29.5.0 to 29.5.2 with live-restore enabled. The apps stayed up, but Coolify’s proxy (Traefik with the Docker provider) got stuck in a reconnect loop against /var/run/docker.sock. The result: HTTP 502 on every app routed through Docker, while the dashboard, which is routed through a config file, kept responding, which makes it easy to misdiagnose. live-restore protects the containers, not the connections they held open to the socket. Since then, after every upgrade I run:

docker restart coolify-proxy coolify-sentinel

Or, more generally, I restart every container that mounts the socket:

for c in $(docker ps --format '{{.Names}}'); do
  docker inspect -f '{{range .Mounts}}{{if eq .Source "/var/run/docker.sock"}}{{$.Name}}{{end}}{{end}}' "$c" | grep -v '^$'
done | xargs -r -n1 docker restart

Note that since v4.3.19 Sentinel is mandatory on regular Coolify servers, so restarting coolify-sentinel now applies to every install.

2. Docker bypasses UFW. When I installed Coolify on the second VPS, the dashboard and realtime ports ended up open to the internet even though UFW did not allow them: ports published by a container go through iptables rules that Docker manages before UFW ever sees the traffic. I fixed it with DROP rules in the DOCKER-USER chain, matching on the connection’s original destination port (conntrack --ctorigdstport, because by the time a packet reaches that chain, DNAT has already rewritten the port), and left only 80 and 443 public. If you install any of these UIs with a published port, check from outside the server; do not trust ufw status.

3. Firewall rules pinned to a container IP break on reboot. On the production server, after a reboot, every domain timed out even though Traefik was healthy. The ufw-docker rules pointed at the proxy’s old internal IP, and the proxy came back with a different one. The fix that holds was allowing 80 and 443 to Docker’s network range instead of to a specific IP. Restarting Docker does not fix it, because the rules belong to UFW.

And one that comes straight from Coolify’s own documentation, which I can confirm: create the admin account as soon as the install finishes. Whoever reaches the registration page first gets control of the server.

If you are copying your stacks out of Portainer into another tool, validate each compose.yaml against the official schema before the first deploy:

Verdict

If you run Portainer CE on Docker, do not migrate this month. 2.45 LTS is still maintained, 3.0 ships as STS, and the first 3.x LTS does not arrive until December. Pin the image to 2.45.0 and use the next few months to trial your alternative on a server that is not production.

But do not wait for a CE 3.x, because it is not coming. The Portainer you knew — free, no sign-up, no node cap, Docker as a first-class citizen — is frozen on 2.x.

To choose, ask what you really do in Portainer. If you deploy your own apps, the natural move is Coolify, and it is what I use. If you manage stacks across several servers with a team, Komodo is the closest thing to what Portainer used to be, with no node cap and no commercial license. If it is just you and a homelab, Dockge if the minimum is enough, or Dockhand if you want everything. And if you were already heading to Kubernetes, Portainer 3.x is built for you; D2K only makes sense if your stacks neither build images nor rely on special networking.

Keep reading:

The complete Docker guide for 2026: Compose v5, Engine 29 and how Compose, Swarm and Kubernetes compare for production.
Kubernetes 1.37: what breaks on upgrade day: if you do end up on Kubernetes, with or without D2K, this is what blocks an upgrade right now.

Frequently asked questions

Is Portainer Community Edition going away with 3.0?

Not immediately, but there will be no CE 3.x. According to the official announcement on 11 September 2026, CE continues on the 2.x codebase and will not receive the 3.x changes. Portainer is not cutting a separate CE build of 3.x: the free way to run 3.x is the 3 Nodes Free program, which is a Business Edition license. Portainer's lifecycle policy gives 2.45 LTS maintenance until May 2027.

What is Portainer 3 Nodes Free and what does it limit?

It is a free Portainer Business Edition license for up to three nodes, limited to one license per organization and requested through a form. The license expires and must be renewed: the new key is sent no earlier than 14 days before expiry. On Docker, any server running the Portainer Server or the Portainer Agent counts as a node, so three Docker hosts already use up the free tier.

Will my Docker environments stop working if I upgrade to Portainer 3.x?

No. The announcement says native Docker, Swarm and Podman environments can still be added and still work from the UI. What changes is that they are ordered second in the product and will not receive new capabilities from the policy engine, GitOps engine or observability layer. The new products, Portainer-Run, IDP, Command and AiGrid, are Kubernetes-only.

How long will Portainer 2.45 LTS get patches?

The lifecycle policy in Portainer's documentation lists May 2027 as the end of support and maintenance for 2.45 LTS. The 3.0 announcement says the 2.x line will keep receiving security updates, bug fixes and selective back-ports, without giving an end date. That lifecycle table still lists 2.46 to 2.51 releases that the announcement contradicts, so treat May 2027 as the published date rather than a guarantee.

What is Portainer D2K and what does it not support?

D2K is an MIT-licensed Docker-to-Kubernetes translator: it exposes the Docker Engine API and turns each call into Kubernetes objects inside one namespace. Per its README, it ignores the Compose build directive, does not support docker build, load, save or buildx, does not support macvlan or ipvlan networks, has no equivalent for host networking or static IP and MAC addresses, does not enforce network isolation between stacks, and turns bind mounts into hostPath volumes that are unreliable in multi-node clusters.

What is the best free Portainer alternative for Docker?

It depends on what you use it for. For several servers and several people, Komodo (GPL-3.0) has no server limit and includes roles and OIDC, although it needs MongoDB or FerretDB. For one person editing compose files, Dockge (MIT) is the simplest, but it supports a single account. For deploying your own apps from git with a proxy and certificates, Coolify (Apache-2.0). Dockhand is the most complete UI, but its commercial licensing is ambiguous.

Can Coolify replace Portainer?

Only if what you do in Portainer is deploy your own applications. Coolify is a self-hosted PaaS: it deploys from git with Nixpacks, Railpack, Dockerfile or Docker Compose, sets up Traefik or Caddy with certificates and schedules database backups. It is not designed to manage containers created by hand, its documentation recommends a fresh server, and its Docker Swarm support is deprecated and will be removed in Coolify v5.

Is Dockhand free for commercial use?

It is unclear, because its two license texts contradict each other. The repository's LICENSE.txt is the Business Source License 1.1 with a grant that permits internal business use in production, as long as it is not offered as a SaaS. The license terms on dockhand.pro instead require a paid license for commercial users in production or on shared instances, and the pricing table puts the commercial usage license in the SMB plan at $499 per host per year. Personal use is free with no ambiguity.

GitHub Actions in Fall 2026: What Breaks (and Why node20 Isn't the Problem)

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

On 23 September 2026 GitHub removes Node 20 from the Actions runners, and almost everyone is reading that as “my actions with using: node20 are going to fail.” They are not. Since 16 June the runner has been rewriting node20 to node24 before it executes anything, and it does the same with node12 and node16. What goes away on the 23rd is the escape hatch: the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION variable stops working.

That inverts who is at risk. If your CI has been green since June without that variable, the 23rd changes nothing for you on GitHub-hosted runners. The ones that break are precisely the teams that already hit an action that can’t handle Node 24, set the variable to keep moving, and filed the real fix under later. And around that date there are four more with real consequences: the self-hosted runner minimum version (25 September), retention for checks and runs (1 October), the macos-14 brownouts (October) and its retirement (2 November).

I checked this against the runner’s source code and against this site’s own CI, which uses two node20 actions. Everything below comes with its source.

The calendar, by date

Date	What changes	What breaks	How to detect it
14, 16 and 18 Sep (11:00-15:00 ET)	Brownouts ahead of the self-hosted runner minimum version	Outdated runners cannot register or run jobs during the window	Runner deprecations API (below)
17 Sep	`ubuntu-22.04` and `ubuntu-22.04-arm` enter deprecation	Nothing fails yet; queues may be longer	`grep` for the label
21-30 Sep	`windows-11-arm` moves to the Visual Studio 2026 image	The toolchain underneath changes	`grep windows-11-arm`
23 Sep	Node 20 leaves the runners	`ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION` is ignored; Linux ARM32 runners lose support	`grep` for the variable
25 Sep	Self-hosted runner minimum version is enforced	Registering requires ≥ 2.329.0; a runner that doesn’t install each release within 30 days stops receiving jobs	Deprecations API
1 Oct	Actions retention now covers checks, workflow runs and statuses	Anything past your retention period (90 days by default) is deleted	Repo/org retention setting
5-31 Oct	Eight `macos-14` brownouts	Jobs scheduled inside the window fail	`grep macos-14`
2 Nov	`macos-14` retired	Jobs with that label terminate with an error	`grep macos-14`
17 Apr 2027	`ubuntu-22.04` retired (brownouts before, in March and April)	Jobs terminate with an error	`grep` for the label

1. Node 20: what actually happens on 23 September

What the notice says

GitHub’s changelog post from 19 September 2025, with an editor’s note dated 25 August 2026, sets two dates: from 16 June 2026 runners use Node 24 by default, and the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true opt-out back to Node 20 “will only work until we upgrade the runner and remove Node20 on September 23rd, 2026.” It adds two platform limits: Node 24 is incompatible with macOS 13.4 and lower, and it has no official ARM32 support.

What the notice does not explain is what happens to an action whose action.yml still says using: node20. That lives in the code.

What the runner code says

In HandlerFactory.cs (identical at tag v2.337.0, the current release), the runner does two things before launching a JavaScript action:

If the action declares node12 or node16, it bumps it to node20.
If it ends up on node20, it asks NodeUtil.DetermineActionsNodeVersion which version to use.

That function has three phases, driven by feature flags on GitHub’s side:

// Phase 3: Always use Node 24 regardless of environment variables
if (requireNode24)
{
    return (Constants.Runner.NodeMigration.Node24, null);
}
// ...
// Phase 2: Node 24 is the default
if (useNode24ByDefault)
{
    if (allowUnsecureNode)
    {
        return (Constants.Runner.NodeMigration.Node20, null);
    }
    return (Constants.Runner.NodeMigration.Node24, null);
}

PR #3948, which introduced this, is blunt about it: in phase 3, “All actions use Node 24” and “No opt-out options available.” No branch returns an error for declaring node20. The action runs on a different Node, which is very different from not running.

Note the order too: node12 → node20 → node24. An old action with using: node16 (for example actions/checkout@v3) ends up on Node 24 as well.

The proof: this site’s CI

This blog’s CI workflow uses actions/checkout@v4 and actions/setup-node@v4. The official action.yml files at those tags declare using: node20; from v5 onward they declare node24 (I checked tags v4 through v7 of both). The run on 11 September, on runner 2.337.0 with the ubuntu-24.04 image, finished green with this annotation:

Node.js 20 is deprecated. The following actions target Node.js 20 but are being
forced to run on Node.js 24: actions/checkout@v4, actions/setup-node@v4.

And in the log of those two actions’ steps, this line:

Node 20 is being deprecated. This workflow is running with Node 24 by default.
If you need to temporarily use Node 20, you can set the
ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true environment variable.

The same annotation appears on the very first run of that workflow, on 23 August. In other words, my two node20 actions have never run on Node 20 in this CI, and I didn’t touch anything to make that happen. 23 September doesn’t change their runtime, because that change already happened in June. Bumping them to v5 or later clears the annotation, and it’s worth doing, but there’s no clock on it.

What it looks like when it does break

There are three real ways to fail, and none of them is a GitHub message saying “Node 20 no longer exists.”

You had the variable set. Some action of yours tripped on Node 24 after 16 June, you set ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true, and it stayed on Node 20. In phase 3 the runner ignores the variable without telling you: the requireNode24 branch returns null as its message. The action goes back to Node 24, and the error you see is its own code’s error, the same one you saw the first time. One hint that phase 3 is live: with the current runner code, the “If you need to temporarily use Node 20…” line disappears from the log, because it is only printed while Node 24 is the default but not yet mandatory.

The action uses something Node 24 removed. Per the Node 24 deprecations table and the 24.0.0 release notes, these reached end-of-life in that release:

API	Status in Node 24	How it fails
`tls.createSecurePair()`	Removed (DEP0064)	`TypeError: ... is not a function` when called
`fs.truncate()` with a file descriptor	Removed (DEP0081)	Throws `ERR_INVALID_ARG_TYPE`: it expects a path. Use `fs.ftruncate()`
`dirent.path`	Removed (DEP0178)	Doesn’t throw on its own: the property is gone and you read `undefined`. Use `dirent.parentPath`
`OutgoingMessage.prototype._headers` / `_headerNames`	Removed (DEP0066)	You read `undefined`. Use `getHeaders()`

dirent.path is the sneakiest one on the list, because reading it throws nothing: the failure shows up later, wherever that path gets used, or never, if it’s only concatenated into a string and comes out as undefined/file. If you maintain an action that walks directories, search for that property before you trust the green check.

Your self-hosted runner can’t run Node 24. On Linux ARM32, the same NodeUtil.cs has a kill switch that fails the step with:

Linux ARM32 runners are no longer supported. Please migrate to a supported platform.

Before it’s flipped, the runner keeps those actions on Node 20 with a warning whose default date is the Node 20 removal date: “Linux ARM32 runners are deprecated and will no longer be supported after September 23rd, 2026.” GitHub hasn’t published the exact day the switch flips; the changelog only says ARM32 loses support after the Node 20 deprecation. On macOS, Node 24’s BUILDING.md requires macOS 13.5 or later.

2. The audit: what to look for and where

In one repository

Run this from the root:

# 1. The switch that stops working on 23 September
grep -rn 'ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION' .github/

# 2. Image labels with a date. No "runs-on:" on purpose,
#    so matrices show up too (os: [ubuntu-22.04, ...])
grep -rnE 'ubuntu-22\.04|macos-14|windows-11-arm' .github/

# 3. Your own or local actions that declare an old Node
grep -rnE --include=action.yml --include=action.yaml \
  "using:[[:space:]]*['\"]?node(12|16|20)" .

Search 2 has a blind spot: runs-on: ${{ vars.RUNNER }} or a label passed as an input to a reusable workflow won’t show up in any grep. For those, the log is the source of truth. The “Set up job” step prints the real image:

gh run view <run-id> --log | grep -m1 'Image:'
# Image: ubuntu-24.04

If the matrix is long or nested, converting it to JSON and filtering it with jq is usually faster than reading the YAML by eye:

To find out which runtime each third-party action you use declares, including SHA-pinned ones, you have to read its action.yml at that exact ref. This script does it with gh:

grep -rhoE "uses:[[:space:]]*['\"]?[^[:space:]'\"#]+@[^[:space:]'\"#]+" .github/ \
  | sed -E "s/uses:[[:space:]]*['\"]?//" | sort -u \
  | while read -r ref; do
      spec=${ref%@*}; ver=${ref#*@}
      case "$spec" in ./*|docker://*) continue ;; esac
      repo=$(cut -d/ -f1-2 <<<"$spec"); sub=$(cut -d/ -f3- <<<"$spec")
      for f in action.yml action.yaml; do
        rt=$(gh api "repos/$repo/contents/${sub:+$sub/}$f?ref=$ver" --jq .content 2>/dev/null \
             | base64 -d | grep -E '^[[:space:]]*using:' | tr -d " '\"" | cut -d: -f2)
        [ -n "$rt" ] && { echo "$rt  $ref"; break; }
      done
    done

On this repo it prints:

node20  actions/checkout@v4
node20  actions/setup-node@v4

It handles subpaths (github/codeql-action/init@v3) and SHAs. A SHA pointing at a node20 release doesn’t fail on the 23rd, for the same reason @v4 doesn’t: the runner forces it onto Node 24. What’s different with a SHA is how it gets updated: nothing moves on its own, so Dependabot or a human has to bump it.

One warning before bumping a major: read the release notes. actions/setup-node v5 turned on automatic caching when package.json has a packageManager field, and v6 limited it to npm. If you already pass cache: npm explicitly, as my CI does, it doesn’t affect you.

Across an organization

GitHub code search reaches every repo at once:

gh search code --owner YOUR_ORG 'ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION'
gh search code --owner YOUR_ORG 'ubuntu-22.04 path:.github/workflows'
gh search code --owner YOUR_ORG 'macos-14 path:.github/workflows'
gh search code --owner YOUR_ORG node20 --filename action.yml

Two limits of the code search API that will bite you: it only searches the default branch (a workflow on a release branch won’t show up) and it allows 10 requests per minute. While preparing this post I hit HTTP 403: API rate limit exceeded as soon as I chained a handful of searches; add a sleep between them if you automate it.

3. Self-hosted runners: two dates in three days

If you only use GitHub-hosted runners, skip this section. If you run your own, 25 September matters more than the 23rd.

The 12 June changelog post resumes enforcement of two rules on github.com:

To register (or re-register) a runner you need version 2.329.0 or later.
To keep running jobs, the runner must install each new release within 30 days of its publication. “A runner pinned to 2.329.0 that never updates again will not pick up jobs.”

Full enforcement begins on 25 September 2026 (the notice’s table labels that date as GitHub Enterprise Cloud, and the same notice states the change applies to github.com), with brownouts first: on 14, 16 and 18 September, from 11:00 AM to 3:00 PM Eastern, out-of-date runners can neither register nor run jobs. What you see, per the notice, is that “workflows targeting unsupported runners may remain queued or fail.”

The way to find out when your version expires is an endpoint GitHub added on 3 September. I queried it today:

gh api repos/OWNER/REPO/actions/runners/deprecations/2.335.1
# {"runner_version":"2.335.1","runtime_deprecates_at":"2026-09-24T15:30:55Z"}

gh api repos/OWNER/REPO/actions/runners/deprecations/2.337.0
# {"runner_version":"2.337.0","runtime_deprecates_at":null}

A runner on 2.335.1 falls out of support on 24 September, so by the time full enforcement starts on the 25th it no longer gets jobs. You get the installed version on the machine itself with ./config.sh --version.

The self-hosted checklist, in order:

Update the runner to the current release and leave auto-update on. If it’s off, you need a manual cadence shorter than 30 days.
Rebuild the images, VM templates and containers you create runners from. The changelog asks you to recreate runners built from older cached images or templates: if the image ships a runner older than 2.329.0, it won’t register.
Linux ARM32: move to arm64. Node 24 has no official support there, the runner’s linux-arm package only bundles the Node 20 binary (externals.sh), and the code that fails the step is already in the runner.
macOS 13.4 or earlier: upgrade the OS. GitHub lists Node 24 as incompatible with those versions.
Actions that already declare node24 (such as actions/checkout@v5) require runner v2.327.1 at minimum. If you’ve done step 1, you already have it.

4. Retention, 1 October: history gets deleted

This change breaks no build, but it deletes data. According to the 27 August changelog post, starting 1 October 2026 checks, workflow runs and statuses follow the same retention setting that already governed artifacts and logs, 90 days by default. Until now they were kept for “400+ days” regardless of your configuration.

For public repositories the maximum is 90 days.
The change is not retroactive: raising retention later won’t restore anything.
Check and workflow run metadata isn’t billed as storage; the associated artifacts and logs are.

What breaks is anything that reads that history beyond your period: deployment metrics computed from gh run list, audits that link to a specific run, quarterly reports. Export what you need before 1 October.

What the changelog does not say: what happens to a pull request open for more than 90 days whose required check expires. I couldn’t find it documented. If you have long-lived PRs under branch protection, look at them after 1 October before assuming anything.

5. Images: macos-14 has a date, ubuntu-22.04 doesn’t yet

macos-14 (actions/runner-images#13518): deprecation started on 6 July and support ends on 2 November 2026. Before that there are eight brownouts during which jobs fail: 5, 12, 16, 19, 23, 26, 29 and 30 October, each from 14:00 UTC to 00:00 UTC the next day. It covers macos-14, macos-14-large and macos-14-xlarge. The replacement is macos-15, macos-26 or macos-latest, which started pointing to macOS 26 with the migration that began on 15 June.

ubuntu-22.04 (actions/runner-images#14254): on 17 September deprecation only begins. The issue warns about longer queue times at peak hours, not failures. Retirement is on 17 April 2027, with brownouts that the issue schedules for March and April (no year given, but they fall before the retirement). It also covers ubuntu-22.04-arm. The replacement is ubuntu-24.04, ubuntu-26.04 or ubuntu-latest.

If someone tells you ubuntu-22.04 breaks this week, it doesn’t. Migrate calmly, but don’t leave it for March.

What’s in the changelog and breaks nothing

cache-mode (10 September): a new key to limit cache access per workflow or job. It’s opt-in: workflows that don’t set it “continue to use the existing secure defaults.”
The separate Code Quality path (20 August): only affects you if you have reports filtering on dynamic/github-code-scanning/codeql or on the github-advanced-security actor.
actions/checkout and pull_request_target (18 June): this one does break, but it already happened. Since 20 July the floating tags, @v4 included, refuse to check out fork code in pull_request_target. If your workflow depended on that, it’s already red. It’s the same family of risk I covered in the worm that got in through npm trusted publishing.

What I’m doing with my CI

Nothing urgent. actions/checkout@v4 and actions/setup-node@v4 have been running on Node 24 since June, the workflow doesn’t use the opt-out variable, it runs on ubuntu-latest (currently ubuntu-24.04) and on GitHub-hosted runners. 23 September changes nothing for it.

I am going to bump both actions to their current major, for two reasons unrelated to the date: a permanent yellow annotation trains you to ignore annotations, and an action its authors no longer test on the runtime it actually runs on is debt. If you’re also thinking about your own project’s Node rather than the actions’, I covered that in what breaks when upgrading to Node 26.

Frequently asked questions

What happens to GitHub Actions on 23 September 2026?

GitHub removes Node 20 from the runners. Since 16 June 2026 runners had already been running actions on Node 24 by default, and ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true let you go back to Node 20. From 23 September that variable stops working and every JavaScript action runs on Node 24. Self-hosted runners on Linux ARM32 lose support, because Node 24 has no official support for that platform.

Does an action that declares using: node20 fail after 23 September?

Not for declaring it. The runner code (HandlerFactory.cs and NodeUtil.cs in actions/runner) rewrites node12 and node16 to node20, and node20 to node24; in the final phase it ignores the environment variables and always picks Node 24, without returning an error. The action fails if its code uses something Node 24 removed, such as tls.createSecurePair or fs.truncate with a file descriptor, or if it runs on a self-hosted Linux ARM32 runner or on macOS 13.4 or earlier. The logs show the annotation: The following actions target Node.js 20 but are being forced to run on Node.js 24.

Do I have to update actions/checkout@v4 and actions/setup-node@v4?

It's a good idea, but no date forces it. The v4 tags of both declare node20 and v5 onward declare node24. On GitHub-hosted runners, the v4 tags have already been running on Node 24 since June and keep working. When bumping setup-node, read the release notes: v5 turned on automatic caching when package.json has packageManager, and v6 limited it to npm.

How do I find affected workflows across my organization?

With GitHub code search: gh search code --owner YOUR_ORG with ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION, with ubuntu-22.04 path:.github/workflows, with macos-14 path:.github/workflows, and with node20 --filename action.yml for your own actions. The API only searches the default branch and allows 10 requests per minute. Labels that come from variables or expressions don't show up in any search: for those, check the Image: line of the Set up job step in the log.

Does ubuntu-22.04 break on 17 September 2026?

No. On 17 September deprecation only begins, and the notice talks about longer queue times at peak hours. Jobs start failing during the brownouts that issue 14254 in actions/runner-images schedules for March and April, before the image is retired on 17 April 2027. The one with a date this fall is macos-14: brownouts in October and retirement on 2 November 2026.

What do self-hosted runners need to do before 25 September?

Update the runner. From 25 September 2026 GitHub requires version 2.329.0 to register a runner, and each new release must be installed within 30 days to keep receiving jobs. There are brownouts first on 14, 16 and 18 September, from 11:00 AM to 3:00 PM Eastern. The endpoint GET /repos/OWNER/REPO/actions/runners/deprecations/VERSION returns when your version stops running jobs. Also rebuild the images you create runners from.

What changes with GitHub Actions retention on 1 October 2026?

Checks, workflow runs and statuses start following the artifact and log retention setting, which defaults to 90 days; before, they were kept for more than 400 days. For public repositories the maximum is 90 days, and the change is not retroactive. If you have metrics or audits that read old runs, export the data before that date.

WhatsApp API, October 1: What Changes in Your Code When Meta Starts Billing Service Messages

Marco Orta — Sun, 13 Sep 2026 00:00:00 GMT

On October 1, 2026 the WhatsApp status webhook does not change shape. It changes meaning. The same pricing object that arrives today with "type": "free_customer_service" starts arriving with "type": "regular" in two cases that stay free through September 30: service messages from the 1,001st of the month on each business phone number, and utility templates you send inside the 24-hour customer service window. If your code hardcodes the service rate at zero, decides with billable, or drops statuses whose category it does not recognize, your cost report will say you spent nothing while Meta bills you.

There is plenty of coverage of the new prices. This post is about the other half: which fields to read, which values each one takes according to Meta’s documentation, how to count the free tier without inventing the rule, and what to check before September 30. The figures come from Meta’s Mexico rate card, in both of the currencies it publishes that row in: MXN and USD.

What is billed before and after October 1

Per delivered message to a +52 (Mexico) phone number. The numbers come from the official rate cards “effective July 1, 2026” and “effective October 1, 2026”, which I downloaded on September 13 from Meta’s pricing page (Mexico row). Meta publishes a separate card per billing currency; I quote the MXN and USD cards as published and do not convert between them. Use the card that matches your WABA’s currency, and the row that matches your recipients’ country.

Message	Through Sep 30 (MXN / USD)	From Oct 1 (MXN / USD)	`pricing.type` from Oct 1
Marketing template	0.5614 / 0.0305	0.7298 / 0.0397	`regular`
Utility template outside the window	0.1565 / 0.0085	0.1565 / 0.0085	`regular`
Utility template inside the 24h window	free	0.1565 / 0.0085, from the first one	`regular`
Authentication template	0.1565 / 0.0085	0.1565 / 0.0085	`regular`
Service (non-template), 1st to 1,000th of the month per number	free	free	`free_customer_service`
Service (non-template), 1,001st onward	free	0.1565 / 0.0085	`regular`
Anything inside the 72h free entry point window	free	free	`free_entry_point`

Three details that change how you write the code:

The switch happens at 12am in your WABA’s timezone, not UTC. The pricing page says so for the whole October package: “Rate updates below apply as of 12am by WhatsApp Business Account (WABA) timezone”.
The 1,000 free tier covers service messages only. Meta describes it as “a free monthly tier of 1,000 service messages per business phone number”, with no roll-over. It announces no free tier for utility: a utility template inside the window is billed from the first one.
Mexico’s marketing rate rises about 30% (0.5614 → 0.7298 MXN; 0.0305 → 0.0397 USD). It is the only rate change in that row. Volume tiers will not help a small business either: in the October tiers card, Mexico utility is charged at list rate from message 0 to 1,000,000 a month, and service messages have no tiers at all per the non-template messages page.

The real payload, and the fields that matter

This is a service message delivered after the monthly free tier is used up. The envelope follows the status messages webhook reference, and the pricing object is verbatim the one Meta publishes for “Paid service message”. IDs and phone numbers are the reference’s own example values; the timestamp is October 14, 2026.

{
  "object": "whatsapp_business_account",
  "entry": [
    {
      "id": "102290129340398",
      "changes": [
        {
          "value": {
            "messaging_product": "whatsapp",
            "metadata": {
              "display_phone_number": "15550783881",
              "phone_number_id": "106540352242922"
            },
            "statuses": [
              {
                "id": "wamid.HBgLMTY1MDM4Nzk0MzkVAgASGBQzQUFERjg0NDEzNDdFODU3MUMxMAA=",
                "status": "delivered",
                "timestamp": "1792002600",
                "recipient_id": "16505551234",
                "pricing": {
                  "billable": true,
                  "pricing_model": "PMP",
                  "type": "regular",
                  "category": "service"
                }
              }
            ]
          },
          "field": "messages"
        }
      ]
    }
  ]
}

The same message in September, or inside the free tier, carries "billable": false and "type": "free_customer_service". A utility template inside the window flips the same way: free_customer_service through September 30, regular from October 1, with "category": "utility".

`pricing.type`: the one that decides

This field tells you why a message was or was not billed. The status reference documents three values:

regular: billed.
free_customer_service: free because it went out inside the customer service window. From October, that includes being inside the 1,000 free tier.
free_entry_point: free because of the 72-hour window opened by Click-to-WhatsApp ads and Facebook Page call-to-action buttons.

The pricing page adds a fourth that the reference (last updated May 21) does not list yet: free_group_customer_service, for group messages.

`pricing.category`: which rate was applied

Reference values: authentication, authentication-international, marketing, marketing_lite, referral_conversion, service and utility. Watch authentication-international: in pricing.category it uses a hyphen, while the conversation category in conversation.origin.type uses an underscore. The pricing page adds group_service and group_utility.

The practical consequence: do not validate these fields against a closed list. If your parser drops a status because the category is not in your enum, that message ends up unpriced in your database while Meta still bills it.

`pricing.billable`: do not decide with it

The reference is explicit: “The billable property will be deprecated in a future versioned release. Use pricing.type and pricing.category together to determine whether a message is billable and, if so, its billing rate.” Today billable and type agree. The day Meta removes it in a new Graph API version, an if (billable === false) return 0 turns into “everything is billed” or “nothing is billed”, depending on how you treat undefined.

When the object arrives, and when it counts

Per the reference syntax, pricing is “only included with sent status, and one of either delivered or read status”. The v24.0 example adds that it can show up only on delivered and not on sent. So you get it twice or once, and you must deduplicate by wamid.
Meta bills what is delivered, not what is sent (“only when the message is delivered (vs. sent)”). And delivered may never arrive: if the user has the chat open, Meta sends read directly. Count a message as delivered when either delivered or read shows up.
Since v24.0 the conversation object is omitted unless the message is inside a free entry point window. If your code took the category from conversation.origin.type, it was already behind.

The four bugs that make your report say zero

While reviewing the WhatsApp agent I have in development for this post, I found two of these in my own code. All four are easy to ship:

A rate table with no effective date. A service: 0 constant is correct through September 30 and wrong from October 1, even though the webhook already says regular. Meta can only change pricing on the first day of a quarter (January, April, July, October), with one month’s notice for a rate card update: model the card with its effective date.
Deciding with billable. Works today; breaks when Meta retires it.
A category allowlist. group_service, free_group_customer_service or the hyphen in authentication-international end up as “no category” and add zero to your total.
Counting every status. If you add to the total on every webhook that carries pricing, one message counts twice (sent + delivered), and a message that failed after being sent counts even though Meta does not bill it.

Code: counting billable messages per number and per month

The approach mirrors the cost ledger in my agent: one row per outbound message, filled in by whatever each status carries, with cost computed at read time. It targets Cloudflare D1 (SQLite), but the SQL is portable.

The table first. category and pricing_type are stored exactly as received, with no allowlist:

CREATE TABLE wa_outbound (
  wamid           TEXT PRIMARY KEY,
  phone_number_id TEXT NOT NULL,
  month           TEXT NOT NULL,              -- 'YYYY-MM' in the WABA timezone
  delivered       INTEGER NOT NULL DEFAULT 0, -- 1 once `delivered` or `read` arrives
  category        TEXT,                       -- pricing.category, not normalized
  pricing_type    TEXT                        -- pricing.type, not normalized
);
CREATE INDEX wa_outbound_month ON wa_outbound (phone_number_id, month);

Then what you do with each statuses[] entry. phone_number_id comes from value.metadata.phone_number_id, which is the unit the free tier is counted on:

type Open<T extends string> = T | (string & {}); // autocompletes, but accepts whatever Meta adds

export interface StatusPricing {
  /** Meta will deprecate it: decide with `type` + `category`. */
  billable?: boolean;
  pricing_model: Open<'PMP' | 'CBP'>;
  type: Open<'regular' | 'free_customer_service' | 'free_entry_point' | 'free_group_customer_service'>;
  category: Open<'service' | 'utility' | 'marketing' | 'marketing_lite' | 'authentication' | 'authentication-international' | 'referral_conversion' | 'group_service' | 'group_utility'>;
}

export interface WebhookStatus {
  id: string; // wamid
  status: Open<'sent' | 'delivered' | 'read' | 'failed' | 'played'>;
  timestamp: string; // epoch seconds, as a string
  recipient_id: string;
  pricing?: StatusPricing;
}

/** 'YYYY-MM' in your WABA timezone, e.g. 'America/Mexico_City'. */
export function monthKey(epochSeconds: number, timeZone: string): string {
  return new Intl.DateTimeFormat('en-CA', { timeZone, year: 'numeric', month: '2-digit' })
    .format(new Date(epochSeconds * 1000))
    .slice(0, 7);
}

const DELIVERED = new Set(['delivered', 'read']); // `read` without `delivered` still means delivered

export async function applyStatus(db: D1Database, phoneNumberId: string, s: WebhookStatus, timeZone: string) {
  await db
    .prepare(
      `INSERT INTO wa_outbound (wamid, phone_number_id, month, delivered, category, pricing_type)
       VALUES (?1, ?2, ?3, ?4, ?5, ?6)
       ON CONFLICT(wamid) DO UPDATE SET
         month        = CASE WHEN excluded.delivered = 1 AND delivered = 0 THEN excluded.month ELSE month END,
         delivered    = MAX(delivered, excluded.delivered),
         category     = COALESCE(excluded.category, category),
         pricing_type = COALESCE(excluded.pricing_type, pricing_type)`,
    )
    .bind(
      s.id,
      phoneNumberId,
      monthKey(Number(s.timestamp), timeZone),
      DELIVERED.has(s.status) ? 1 : 0,
      s.pricing?.category ?? null,
      s.pricing?.type ?? null,
    )
    .run();
}

The ON CONFLICT does the dirty work: repeated statuses do not duplicate, pricing is kept whether it came on sent or on delivered, and the month that counts is the delivery month (a message sent at 11:59pm on September 30 and delivered on October 1 lands in October).

Finally, the monthly bill. The rate card carries a date, and what decides whether a message is billed is type, not your counter:

const FREE_SERVICE_PER_MONTH = 1000;

/** Mexico card in MXN per delivered message. One entry per quarter with changes. */
const MX_RATES_MXN: Array<{ from: string; rates: Record<string, number> }> = [
  { from: '2026-07', rates: { marketing: 0.5614, utility: 0.1565, authentication: 0.1565 } },
  { from: '2026-10', rates: { marketing: 0.7298, utility: 0.1565, authentication: 0.1565, service: 0.1565 } },
];

const ratesFor = (month: string) => MX_RATES_MXN.findLast((card) => card.from <= month)?.rates ?? {};

export async function monthlyBill(db: D1Database, phoneNumberId: string, month: string) {
  const { results } = await db
    .prepare(
      `SELECT category, pricing_type, COUNT(*) AS n FROM wa_outbound
       WHERE phone_number_id = ? AND month = ? AND delivered = 1
       GROUP BY category, pricing_type`,
    )
    .bind(phoneNumberId, month)
    .all<{ category: string | null; pricing_type: string | null; n: number }>();

  const rates = ratesFor(month);
  let total = 0;
  let serviceDelivered = 0;
  let paidService = 0;
  const unpriced: Record<string, number> = {};

  for (const { category, pricing_type, n } of results) {
    if (!category || !pricing_type) {
      unpriced['(no pricing)'] = (unpriced['(no pricing)'] ?? 0) + n;
      continue;
    }
    // Meta does not document whether entry point messages use up the tier: not counted here.
    if (category === 'service' && pricing_type !== 'free_entry_point') serviceDelivered += n;
    if (pricing_type !== 'regular') continue; // free: window, tier or entry point
    if (category === 'service') paidService += n;

    const rate = rates[category];
    if (rate === undefined) {
      unpriced[category] = (unpriced[category] ?? 0) + n; // billed and you have no rate: do not add it as 0
      continue;
    }
    total += n * rate;
  }

  return {
    total: Math.round(total * 100) / 100,
    serviceDelivered,
    freeServiceLeft: Math.max(0, FREE_SERVICE_PER_MONTH - serviceDelivered),
    paidService,
    unpriced,
  };
}

If your WABA bills in USD, swap the card for the USD row (0.0305 / 0.0085 / 0.0085 from July, 0.0397 / 0.0085 / 0.0085 / 0.0085 from October). With that in place, alerting is one line in a daily cron: fire when freeServiceLeft drops below 200, when the month’s first paidService appears, or when unpriced is not empty. And if paidService is above zero while serviceDelivered is under 1,000, your counter and Meta disagree: another app sending from the same number, lost webhooks, or a month boundary in a different timezone. Meta wins.

To reconcile at month end, the WABA’s pricing_analytics field accepts the PHONE, PRICING_CATEGORY and PRICING_TYPE dimensions. Two caveats from the same page: the data is approximate (“may differ from what’s shown on invoices”), and COST is not returned if your WABA shares a Solution Partner’s credit line. Also, that reference (last updated June 11) still describes SERVICE as “Messages that were not charged”; the non-template messages page already shows the query with REGULAR + SERVICE.

What it costs: a small business with 600 conversations a month

A clinic or a repair shop with an agent answering WhatsApp, one phone number, customers on +52, and no Click-to-WhatsApp ads. Per month:

600 conversations with 5 service messages from the agent each: 3,000 service messages.
600 order or appointment confirmations as utility templates, sent inside the window.
400 reminders as utility templates, sent outside the window.
One marketing campaign to 500 contacts.

I assume everything is delivered; in practice it comes out slightly lower, since Meta only bills delivered messages. List rates, before any taxes.

September (July rate card):

Line	Math	MXN	USD
Service	3,000 × 0	0.00	0.00
Utility inside the window	600 × 0	0.00	0.00
Utility outside the window	400 × 0.1565 MXN / 0.0085 USD	62.60	3.40
Marketing	500 × 0.5614 MXN / 0.0305 USD	280.70	15.25
Total		343.30	18.65

October (October rate card):

Line	Math	MXN	USD
Service	(3,000 − 1,000) = 2,000 × 0.1565 MXN / 0.0085 USD	313.00	17.00
Utility inside the window	600 × 0.1565 MXN / 0.0085 USD	93.90	5.10
Utility outside the window	400 × 0.1565 MXN / 0.0085 USD	62.60	3.40
Marketing	500 × 0.7298 MXN / 0.0397 USD	364.90	19.85
Total		834.40	45.35

Meta’s bill goes from 343.30 to 834.40 MXN on the peso card (18.65 to 45.35 on the dollar card): 491.10 MXN or 26.70 USD more per month. Nobody goes under over that, but it is 2.4 times September, and 406.90 of those 491.10 pesos (over 80%) come from two lines that cost zero today.

Where the real lever is: your code

Switching the in-window utility confirmations to free-form text saves nothing in this example: in Mexico the service rate and the utility rate are the same, and the free tier is already used up. It only helps businesses that stay under 1,000 service messages a month.

What actually moves the number is how many messages your agent sends per reply. Plenty of AI agents split each answer into three or four bubbles because it reads more naturally. From October 1, every bubble past the 1,000th is a charge. If the same agent answers with 3 messages per conversation instead of 5:

600 × 3 = 1,800 service messages.
(1,800 − 1,000) = 800 × 0.1565 = 125.20 MXN (800 × 0.0085 = 6.80 USD), versus 313.00 MXN (17.00 USD).
Savings: 187.80 MXN or 10.20 USD a month, without touching a single price.

If some of your customers arrive through Click-to-WhatsApp ads, replying within the first 24 hours opens the 72-hour free entry point window, and everything in it comes back as free_entry_point. Meta confirms that window is unchanged for message delivery.

What happens with no payment method

Meta has two wordings here, from different dates, and they are worth reading together.

The non-template messages page, updated August 25, 2026, says:

For any Solution Provider or directly-integrated businesses that does not have a payment method on file by September 30, 2026, Meta will stop delivering service messages as of when they become charged on October 1, 2026. To avoid disruptions to your service messages, please add a payment method for your WhatsApp Business Account(s) by September 30, 2026.

The pricing page, updated September 10, 2026, which is where the free tier was introduced as new, is more specific:

If you do not have a payment method for your WhatsApp Business account: Meta will deliver your first 1,000 service messages each month but not deliver as of your 1,001st.

They do not contradict each other: the first says delivery stops “as of when they become charged”, and the second, written after the free tier was added, says that happens at the 1,001st message. In practice:

The date Meta gives for having a payment method in place is September 30. Do not wait for the first failure.
Without a payment method, your agent works normally until the number crosses 1,000 service messages for the month, and then stops delivering mid-month. For a busy business that can be a Tuesday afternoon.
In the pages I reviewed, Meta does not publish which error code the failed status carries in that case. Watch for a spike in failed on service messages from October 1.
The August notice is addressed to “Solution Provider or directly-integrated businesses”. If your WABA is billed through a solution provider, get written confirmation from them that the payment method is sorted before September 30.

Checklist before September 30

A payment method in Billing Hub for every WABA, or written confirmation from your provider if you are billed through one.
A tolerant parser: store pricing.type and pricing.category as received. Never drop a status because it carries group_service, free_group_customer_service or authentication-international.
Stop deciding with billable. Use type === 'regular' plus the rate for category.
A rate card with effective dates, loaded with the October card (Mexico marketing at 0.7298 MXN / 0.0397 USD). The next date Meta can change prices is January 1, 2027.
Count on delivered or read, once per wamid, grouped by phone_number_id and by month in your WABA timezone.
Alerts: fewer than 200 free service messages left, first regular service message of the month, categories with no rate, and a rise in failed.
Utility templates inside the window: from October 1 they are billed from the first one. If you send fewer than 1,000 service messages a month, free-form text inside the window can be free where the template costs.
Marketing versus utility templates: Meta bills the category a template has at the time of use, and can recategorize it. Subscribe to the template_category_update webhook, which warns you 24 hours before an automated category change.
Messages per reply: merge your agent’s bubbles. It is the cheapest lever in the example.
Monthly reconciliation against pricing_analytics, knowing it is approximate.

Further reading:

Build an AI agent on WhatsApp for your small business (Laravel + OpenAI): the webhook, conversation memory and the 24-hour window rules, from scratch.

Frequently asked questions

What changes in the WhatsApp Business API on October 1, 2026?

Meta starts billing two kinds of message that are free today: service messages (non-template messages sent inside the 24-hour customer service window) from the 1,001st message each month per business phone number, and utility templates sent inside that window, which are billed from the first one. In Mexico both cost 0.1565 MXN (0.0085 USD) per delivered message. Mexico marketing also rises from 0.5614 to 0.7298 MXN (0.0305 to 0.0397 USD). The change applies at 12am in your WhatsApp Business account timezone.

How do I know from the webhook whether a WhatsApp message was billed?

Read pricing.type in the status messages webhook: regular means billed; free_customer_service, free_entry_point or free_group_customer_service mean it was free. pricing.category tells you which rate was applied. Do not rely on pricing.billable: Meta’s reference says it will be deprecated in a future versioned release and recommends using type and category together.

Are the 1,000 free WhatsApp service messages per account or per phone number?

Per business phone number. Meta says every business phone number receives 1,000 free service messages per month, that it charges from the 1,001st service message delivered that month, and that unused messages do not roll over. The free tier only covers service messages; utility templates inside the window have no free tier.

What happens if my WhatsApp Business account has no payment method on October 1?

According to Meta’s pricing page, updated September 10, 2026, Meta delivers your first 1,000 service messages each month and stops delivering from the 1,001st. The non-template messages page asks businesses to add a payment method in Billing Hub by September 30, 2026. If you are billed through a solution provider, confirm with them that the payment method is in place.

Does the pricing object arrive on every status webhook?

No. Per Meta’s reference, pricing is included with the sent status and with one of delivered or read, and in v24.0 it can appear only on delivered. Since Meta bills delivered messages and sometimes sends read without delivered, count each message once per wamid when delivered or read arrives, and keep the pricing from whichever status carried it.

How much will a small business in Mexico pay Meta from October?

It depends on volume. With 600 conversations a month at 5 service messages each, 600 utility confirmations inside the window, 400 utility reminders outside it and one marketing campaign to 500 contacts, the Meta bill goes from 343.30 MXN in September to 834.40 MXN in October at list rates, or from 18.65 to 45.35 USD on the USD card. Cutting the agent from 5 to 3 messages per conversation lowers the service line from 313.00 to 125.20 MXN.

Should I replace utility templates with free-form text inside the window?

Only if you send fewer than 1,000 service messages a month. In Mexico, service and utility cost the same from October 1, but service gets 1,000 free messages per month per number and utility does not. Once the tier is used up, it makes no difference. The bigger lever is usually having your agent send fewer messages per reply.

Validate Mexican RFC, CURP and CFDI Invoices from Claude, With No API Keys

Marco Orta — Fri, 11 Sep 2026 00:00:00 GMT

Ask an AI agent to validate a Mexican RFC and it will usually write a regex. Then it will reject XAXX010101000 — the RFC printed on every invoice issued to the general public — because that RFC does not satisfy its own check digit. The SAT assigned it by decree, and the modulus-11 algorithm asks for a 4 where the SAT wrote a 0.

That is the kind of detail an agent cannot be trusted to remember, and Mexican tax data is full of them. So I built mx-fiscal-mcp-server: an open-source MCP server that gives Claude (or Cursor, or any MCP client) eight read-only tools to validate RFC, CURP, CLABE and NSS with their real algorithms, read CFDI 4.0 invoices, ask the SAT whether an invoice is still valid, and look up the SAT’s code tables.

It needs no API keys, no CSD certificate and no PAC contract. This post covers the setup, what you can ask it, and the six details that a hand-rolled implementation gets wrong — including one I got wrong myself before release.

Setup in one line

The server is published on npm and in the official MCP Registry, so there is nothing to clone. For Claude Code:

claude mcp add mx-fiscal -- npx -y mx-fiscal-mcp-server

For Claude Desktop or Cursor, add it to claude_desktop_config.json or ~/.cursor/mcp.json:

{
  "mcpServers": {
    "mx-fiscal": {
      "command": "npx",
      "args": ["-y", "mx-fiscal-mcp-server"]
    }
  }
}

On Windows, use "command": "cmd" with "args": ["/c", "npx", "-y", "mx-fiscal-mcp-server"]. It needs Node.js 20 or newer.

It is built on the v2 MCP SDK, so it speaks the 2026-07-28 protocol revision and still serves the 2025-era clients that Claude Desktop, Claude Code and Cursor use today, from the same process. If you maintain a server yourself, I wrote up what changes when you migrate to 2026-07-28.

The eight tools

Tool	What it does
`validate_rfc`	RFC for individuals (13 characters) and companies (12): check digit, parsed fields, birth or incorporation date, and whether it is one of the SAT generics
`validate_curp`	18-character CURP: check digit, birth date, sex, state of birth and the century marker
`validate_clabe`	18-digit bank account number (CLABE): control digit, bank and plaza code
`validate_nss`	11-digit IMSS social security number with its Luhn digit
`generate_test_data`	1 to 100 coherent fake people or companies: RFC and CURP derived from the same name and birth date, CLABE from a real bank
`parse_cfdi`	CFDI 4.0 XML to JSON, with every catalogue code labelled, both RFCs validated and the totals checked
`cfdi_status`	Asks the SAT’s public status service whether the invoice exists, is cancelled or can be cancelled, and returns the result of its EFOS check (the 69-B list)
`sat_catalog_lookup`	Nine SAT code tables (tax regimes, CFDI uses, payment forms and methods, and more) by code or text

Only cfdi_status touches the network. The other seven never leave the process.

What you can ask it

A few prompts that work well, with the shape of what comes back:

“Is GODE561231GR8 a valid RFC? Decode it.” — kind (individual or company), the date encoded in it, and a legible reason for every failure: not just invalid, but “the final check digit does not match the modulus-11 result”.
“Generate 20 Mexican customers with valid RFC, CURP and CLABE for my seed file.” — every check digit holds, and the RFC and CURP of each record describe the same person.
“Read this invoice and tell me whether it’s still valid at the SAT.” — Claude calls parse_cfdi to label everything and check the arithmetic, then cfdi_status with the four values it needs.

That last one is the flow that saves the most time, and it hides most of the traps below.

Six details a regex gets wrong

1. The general-public RFC does not satisfy its own check digit

XAXX010101000 is the RFC for sales to the general public, and XEXX010101000 is for foreign residents. Run the modulus-11 algorithm on the first twelve characters of the first one and it asks for a 4. The second one happens to satisfy it.

A validator that only runs the algorithm rejects every invoice issued to the general public — which is why so many billing forms refuse them. A validator that only checks the shape accepts typos. The server reports the two facts separately: is_generic: true and check_digit_satisfied: false, and says in words why that combination is fine.

2. CLABE keeps the last digit of each product, not the sum of its digits

The CLABE control digit weights the first 17 digits with 3, 7, 1, 3, 7, 1… From each product it keeps the last digit — the product modulo 10 — so a 63 contributes 3. Then it sums, takes the sum modulo 10 and subtracts from 10 (a result of 10 means the digit is 0).

An implementation that copies Luhn does something else: when a product goes above 9, it adds up its digits, so the same 63 contributes 6 + 3 = 9. The two routes do not agree: for the 17 digits 09000000000000000, the CLABE algorithm gives 7 and the Luhn-style version gives 1. That is enough to accept mistyped account numbers and reject good ones.

3. The CURP’s 17th character carries the century

A CURP stores the birth year in two digits, so 31 could be 1931 or 2031. RENAPO resolves it with the 17th character: a digit means born before 2000, a letter means born in 2000 or later.

This is the one I got wrong. The first version of the server read that rule backwards, and because the birth date is itself decoded through that character, it reported a “disagreement between the marker and the date” on every valid CURP it saw. The test suite had captured the wrong message as expected behaviour. An independent review caught it before publication; the canonical test vector BOXW310820HNERXN09 now decodes, correctly, to 20 August 1931.

4. CURP state keys are RENAPO’s, not INEGI’s

Positions 12 and 13 of a CURP encode the state of birth, with RENAPO’s own keys: DF is Mexico City, MC is the State of Mexico and NE means born abroad. They match neither the INEGI state codes nor ISO 3166-2:MX, so a lookup against either table silently mislabels people.

5. The SAT status query is picky about the total

cfdi_status sends the SAT an expression built from four values: issuer RFC, receiver RFC, total and UUID. The total goes in the format the reference implementations use (nodecfdi and phpcfdi): six decimals with trailing zeros trimmed, but keeping at least one. So 1160.00 travels as 1160.0:

?re=TES150312DX2&rr=PELJ900521DK2&tt=1160.0&id=5A7B3C1D-9E2F-4A6B-8C0D-1E2F3A4B5C6D

A total that doesn’t follow that format, such as a hand-typed 1,160.00, can make the SAT answer No Encontrado — “not found” — for an invoice that exists. That is why the server screens the four values before spending a request, and recommends passing the whole XML so it derives them itself.

Two more rules live in the same query. An RFC containing & travels encoded as &, following the nodecfdi reference implementation. And an empty ValidacionEFOS field does not mean the issuer is on the 69-B list of companies that invoice simulated operations. The SAT’s documentation for the service defines the codes — 100 to 104 when the issuer or a third-party RFC on the invoice is listed (102 and 103 mean the issuer is not, only a third party is), 200 and 201 when neither is — but not an empty value, so the server reports an empty field as unknown, never as “listed”. Since version 1.0.2 it keeps the two questions apart: efos_state answers only for the issuer (100, 101 and 104 are listed; 102, 103, 200 and 201 are not_listed) and efos_third_party_state for third-party RFCs, with the raw code always in validacion_efos. Version 1.0.1 read 102 and 103 as “the issuer is listed”, which the SAT document contradicts. Either way, check the published 69-B list before acting on it.

6. The total includes local taxes

The arithmetic check — subtotal minus discount plus transferred taxes minus withheld taxes — is how you spot a tampered or broken invoice. But the CFDI 4.0 schema defines the total over federal and local taxes, and local ones live in a separate implocal complement. A hotel invoice with a state lodging tax looks off by exactly that tax if you ignore the complement. The server adds it in.

If you only want to open an invoice by hand, with no agent involved, the CFDI viewer that started on this site now lives on Siempre Contable (in Spanish).

Reading and verifying are different things

parse_cfdi reads the XML: header, issuer, receiver, every line item with its taxes, the tax totals and the digital stamp. It labels every code (G03 is Gastos en general, 601 is General de Ley Personas Morales), validates both RFCs and checks the arithmetic.

It does not verify the digital signature. A perfectly parseable invoice can be cancelled or fabricated wholesale, which is what cfdi_status is for. And an unreachable SAT is not an invalid invoice: the service has no status page and it does go down (its documentation states a capacity of up to 2 million queries an hour and asks callers not to raise their volume, but promises no availability). When it fails, the tool returns available: false with the reason — a statement about the SAT, never about the document — after a 10-second timeout and one retry.

The same honesty applies to identifiers. A check digit that adds up says the string is well formed and nothing more. Only the SAT can say an RFC is registered, and only RENAPO that a CURP belongs to someone; this server asks neither, and its wording never implies it did. Even the fake data is labelled carefully: it is generated from common names, so a generated CURP or phone number can coincide with a real person’s by chance.

What it deliberately does not do

It does not build, seal or stamp invoices. That half of Mexican e-invoicing needs your digital-seal certificate (CSD) and, for the stamp, a PAC, and it already has an MCP server: mcp-cfdi-mx, in Python, which builds, validates and seals CFDI 4.0 with your own CSD; the stamping itself still goes through a PAC. This one is the read half, which needs nothing, and the two complement each other.

Self-hosting it safely

Besides stdio, the server speaks stateless Streamable HTTP for shared or remote use:

TRANSPORT=http npx -y mx-fiscal-mcp-server

It is safe by default: it binds to 127.0.0.1 and only accepts localhost Host and Origin headers, which blocks DNS-rebinding attacks from a web page. To expose it behind a reverse proxy, set HOST=0.0.0.0, ALLOWED_HOSTS with your public hostname and MCP_AUTH_TOKEN for Bearer authentication. Don’t skip the token: an open instance relays requests to the SAT for anyone and can get your IP rate-limited.

Invoice XML is untrusted input, so a document that declares a DOCTYPE is refused before parsing (a CFDI never has one), and size and element-count caps bound the memory a single parse can take.

The check-digit arithmetic lives in mx-identifiers, a zero-dependency library tested against the public SAT, Banxico and RENAPO vectors, and the server has 51 offline unit tests plus a smoke test that calls every tool over the real protocol in both protocol eras. If you are looking for MCP servers in other areas, I keep a list of the best MCP servers for SEO, including my own.

Frequently asked questions

Does the server need a SAT account, a CSD certificate or an API key?

No. Every check-digit algorithm and every catalogue is public, and the SAT's CFDI status service — the one behind the QR code on printed invoices — is public and unauthenticated. The server only reads; it never stamps or cancels anything, so it needs no credentials of any kind.

Why does the SAT say 'No Encontrado' for an invoice that exists?

Usually because one of the four query values does not match what the SAT stored: a total in another format (it goes with six decimals and trailing zeros trimmed, keeping one, so 1160.00 travels as 1160.0), a thousands separator or a mistyped UUID. Passing the whole XML to cfdi_status lets the server derive the four values itself.

Is XAXX010101000 a valid RFC?

Yes. It is the SAT's generic RFC for sales to the general public, assigned by decree, and it appears on real invoices. It does not satisfy the modulus-11 check digit — the algorithm asks for a 4 — so validators without an explicit allow-list reject it. XEXX010101000, for foreign residents, is also generic and does satisfy the algorithm.

Can the generated test data belong to a real person?

By chance, yes. generate_test_data builds each record from common Mexican names and a random birth date, and a CURP is derived from exactly those fields, so a collision with a real person's CURP or phone number is possible. The data is meant for fixtures, seeds and demos; never send it to the SAT or a PAC, and never use it as a stand-in for a customer's real data.

npm Supply Chain: The Worm That Walked In Through Trusted Publishing

Marco Orta — Tue, 08 Sep 2026 00:00:00 GMT

For a year, npm security advice was a single sentence and everybody repeated it: stop publishing with long-lived tokens and move to trusted publishing with OIDC. It was good advice. It still is. And on May 11, 2026, the Shai-Hulud worm published dozens of official @tanstack/* packages by walking in exactly that way — not by forging provenance, but by genuinely generating it from the project’s own legitimate workflow.

That distinction is the whole article. A malicious package with an authentic Sigstore signature, issued by Fulcio, logged in Rekor, backed by the real repository context. Every indicator you were taught to check said “fine.”

This doesn’t mean trusted publishing is useless, or that anyone should go back to tokens. It means something more uncomfortable: it’s a layer, not a perimeter, and we spent a year selling it as the second thing. Here’s what it actually protects, what it leaves out, and the four measures that would have stopped the last twelve months of attacks.

The timeline, with dates

Worth having in front of you, because the cadence matters more than any single incident:

Date	What happened
Jul 2025	Trusted publishing with OIDC goes generally available on npm
Aug 26, 2025	S1ngularity attack
Sep 8, 2025	Phishing against `debug`, `chalk` and 16 more utilities — live for two hours
Sep 15, 2025	Shai-Hulud wave 1: 700+ packages compromised
Nov 23, 2025	Shai-Hulud 2.0
Dec 9, 2025	npm permanently revokes every classic token
Feb 2026	npm CLI 11.10.0 ships `min-release-age` and bulk OIDC configuration
Mar 30, 2026	`axios@1.14.1` compromised — 100M weekly downloads
May 11, 2026	Shai-Hulud against TanStack, entering through trusted publishing itself
May 14, 2026	`node-ipc`: three malicious versions with an 80 KB credential stealer
Jun 1, 2026	32 `@redhat-cloud-services` packages, payload named “Miasma”
Aug 2026	New wave: `keyv` and 400+ packages

Ten months, eight campaigns. This is no longer a series of incidents: it’s the registry’s normal operating state.

How it came in through the good door

The TanStack attack is worth following step by step, because each link dismantles a different assumption. Upwind’s reconstruction lays it out like this:

A “dropper” dependency lands in package.json and runs during installation via npm’s lifecycle hooks. Nothing exotic: that’s documented behaviour.
The dropper downloads and runs the Bun runtime. That way it doesn’t depend on the installed Node and it sidesteps monitoring that watches for Node executions.
Under Bun runs a heavily obfuscated 2.3 MB payload (router_init.js) that daemonises itself and stays alive after the install finishes.
Credential sweep: filesystem, cloud APIs, and — this is the good part — GitHub Actions runner memory, scraped from /proc/*/mem. Targets: AWS keys, npm tokens, Kubernetes service accounts, AI assistant configs.
OIDC abuse: rather than needing a stored npm token, it exchanges the GitHub Actions OIDC token for dynamic publish access. The workflow’s id-token: write permission is the key.
Propagation: with that access it downloads target packages, injects itself, bumps the version by exactly +3 and republishes.
And along the way it mints a Sigstore bundle through Fulcio and Rekor — so the malicious tarball ships with provenance generated from the trusted workflow context.

Point 7 is the one to internalise. There was no forgery. The chain of trust worked exactly as designed; what was compromised was the link before it, the CI runner. Provenance answers “was this built where it says?”, and the answer was yes. It does not answer “is what was built what the maintainer wrote?”, which was the question that mattered.

The published indicators, in case you need to sweep: workflows talking to api.masscan[.]cloud or 83.142.209.194, and persistence artifacts named router_init.js, pgmonitor.py or pgsql-monitor.service.

So is trusted publishing worth it?

Yes, very much so. But the split is worth being explicit about, because the generic advice never is:

Threat	Does OIDC stop it?
npm token stolen off a laptop	✅ Yes — there’s no token to steal
Token leaked in a CI log or a `.env`	✅ Yes
Maintainer phishing (the `debug`/`chalk` case)	✅ Largely
Token still valid months after a maintainer leaves	✅ Yes
CI runner compromised during the build	⛔ No
Malicious dependency running in `postinstall`	⛔ No
CI cache poisoning	⛔ No
Maintainer’s GitHub account compromised	⛔ No

The correct reading: OIDC eliminates the long-lived secret, which was the dominant vector through 2025. It does not defend the process that issues the publish. And as the first vector closes, attacks move to the second. That is precisely what the timeline above shows.

One number to calibrate how many people are still in the first box: according to Aikido’s analysis, of the 51,370 most-downloaded packages only 11,001 use trusted publishing — 21.4%, covering barely 25% of download volume. Three quarters of what you install every day is still published with tokens. And adoption moves incident by incident: from a baseline of ~35 new packages a week it spiked to 372 during Shai-Hulud 2.0, then the urgency deflated again.

So the message isn’t “trusted publishing failed.” It’s “migrate anyway, and also do these four things.”

The four measures that would actually have stopped this

1. Dependency cooldown: don’t install what shipped this morning

This is by far the best impact-to-effort ratio available, and still the least used.

The idea is offensively simple: tell your package manager to ignore versions published less than N days ago. Almost all of these campaigns are detected and pulled within hours — the malicious debug and chalk versions were live for two hours — so a modest delay takes you entirely out of the exposure window. Of ten attacks analysed, eight had windows shorter than a week.

All four managers support it natively now, with the trap that the units don’t match:

Manager	Key	Unit	Since
npm	`min-release-age`	days	CLI 11.10.0 (Feb 2026)
pnpm	`minimumReleaseAge`	minutes	10.16 (Sep 2025)
Yarn	`npmMinimalAgeGate`	minutes	Berry 4.10.0
Bun	`minimumReleaseAge`	seconds	—

In npm, one line in .npmrc:

min-release-age=7

In pnpm, inside pnpm-workspace.yaml, with an exclusion list for whatever you publish yourself:

minimumReleaseAge: 10080          # 7 days in minutes
minimumReleaseAgeExclude:
  - '@my-company/*'

Two practical warnings. First: the cooldown is enforced at install time, not at update-suggestion time, so your dependency bot can open the PR and the npm ci fail afterwards; set the same threshold in both places. Second: Bun counts seconds, not minutes: seven days is 604800, and anyone who copies pnpm’s 10080 ends up with a cooldown of under three hours without noticing. Yarn does accept durations like 7d, and its exemption list is not a *Exclude key but npmPreapprovedPackages.

If you want to see what it would have held back in your project before switching it on, dep-cooldown, an open-source tool of mine, reads your npm, pnpm, Yarn or Bun lockfile and gives you the age of every resolved version, including on the day you installed (--as-of). And npx dep-cooldown --config all prints the key for all four managers with the unit already converted.

2. Separate the runner that installs from the runner that publishes

This is the one that would have cut the TanStack attack dead.

The structural problem is that in most workflows the same job runs npm ci and npm publish. That means third-party code executing during install lives in the same process that holds — or can request — the OIDC token.

The right shape is to split it, with id-token: write existing only in the publishing job, which installs nothing from third parties:

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read          # no id-token here
    steps:
      - uses: actions/checkout@v5
      - run: npm ci --ignore-scripts
      - run: npm run build
      - run: npm pack
      - uses: actions/upload-artifact@v4
        with: { name: tarball, path: '*.tgz' }

  publish:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write         # the permission lives only here
    steps:
      - uses: actions/download-artifact@v4
        with: { name: tarball }
      - run: npm publish *.tgz --provenance

Note the --ignore-scripts on the install step. Lifecycle hooks are steps 1 and 2 of the attack; if your build doesn’t need them — and many don’t — turning them off in CI is free. If some dependency genuinely does need them, the exception list is shorter than you think and worth writing by hand.

3. Treat the CI cache as untrusted input

The initial vector of the May wave was cache poisoning. It’s an unintuitive vector because the cache looks like your own infrastructure, and it isn’t: in GitHub Actions, a lower-privileged branch can write into a cache that the release branch later reads.

The minimum:

Never use pull_request_target without an explicit trust boundary. That trigger runs with the base repository’s secrets and the PR’s code in front of it; it’s the foot in the door.
Segregate cache keys by branch or by purpose. The release workflow should not share a key with the PR workflow.
In the publishing job, don’t restore a cache at all. That job should be as boring as possible: download an artifact, upload it. Nothing else.

4. Stop reading the provenance badge as a verdict

Provenance is still useful: it tells you where a package was built. What you can’t do after May is read it as “this is safe.”

In practice that means dependency review doesn’t get delegated to a badge. What does work:

Pin with package-lock.json and always use npm ci in CI, never npm install. That’s the difference between reproducing a tree and resolving a new one every time.
Watch for odd version jumps. The worm bumped versions by exactly +3. A patch that skips three numbers with no changelog is a cheap and surprisingly good signal.
Rotate credentials when a wave hits you, and rotate everything: npm, GitHub, Actions secrets, AWS, Vault, Kubernetes, SSH. These payloads sweep the entire runner, not just the publish token.

And what npm changed on its own

Part of the work has already been done for you, and it’s worth knowing because it affects scripts you may still have lying around:

Classic tokens have been revoked since December 9, 2025. Not deprecated: revoked. If an old pipeline of yours stopped publishing on that date, this is why.
npm login no longer hands you a long-lived token, but a two-hour session that expires on its own and enforces 2FA for publishing.
Granular write tokens expire after 90 days at most. The eternal token no longer exists, even if you ask for it.
And since npm CLI 11.10.0 you can configure OIDC in bulk across many packages at once, which was the real friction in migrating an org with fifty packages.

If you publish packages, migrating to trusted publishing is literally four lines of YAML — the id-token: write and the --provenance from the example above — plus setting the trusted publisher on the package page. Do it. But do it knowing you’ve just closed the 2025 vector, not the 2026 one.

What I’d do this month, in order

If you have half an hour, in decreasing order of return:

Set min-release-age=7 (or your manager’s equivalent) in every repository. Five minutes, cuts off most known campaigns.
Swap npm install for npm ci --ignore-scripts in every CI workflow that doesn’t need hooks.
If you publish packages, split the workflow into build and publish, with id-token: write only in the second.
Migrate to trusted publishing anything still publishing with a granular token.
Audit your pull_request_target triggers and any cache keys shared across branches.

None of the five is expensive. And here’s the uncomfortable part: the first one, the most effective of all, requires trusting nobody and understanding no attack. Just waiting a week.

Further reading:

Secure Vibe Coding: Avoiding Vulnerabilities in AI-Written Code — the other front through which unreviewed code walks in.
The Complete Docker Guide for 2026 — isolating the build is half the defence in this article.
Tools to Audit Domain Security — the same review, pointed outward.

Frequently asked questions

Is trusted publishing with OIDC still worth it after the May 2026 attack?

Yes, and you should migrate anyway. OIDC completely eliminates the long-lived token, which was the dominant vector through 2025: there is nothing to steal from a laptop, from a CI log, or from a maintainer via phishing. What it does not cover is the process that issues the publish: if the CI runner is compromised during the build, the attacker exchanges the OIDC token exactly as the legitimate workflow would. It is a layer, not a perimeter.

How did the Shai-Hulud worm generate valid Sigstore provenance?

Because it did not forge it: it genuinely generated it. The malicious payload ran inside the project's own GitHub Actions runner, requested an OIDC token using the workflow's id-token: write permission, exchanged it for npm publish access, and minted a Sigstore bundle through Fulcio and Rekor from that trusted context. Provenance answers "was this built where it says?", and the answer was yes. It does not answer "is what was built what the maintainer wrote?".

What is a dependency cooldown and how do I configure it?

It tells your package manager to ignore versions published less than N days ago, so you never install a malicious version inside its lifetime, which is usually measured in hours. In npm it is min-release-age in .npmrc, measured in days (since CLI 11.10.0, February 2026); in pnpm it is minimumReleaseAge, measured in minutes (since 10.16); in Yarn it is npmMinimalAgeGate in minutes, and in Bun minimumReleaseAge in seconds. A seven-day threshold would have blocked eight of the ten most recent attacks analysed.

Why should the install job be separate from the publish job in CI?

Because if the same job runs npm ci and npm publish, the third-party code that executes during installation lives in the same process that has access to the OIDC token. That is how the TanStack attack got in: a malicious dependency ran in a lifecycle hook, scraped the runner memory and exchanged the token. The fix is for id-token: write to exist only in a publish job that installs nothing from third parties and just uploads an already-built artifact.

What share of npm packages already use trusted publishing?

Not many: of the 51,370 most-downloaded packages, 11,001 use it — 21.4%, covering around 25% of total download volume. In other words, three quarters of what gets installed daily is still published with tokens. Adoption spikes with each incident (372 new packages during the week of Shai-Hulud 2.0, against a baseline of about 35 per week) and falls back once the urgency passes.

Do npm classic tokens still work?

No. npm permanently revoked every classic token on December 9, 2025. Since then npm login issues a two-hour session instead of a long-lived token, and granular write tokens expire after 90 days at most. If an old pipeline stopped publishing around those dates, that is the cause.

Ollama on an AMD GPU: Five Failures That Drop You to CPU Without Telling You

Marco Orta — Tue, 08 Sep 2026 00:00:00 GMT

The worst Ollama failure on an AMD GPU isn’t the one that takes your server down. It’s the one that takes nothing down: Ollama starts, responds, answers correctly — and does it on CPU, at 15.89 tokens per second instead of 132.48. An 8.3x penalty that shows up in no log unless you go looking, because as far as Ollama is concerned that isn’t an error. It’s a fallback.

This article is the summary of three weeks measuring a 24 GB Radeon RX 7900 XTX on a Ryzen 9 7950X3D, across Windows, native Linux and inside WSL2. It isn’t an install guide — there are plenty of those — but an inventory of the five ways this setup breaks without saying so, with the numbers for each and with what I proved doesn’t fix them, which is usually the more useful half.

The tok/s here belong to one specific card in one specific environment. What does transfer verbatim are the failure modes and the method for catching them.

First: the thirty-second check

If you take one thing from this article, take this. Ollama probes the GPU exactly once, at startup, and never looks again. So there are two questions to answer every time, and neither is answered by noticing that the chat “feels fast”:

1. Which backend did the server declare at startup? It’s in the startup log (%LOCALAPPDATA%\Ollama\server.log on Windows, journalctl -u ollama on Linux):

library=Vulkan compute=0.0 name=Vulkan0 description="AMD Radeon RX 7900 XTX"
libdirs=ollama,vulkan  total="24.0 GiB" available="23.2 GiB"

What you’re looking for is library=. If it says cpu, that’s it: there is no GPU, and nothing else is going to tell you.

2. Did the model load in full? ollama ps gives you the split:

ollama ps
# NAME              SIZE     PROCESSOR
# gpt-oss:20b       16 GB    100% GPU

Anything that isn’t 100% GPU is a model split between GPU and CPU, and that doesn’t raise an error either.

One detail that cost me a whole verifier script: don’t require compute=gfx1100 or a pci_id. The Vulkan backend reports compute=0.0 and pci_id="" where ROCm gave real values, so a script checking those fields will fail a perfectly healthy system. Read library= and libdirs=, nothing else.

Failure 1: the CPU’s integrated GPU steals the job

This one is treacherous because the guilty hardware isn’t the hardware you’re looking at.

If you have a desktop Ryzen with integrated graphics — nearly all of the 7000 series and later do — your machine has two AMD GPUs, not one. And ROCm’s enumeration orders them however it likes:

ROCm0: AMD Radeon(TM) Graphics (36694 MiB)   <- the integrated one
ROCm1: AMD Radeon RX 7900 XTX (24560 MiB)

The integrated one comes first and reports 36 GB of VRAM (which it doesn’t have: that’s system RAM). llama.cpp binaries pick it, load kernels compiled for gfx1100, and blow up:

ggml-cuda.cu:106: ROCm error
ROCm error: device kernel image is invalid
  current device: 1, in function ggml_cuda_kernel_launch

What doesn’t fix it — and I tried everything before giving up:

Attempt	Result
`--device ROCm1` (pick it by name)	⛔ same error
`HIP_VISIBLE_DEVICES=0` and `=1`	⛔ same error, or “no usable GPU found”
`ROCR_VISIBLE_DEVICES=1` + `--device ROCm0`	⛔ same
`ROCBLAS_TENSILE_LIBPATH` to the kernel directory	⛔ same (the `gfx1100` kernels were there)

What does fix it: disabling the integrated GPU in the BIOS. With a single device there’s nothing to pick wrong and it starts first try, with no flags:

	before	after
`--list-devices`	integrated + dedicated	only the RX 7900 XTX
standalone `llama-server`	⛔ `kernel image is invalid`	✅ 136 tok/s
Ollama	118 tok/s	132.5 tok/s

The reasonable fear was losing VRAM by moving the monitor onto the dedicated card. Measured: it costs 0.2 GiB. With the display running 3440×1440 at 165 Hz off the big card, Ollama still reports total 24.0 GiB / available 23.8 GiB. The trade is free.

And a note so you don’t lose your mind: under Ollama this doesn’t happen, because Ollama masks the integrated GPU on its own and to it the dedicated card is ROCm0. That’s why you can have Ollama working and llama-server failing on the same machine with the same weights. You’re not imagining it: they’re two different enumerations.

Failure 2: updating anything resets the backend

I said it above, but it earns its own section because it’s the most expensive one: Ollama probes the GPU at startup and that’s it.

After an AMD driver reinstall, the service just carried on like this:

inference compute  id=cpu  library=cpu

No error. No warning. 15.89 tok/s against 132.48. Restarting Ollama put it back on library=ROCm compute=gfx1100 and back to 132.

There’s a second version of the same failure, and it’s worse because you don’t trigger it: every Ollama update reinstalls the ROCm bundle. If you’d deliberately switched to Vulkan, the update quietly puts you back on ROCm. Nobody tells you; the number you’d been measuring for weeks simply stops being the same number.

The operating rule that came out of this: run the check after touching drivers, BIOS or Ollama version. Not after something goes wrong — after touching anything, always, even when nothing seems wrong.

Failure 3: inside WSL2 there is no GPU for Ollama, and there won’t be

This is the one that ate the most time, so here’s the detail so it doesn’t eat yours.

The question was reasonable: if native Linux beats Windows by 6.7 to 19.5% in tok/s, can I take it inside WSL and skip the reboot? The answer is that Ollama in WSL doesn’t use the GPU at all. And it isn’t a driver problem.

What I measured, in order:

Check	Result
`/dev/kfd` and `/sys/class/kfd`	⛔ don’t exist
`/dev/dxg`	✅ exists (the WSL path)
Does HIP compute in WSL?	✅ YES — probe built with `hipcc`: `hipGetDeviceCount rc=0 n=1`, `gfx1100`
Ollama detects GPU	⛔ `library=cpu`
`HSA_ENABLE_DXG_DETECTION=1`	⛔ changes nothing
`llama-server --list-devices` with ROCm	⛔ `Available devices: (none)`
`llama-server --list-devices` with Vulkan	⛔ `Available devices: (none)`

The paradox that explains it: HIP does work in WSL, through the HSA runtime that talks to /dev/dxg. But Ollama enumerates GPUs by reading the KFD topology from sysfs, which WSL doesn’t expose. The driver isn’t missing — Ollama is looking through a door WSL doesn’t have.

With OLLAMA_DEBUG=1 the real cause surfaces, otherwise buried:

failure during llama-server GPU discovery
error="llama-server --list-devices failed: signal: segmentation fault (core dumped)"

There’s a recipe going around — Ollama issue 16551, which is the identical case: same card, same WSL2, same ROCm 7.2 — whose author reports library=ROCm compute=gfx1100 at 100% GPU by dropping in the ROCm bundle and setting HSA_ENABLE_DXG_DETECTION=1. Tried here, does not reproduce.

What about the Vulkan backend? In WSL it would need the dzn ICD (Vulkan over D3D12), which Ubuntu doesn’t package. You could build Mesa with -Dvulkan-drivers=microsoft-experimental and see what happens, but that’s a lot of work for an uncertain payoff.

Practical conclusion: for Ollama, WSL is out. The two exits are Windows Ollama (which does use the GPU, and is what exists today) or booting native Linux. And if you develop inside WSL like I do, the good news is you don’t need to move Ollama: with WSL2 in networkingMode=mirrored, localhost:11434 from WSL reaches Windows Ollama with zero configuration.

Failure 4: the model doesn’t fit, gets split, and keeps answering

When you ask for more context than fits in VRAM, Ollama doesn’t say no. It splits the model between GPU and CPU and carries on. The symptom is size_vram < size in /api/ps, and nothing else.

Measured with qwen3.8 (27.3B) on the 7900 XTX, with OLLAMA_FLASH_ATTENTION=1 and the KV cache at q8_0:

`num_ctx` requested	On GPU
262,144	⛔ 63.4% — a third on CPU
131,072	⛔ 92.4%
122,880	✅ 100% (with 0.6 GiB of headroom)

With 0.6 GiB free, anything you open on the desktop knocks it over. That ceiling belongs to that afternoon and that display, not to the model.

And here’s the warning that nearly cost me a bad decision: ollama ps underestimates real VRAM by 4.3 to 6.8 GiB. Cross-checked against the system counter, across four models:

Model	`ollama ps`	Real VRAM
`gpt-oss:20b`	12.33 GiB	16.59 GiB
`muse-glimmer` (27.9B)	15.49 GiB	20.77 GiB
`gemma4` (25.8B)	17.24 GiB	22.37 GiB
`qwen3.8` (27.3B)	16.61 GiB	23.36 GiB

For memory decisions, the ps column is useless. It’s only good for telling you whether Ollama split to CPU. If you’re working out whether a model fits, measure system VRAM, not what Ollama declares.

Failure 5: it trims your context and lets you believe you have it

A subtler variant of the previous one. Ask muse-glimmer or gpt-oss for num_ctx: 262144 and they load perfectly happily — and the context_length returned by /api/ps says 131072. What you asked for isn’t what you got.

The underlying cause is that these models have an architecture ceiling below the card’s. And it explains something counterintuitive that shows up when you measure: on-disk size does not predict maximum context. What decides is whether the model uses a sliding window (SWA) or dense KV:

Model	SWA	KV growth from 16K to 128K
`muse-glimmer`	2048	~0
`gpt-oss`	128	+0.36 GiB
`gemma4`	1024	+0.40 GiB
`qwen3.8`	— (dense KV)	+1.35 GiB

Three of the four hit their architecture ceiling and never notice the VRAM. The only one that actually pays for context is the only one that overflows.

Always read the real context_length from /api/ps, not the one you sent.

ROCm or Vulkan in 2026: what each one wins

This is the year’s underlying shift, and the reason this article lands now. Ollama added experimental Vulkan support in 0.12.6 and it has been reaching the binaries through 2026, with the argument of opening the door to the AMD and Intel GPUs ROCm never supported — which is most consumer cards.

On my machine, forcing each backend with the same Ollama and the same weights, Vulkan wins:

Model	Vulkan’s gain over ROCm
`gpt-oss:20b`	+17.8%
`gemma4`	+30.1%
`muse-glimmer`	+30.3%

Disjoint ranges across two independent rounds, so the signal is real. And it lines up with what others report: on an RX 9070 XT, Llama 2 7B Q4_0 decodes at 137 tok/s on Vulkan against 101 on ROCm.

With two caveats almost nobody adds.

First: the delta compares two things at once. On Windows it’s ROCm 7.1 against AMDVLK; on Linux it’s ROCm 7.2.4 against RADV. A worse ROCm inflates exactly the same number as a better Vulkan, and they aren’t separated.

Second is a cost I didn’t see coming. Vulkan leaves 0.6 GiB less VRAM available: 23.2 GiB declared against 23.8 with ROCm. For three of my four models it makes no difference because they weren’t near the limit. For qwen3.8, which had exactly 0.6 GiB of headroom, it eats the lot:

`num_ctx`	On Vulkan
122,880 (the ROCm ceiling)	⛔ 93.8% on GPU
98,304	✅ 100%

The real trade with this lever isn’t speed against stability: it’s speed against context. If your model is near the card’s limit, Vulkan costs you window. If it isn’t, it’s free.

What remains unmeasured — by me and by almost everyone — is Vulkan’s stability over multi-hour sessions. For a ten-minute chat it doesn’t matter; for an agent looping all afternoon, it does.

The full checklist

What I do now every time I touch this machine:

Disable the integrated GPU in the BIOS if you have a Ryzen with graphics. It costs 0.2 GiB and removes an entire axis of ambiguity.
Restart Ollama after touching drivers, BIOS or version. Not optional: it probes once.
Check library= in the startup log. Not compute=, not pci_id.
Check that ollama ps says 100% GPU before trusting any measurement.
Read the real context_length from /api/ps, not the one you sent.
For memory decisions, measure system VRAM, not the ollama ps column.
Don’t try it in WSL. Point at localhost:11434 against Windows Ollama.
Close Chrome, Spotify and Slack before measuring. Less for the tok/s than for the range: a real 2% difference disappears if noise widens it.

And the one that covers all of them: an empty result is not a zero. When an instrument returns nothing, the reading isn’t “there is none”; it’s “I couldn’t look.” On this machine, Get-Process | Modules returned 0 modules and I nearly read it as “no layers loaded.” It was 0 because the process was running elevated and I couldn’t see inside. What saved it was having a control case next to it — explorer, same user, 389 modules. Without that contrast, the zero reads as data.

If you’re weighing up the hardware

The honest conclusion after all of this: a consumer Radeon runs local models perfectly well in 2026, and the numbers sit alongside what gets published for NVIDIA in the same bracket. ROCm 7.2 is the first release where Ollama, LM Studio, llama.cpp and vLLM all work on Radeon without hand-patching.

What still costs more than on NVIDIA isn’t the tok/s: it’s the diagnosis. Everything in this article is time you wouldn’t have spent on a 4090 — not because the hardware is worse, but because the path is less trodden and the failures are silent instead of loud.

If that trade works for you — and it works for me, because 24 GB of VRAM at this price doesn’t exist on the other side — this article is the shortcut past the five holes.

Further reading:

AI Without Sending Data Out: Local LLMs for Law Firms and Small Businesses — the why behind all of this: what a local model actually solves, and what it doesn’t.
How Much Do the OpenAI, Claude and Gemini APIs Cost in 2026 — the number to compare against before buying a card.
The AI model your business runs on is being retired — why keeping the model in-house stops being a luxury.

Frequently asked questions

How do I know whether Ollama is using my AMD GPU?

With two checks, not one. First, the server startup log (%LOCALAPPDATA%\Ollama\server.log on Windows, journalctl -u ollama on Linux) must declare library=ROCm or library=Vulkan; if it says library=cpu, there is no GPU. Second, ollama ps must say 100% GPU: any other value means the model is split between GPU and CPU. Ollama raises no error in either case, it just runs slower.

Why does Ollama run on CPU after a driver update?

Because Ollama probes the GPU only once, at startup, and never looks again. If you update drivers, change the BIOS or install a new version while the service is running, it keeps the stale detection and falls back to CPU with no error at all. Measured on an RX 7900 XTX: 15.89 tok/s on CPU against 132.48 on GPU, an 8.3x penalty. The fix is to restart Ollama and re-check the library= line in the log.

Can I use an AMD GPU with Ollama inside WSL2?

No. Verified in August 2026 with an RX 7900 XTX and ROCm 7.2: Ollama enumerates GPUs by reading the KFD topology from sysfs, and WSL exposes neither /dev/kfd nor /sys/class/kfd. HIP does compute in WSL through /dev/dxg, but Ollama does not look there, and HSA_ENABLE_DXG_DETECTION=1 does not change it. Both ROCm and Vulkan return "Available devices: (none)". The practical exit is to point at localhost:11434 against Windows Ollama: with WSL2 in networkingMode=mirrored it works with no configuration.

Is ROCm or Vulkan better for Ollama on an AMD GPU?

It depends on whether your model is near the VRAM limit. On an RX 7900 XTX, Vulkan wins between 17.8% and 30.3% in tokens per second depending on the model, with disjoint ranges across two rounds. But Vulkan leaves 0.6 GiB less VRAM available (23.2 against 23.8 GiB), so a model that was tight on context stops fitting. The trade is not speed against stability: it is speed against context window.

Why does llama.cpp fail with "device kernel image is invalid" on a Ryzen?

Because the machine has two AMD GPUs: the dedicated card and the CPU's integrated graphics. ROCm enumerates the integrated one first, the binary picks it, and kernels compiled for gfx1100 do not work on that chip. Neither --device by name nor HIP_VISIBLE_DEVICES nor ROCR_VISIBLE_DEVICES fixes it. The only thing that works is disabling the integrated GPU in the BIOS, and it costs just 0.2 GiB of VRAM. Ollama does not suffer from this because it masks the integrated GPU on its own.

How much VRAM does a model in Ollama actually need?

More than ollama ps says, which underestimates by 4.3 to 6.8 GiB. Measured across four models on a 24 GB card: gpt-oss:20b declares 12.33 GiB and occupies 16.59; qwen3.8 declares 16.61 and occupies 23.36. To decide whether a model fits you have to read the system VRAM counter; the ollama ps column is only good for telling you whether the model was split to CPU.

GPT-6 Astra for Developers: The Pricing Cliff Nobody Put in the Headline

Marco Orta — Sat, 05 Sep 2026 00:00:00 GMT

OpenAI released GPT-6 Astra on 3 September 2026 with a 1,050,000-token context window. What the launch coverage skipped: the moment a request crosses 272,000 input tokens, the entire request is repriced at 2x input and 1.5x output. Not the excess — the whole thing. One token past the line roughly doubles the bill for that call. The window you are being sold is the window you are billed double to use.

That is the first of five things that matter if you are the one writing the code rather than reading the benchmark chart. This post is the developer-side read: pricing, access gating, what Astra explicitly does not support, the parameter that will break your validation, and — the one I care about most for the people who email me — why Astra is the wrong destination for the models OpenAI shuts down on 23 October.

What Astra actually is, in one screen

	GPT-6 Astra
API model ID	`gpt-6-astra` (single snapshot)
Context window	1,050,000 tokens
Max input	922,000 tokens
Max output	128,000 tokens
Knowledge cutoff	30 April 2026
Input / output	$10 / $50 per million
Cached input / cache write	$1.00 / $12.50 per million
Batch and Flex	50% of standard
Fast mode	2x standard, up to ~2.5x speed
Over 272K input	2x input and cache, 1.5x output — applied to the full request
Reasoning effort	`low`, `medium`, `high`, `xhigh`, `max`
Endpoints	Chat Completions, Responses, Batch
Not supported	Realtime, Assistants, fine-tuning, embeddings, image generation, audio, moderation, legacy Completions

Availability is staged: a limited set of organizations first (OpenAI’s Daybreak and Trusted Access programs), then ChatGPT Plus, Pro, Business and Enterprise “over the coming days”, then the API and Amazon Bedrock. Enterprise workspaces have it off by default — an admin has to switch it on, which is the first support ticket your team will file.

1. The 272K cliff, with the arithmetic

This is the part worth internalizing before you wire Astra into anything that runs on a loop.

The surcharge is not marginal pricing. It is not “the tokens above 272K cost double.” Per OpenAI’s own model page, prompts above 272,000 input tokens are billed at 2x input and cache rates and 1.5x output for the full request. Which produces this:

Request	Input tokens	Output tokens	Input cost	Output cost	Total
Just under	272,000	8,000	$2.72	$0.40	$3.12
Just over	273,000	8,000	$5.46	$0.60	$6.06
Max input	922,000	8,000	$18.44	$0.60	$19.04
Max input, max output	922,000	128,000	$18.44	$9.60	$28.04

A thousand extra input tokens — a medium-sized file, a couple of tool results — takes a $3.12 call to $6.06. That is a 94% increase for a 0.4% increase in input.

Now put that in an agent loop. Agents do not send one big prompt; they accumulate. The context grows with every tool result, every file read, every retry. So an agent that starts each session comfortably under the line will, somewhere around hour two of a long refactor, silently cross it — and every subsequent call in that session is priced on the far side. Nothing errors. Nothing warns you. You find out on the invoice.

If you have ever measured what an agent actually burns, you know the shape of this problem: in 35 days of Claude Code I logged 7.97 billion billable tokens. Apply a 2x step function to a curve like that and the number stops being theoretical.

What to actually do:

Set a hard input ceiling below the line, not at it. 260,000 leaves room for the tool result you did not predict. Enforce it in your own code before the call, because the API will not do it for you.
Count before you send. Token counting is cheap and the cliff is not. If your stack does not already meter input per request, that is the instrumentation to add first.
Remember prompt caching sits on the same side of the cliff. Cached input is $1/M normally and $2/M past 272K. Caching softens the slope, it does not move the step.
Batch where latency allows. 50% off applies before the multiplier, so batch plus long context is still cheaper than standard plus long context.

Before you commit a prompt template to production, sanity check its size. The cliff is a number you can design around — but only if you know which side of it you are on.

2. The gating is real, and it lands on unrelated work

Astra is the first model OpenAI has classified at the Critical cybersecurity level under its Preparedness Framework. In OpenAI’s own plain-language framing: with the right tools and access, it can find previously unknown security flaws and develop new ways to exploit them across many well-protected systems without a person guiding each step. During evaluation it developed exploits for hardened browsers and operating systems and found two previously unknown V8 vulnerabilities.

The consequence for developers is not abstract:

Standard API access refuses advanced cybersecurity work outright. Exploit discovery and development are not “paused for review” — they are declined.
The advanced capability is gated behind Daybreak and Trusted Access. If you do legitimate defensive security work, you apply; you do not just pay.
Accounts outside those programs may hit slowdowns, pauses or blocks — reportedly “sometimes during unrelated work.” That last clause is the operationally important one. A safety classifier tuned for a Critical-rated capability will have false positives, and false positives on a synchronous API call are latency spikes and failed requests in your product.

If you are putting Astra behind a user-facing feature, build for that: timeouts, a fallback model, and a retry path that degrades to a smaller model instead of surfacing an error. Treat “the safety layer said no” as a normal failure mode with a code path, not an exception you log and forget.

There is a second flag worth reading honestly rather than dismissing. The UK AI Safety Institute’s evaluation found supply-chain attack behavior in 2 out of 500 sampled runs, and OpenAI itself notes a substantial decrease in chain-of-thought monitorability compared with previous models — meaning the model can complete tasks without surfacing its reasoning. If you are running Astra with shell access in CI, approval_policy = "never" is not a defensible default anymore. This is the same argument I made about reviewing AI-written code before it ships, except the blast radius now includes your build pipeline.

3. What it does not support (the drop-in replacement trap)

Astra is a reasoning, computer-use and long-context model. It is not a general replacement for your OpenAI account. The unsupported list is long and specific:

Realtime. Assistants. Fine-tuning. Embeddings. Image generation. Audio. Moderation. Legacy Completions.

Two of those deserve a callout because they are load-bearing in real systems:

No fine-tuning. If your product depends on a fine-tuned model, Astra is not a path forward for it, and OpenAI is separately closing new self-serve fine-tuning job creation on 6 January 2027. Those two facts together are a strategy decision, not a config change.
No embeddings. Your RAG pipeline’s embedding step stays where it is. Astra changes the generation half of RAG and nothing about the retrieval half — and with a million-token window, the more interesting question is whether parts of your RAG layer are now solving a problem you no longer have. (Given the pricing above: probably not. Retrieval is still cheaper than stuffing.)

4. `xhigh` and `max`: the parameter that breaks validation

Astra adds two reasoning-effort levels above high: xhigh and max. Five total, in order: low, medium, high, xhigh, max.

This is a small change with a sharp edge. If anywhere in your stack you validate reasoning_effort against a hardcoded enum, a TypeScript union, a Pydantic Literal, a Zod schema, a JSON Schema enum, or a database CHECK constraint — that validation now rejects valid values. The failure is in your layer, not OpenAI’s, which is exactly the kind of break that costs an afternoon to find because the error message points at your own code and looks like a bug you introduced.

// Before
type ReasoningEffort = 'low' | 'medium' | 'high';

// After
type ReasoningEffort = 'low' | 'medium' | 'high' | 'xhigh' | 'max';

Grep for the string 'high' next to reasoning across your codebase and your infrastructure config before you let anyone select Astra in a model picker.

On cost: reasoning tokens are output tokens, billed at $50/M (or $75/M past the cliff). max on a long-context request is the single most expensive combination available in the API right now. Reserve it for the architectural decision or the debugging session that has already eaten a day — not for the default in a settings file that nobody revisits.

5. Context notes replace compaction — and that changes agent behavior

This is the change I think is genuinely underrated, and it is not a benchmark number.

Every long-running agent hits the same wall: the context fills, and the harness compacts — it summarizes the conversation into a shorter one and continues. Compaction is lossy and the loss is irreversible. The exact error text from the third failed attempt, the approach you abandoned and why, the specific assertion that broke — those get flattened into “we tried several approaches to fix the auth bug.” Then the agent tries the abandoned approach again, because nothing in its context says it already failed.

Astra replaces that with persistent notes plus searchable earlier context windows. It keeps running notes across windows, and it can go back and search prior windows for something the note did not capture. In practice: the model can retrieve a requirement or a test result from two hours ago even if it did not think to write it down at the time.

In Codex CLI (v0.153.1 or later, released 3 September 2026), the configuration is:

model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

# Let Astra's own notes do the work instead of Codex's compaction
auto_compact_token_limit = 850000

[tui]
auto_recap = false

Per session: codex -m gpt-6-astra --reasoning-effort xhigh "your task", or /model gpt-6-astra mid-session. Run codex models to confirm your account actually has access — the picker only shows what your account is entitled to, so an absent model is a gating answer, not a bug.

Note the tension with section 1: auto_compact_token_limit = 850000 deliberately lets context run well past 272K, because that is the point of the feature. You are trading money for continuity. That is a defensible trade for a hard debugging session and an indefensible one for a chatbot.

6. Reading the benchmarks honestly

The scoreboard, with the comparisons that were published alongside it:

Benchmark	GPT-6 Astra	GPT-5.6 Sol	Claude Opus 5	Claude Fable 5.1
OSWorld 2.0 (computer use)	72.6%	65.7%	70.2%	—
Terminal-Bench 4.0	57.7%	37.3%	52.3%	55.8%
FrontierMath Tier 4 v2	97.6%	83.0%	73.2%	87.8%
GPQA Diamond	96.0%	94.6%	93.7%	93.7%
ExploitBench	100%	78.5%	70.0%	—
Humanity’s Last Exam (tools)	57.2%	—	63.6%	65.0%
DeepSWE v1.1 (coding)	74.1%	72.7%	—	—

Three honest readings:

The computer-use gain is the real story. 72.6% on OSWorld with task completion time dropping from ~75 minutes to ~40 is a step change in what an agent can finish unattended. If your use case is “operate a browser, a spreadsheet and a terminal to complete a multi-step job,” this is a different class of tool.
The coding gain is marginal. 74.1% vs 72.7% on DeepSWE is inside the noise of a leaderboard where Gemini 3.8 Flash and Claude Opus 5 sit in the same band. If you are picking a model to write code, Astra is not obviously the answer, and at $10/$50 it is not the cheap answer either.
The ARC-AGI-3 number is doing marketing work. The headline 99.9% comes from an adapter harness. Stateless API calls — which is what your code makes — reportedly score somewhere between 17% and 63% depending on reasoning tier. Any benchmark quoted with a custom harness is a statement about the harness as much as the model.

Astra also trails Claude Fable 5.1 on Humanity’s Last Exam with tools (57.2% vs 65.0%). “Most capable model ever deployed” is a defensible claim on aggregate; it is not true on every axis, and the axes where it is not true include reasoning-with-tools, which is what agents do all day.

The part most people reading this actually need: 23 October

Here is where the launch hype and the real deadline collide.

On 23 October 2026, OpenAI shuts down gpt-3.5-turbo, gpt-4, gpt-4-turbo, o1, o1-pro, o3-mini and o4-mini in the API. After that date, calls to those IDs return errors, not responses. That is the breaking change on your calendar, and it is 48 days out from this post.

Astra’s launch will push a lot of people to migrate straight to it. For most of them that is a costly mistake.

The typical thing wired to gpt-3.5-turbo is a support chatbot or a classifier built in 2023. gpt-3.5-turbo last published at roughly $0.50 per million input and $1.50 per million output. Astra is $10 and $50. That is 20x the input cost and 33x the output cost — for a workload that was chosen precisely because it was the cheap tier. Migrating a high-volume classifier from gpt-3.5 to Astra does not modernize it; it turns a $40/month line item into something you will notice.

The migration ladder that actually makes sense:

gpt-3.5-turbo chatbot or classifier → the current small/mini tier. Cheaper than what you are on, and far more capable. Astra is not in the conversation.
gpt-4 / gpt-4-turbo general workload → the current flagship mid tier. Test for prompt regressions; a decade of prompt-engineering folklore was tuned against gpt-4’s specific quirks.
o1 / o3-mini / o4-mini reasoning workload → this is where Astra is a genuine candidate, because you already accepted reasoning-token cost. Benchmark high before you reach for xhigh.
Long-horizon agent that operates software → Astra, and this is the case it was built for. Budget for section 1.

The full calendar, the audit query to find out whether you are exposed, and the migration checklist are in the 2026 AI model shutdown calendar — including the two September dates that land before Astra is even generally available: the Videos API and sora-2 retire on 24 September, and legacy snapshots follow on 28 September.

So should you switch?

You run a chatbot, a classifier, or anything high-volume and short-context: no. Astra is the wrong price class. Go to the small tier, and go before 23 October.

You run a coding agent: not on these numbers alone. The coding delta over the previous generation is marginal and the price is not. Try it on the hard tasks — the ones that currently fail — and keep the cheaper model as the default.

You run a long-horizon agent that drives a browser, a terminal or a desktop: yes, and this is the only category where the answer is straightforwardly yes. The OSWorld jump and the persistent-notes architecture are aimed exactly at you. Set a token ceiling first.

You do defensive security work: yes, and start the Trusted Access application now, because the standard API will refuse the work you need it for.

You have anything fine-tuned: Astra is not your path. Plan around that separately, with the January 2027 fine-tuning date on the same page.

Further reading:

The 2026 AI model shutdown calendar — the 23 October deadline in full, and how to check whether your code is exposed.
How much AI coding agents really cost — 7.97 billion measured tokens, and the arithmetic that makes the 272K cliff matter.
AI without sending data out: local LLMs — the other answer when the flagship price and the data-retention question both land badly.
Migrating your MCP server to the 2026-07-28 spec — Astra supports MCP and tool search; the spec underneath moved too.

Frequently asked questions

How much does the GPT-6 Astra API cost?

Standard pricing is $10 per million input tokens and $50 per million output tokens, with cached input at $1 per million and cache writes at $12.50 per million. Batch and Flex processing run at 50% of standard rates, and Fast mode costs 2x standard for up to roughly 2.5x the speed. Critically, any request with more than 272,000 input tokens is billed at 2x the input and cache rates and 1.5x the output rate for the entire request, not just for the tokens above the threshold.

What is the GPT-6 Astra context window?

The context window is 1,050,000 tokens, with a maximum of 922,000 input tokens and 128,000 output tokens in a single request. The knowledge cutoff is 30 April 2026. Be aware that using more than 272,000 input tokens triggers a pricing surcharge that applies to the full request, so the usable window and the economically sensible window are not the same number.

Why can I not see gpt-6-astra in my account?

Access is staged. At launch Astra went to a limited set of organizations in OpenAI's Daybreak and Trusted Access programs, then to ChatGPT Plus, Pro, Business and Enterprise users, then to the API and Amazon Bedrock. Enterprise workspaces have it disabled by default and an administrator has to enable it. In Codex CLI, running "codex models" shows only what your account is entitled to, so an absent model usually means gating rather than a bug.

Can I use GPT-6 Astra for security research or penetration testing?

Not through standard API access. Astra is the first model OpenAI has rated at the Critical cybersecurity level under its Preparedness Framework, and standard access refuses advanced cybersecurity work such as exploit discovery outright rather than pausing it for review. Advanced capability is gated behind the Daybreak and Trusted Access programs. Accounts outside those programs may also see slowdowns, pauses or blocks, reportedly sometimes during unrelated work.

Does GPT-6 Astra support fine-tuning?

No. Astra supports Chat Completions, Responses and Batch, and does not support fine-tuning, Realtime, Assistants, embeddings, image generation, audio, moderation, or the legacy Completions endpoint. This matters alongside a separate OpenAI change: new self-serve fine-tuning job creation closes on 6 January 2027, so any product depending on a fine-tuned model needs a plan that does not route through Astra.

Should I migrate my gpt-3.5-turbo chatbot to GPT-6 Astra before 23 October 2026?

Almost certainly not. gpt-3.5-turbo shuts down on 23 October 2026 along with gpt-4, gpt-4-turbo, o1, o1-pro, o3-mini and o4-mini, so you do have to move. But gpt-3.5-turbo last published at roughly $0.50 per million input and $1.50 per million output, against Astra's $10 and $50 — around 20x the input cost and 33x the output cost. High-volume, short-context workloads like chatbots and classifiers belong on the current small or mini tier, which is both cheaper than gpt-3.5-turbo and considerably more capable.

What are the xhigh and max reasoning effort levels?

Astra adds two levels above high, giving five in total: low, medium, high, xhigh and max. Any code that validates reasoning_effort against a hardcoded list — a TypeScript union, a Zod or Pydantic schema, a JSON Schema enum, a database constraint — will reject the new values until it is updated, and the resulting error appears to come from your own code. Reasoning tokens are billed as output tokens, so max on a long-context request is the most expensive combination the API currently offers.

What are context notes and how do they differ from compaction?

Compaction summarizes a full conversation into a shorter one when the context window fills, which irreversibly loses detail such as exact error messages or approaches that were tried and abandoned. Astra instead keeps persistent notes across context windows and leaves earlier windows searchable, so it can retrieve a requirement or test result from an earlier window even when the note did not capture it. In Codex CLI v0.153.1 or later this is configured by raising auto_compact_token_limit so Astra's own notes handle continuity instead of the harness compacting early.

Kubernetes 1.37: What Breaks on Upgrade Day (and Why It's Your Control Plane)

Marco Orta — Sat, 05 Sep 2026 00:00:00 GMT

Kubernetes v1.37 “Garhwal” shipped on 26 August 2026, and the headline breaking change is being reported wrong almost everywhere. v1.37 does not introduce the rule that static Pods cannot reference API objects — that landed in v1.34. What v1.37 removes is the escape hatch. The PreventStaticPodAPIReferences feature gate is gone, and per the upstream release note it “cannot be disabled anymore.”

That inverts who is at risk. If you never hit this, you are fine. The clusters that break on upgrade day are precisely the ones that already hit it in 1.34, 1.35 or 1.36, turned the gate off to get moving, and filed the real fix under later. Later is now, and the thing that fails to start is the control plane.

The three blockers, ranked

#	Change	Failure mode	Urgency
1	`PreventStaticPodAPIReferences` gate removed	kubelet denies admission to static Pods referencing API objects — including etcd and kube-apiserver manifests	Blocks upgrade
2	cgroup v1 refusal enforced	kubelet exits on start unless `failCgroupV1: false`	Blocks upgrade
3	kube-proxy `ipvs` mode deprecated	Warning on startup only. Disabled by default in v1.40, removed in v1.43	Plan, don’t panic

Everything else in this release — kube-dns deprecated in favour of CoreDNS, kubectl run --filename/-f deprecated, sixteen features graduating to stable — is housekeeping. The two that stop a node from coming back are the first two.

1. Static Pods can no longer reference API objects

What the rule actually is

The clean formulation is not “no Secrets or ConfigMaps.” It is the one from the implementing pull request: static Pods may only use hostPath and emptyDir volumes, and may not reference API objects at all.

The upstream release note for PR #131837, which carries an explicit ACTION REQUIRED, names the full surface:

Prior to upgrade, ensure static pods are not referencing API objects such as ServiceAccounts, ConfigMaps, Secrets, ResourceClaims, CSIDrivers, PersistentVolumeClaims, or ClusterTrustBundles.

Note ServiceAccounts in that list. Most of the secondary coverage of this release only mentions configMapRef and secretRef, which understates it: a static Pod with a serviceAccountName, an imagePullSecrets entry, or a PVC-backed volume is equally denied. In practice the fields to hunt for are:

env.valueFrom.configMapKeyRef and env.valueFrom.secretKeyRef
envFrom.configMapRef and envFrom.secretRef
volumes[].configMap, volumes[].secret, volumes[].persistentVolumeClaim, volumes[].projected
serviceAccountName, imagePullSecrets, resourceClaims

Why this is a control-plane problem, not a workload problem

Static Pods are the ones the kubelet runs straight off disk from /etc/kubernetes/manifests/, with no API server involved. On a kubeadm cluster that directory holds etcd, kube-apiserver, kube-controller-manager and kube-scheduler.

So the failure mode is not “one of my Pods didn’t schedule.” It is: you upgrade a control-plane node, the kubelet refuses admission to the etcd manifest, and the API server never comes up to tell you why. You are debugging from journalctl -u kubelet on the node, not from kubectl.

The old behaviour was silent, which is why this exists

Before v1.34 this did not error. The static Pod ran, and only the mirror Pod — the read-only API representation the kubelet creates so the Pod shows up in kubectl get pods — failed to reconcile. The container was live on the node and effectively invisible to the API. PR #131837 closed that by denying admission outright, so the container is never created rather than running unobserved.

That history is the reason the gate existed at all: reviewers asked for the validation to ship on by default but disableable “for a few releases.” Three release cycles later, PR #140226 removed it, with milestone v1.37.

The audit, before you touch a single node

Run this on every control-plane and worker node, not just one:

grep -rlE 'configMapRef|secretRef|configMapKeyRef|secretKeyRef|serviceAccountName|imagePullSecrets|persistentVolumeClaim' \
  /etc/kubernetes/manifests/

Any file it prints is a manifest you have to rework before upgrading that node. The fix is always the same shape: stop pulling the value from the API and put it on disk, as a hostPath mount or as a literal in the manifest, since hostPath and emptyDir are the only volume types still permitted.

If your manifests are generated — kubeadm, Cluster API, a Helm chart that templates node config, an Ansible role — audit the template, not just the rendered output, or the next node you provision reintroduces the problem.

Before you commit a reworked manifest, sanity check that it is still valid YAML and that you did not break indentation while ripping out a volume block:

2. cgroup v1: the kubelet just exits

This one is short and absolute. The kubelet refuses to run on a host using cgroup v1. It does not warn and degrade — it exits on start with:

kubelet is configured to not run on a host using cgroup v1

The default flipped to failing in v1.35, and v1.37 keeps it enforced. The only override is in KubeletConfiguration:

failCgroupV1: false

Where you put it depends on your distribution, and the timing matters:

kubeadm: edit the kube-system/kubelet-config ConfigMap and add the field before you upgrade. Adding it after the kubelet has already refused to start means editing config on a node whose control plane may be down.
RKE2 / K3s: pass the kubelet argument fail-cgroupv1=false in /etc/rancher/rke2/config.yaml or /etc/rancher/k3s/config.yaml.

Treat that as a bridge, not a fix. It is the same category of decision as the static-Pod gate you are reading this post because of — an off switch that upstream is winding down.

Check which cgroup version a node is on before you upgrade it:

stat -fc %T /sys/fs/cgroup
# cgroup2fs -> v2, you are fine
# tmpfs     -> v1, you are not

ls /sys/fs/cgroup/cgroup.controllers   # exists only on v2

The nodes that trip this are the old ones: long-lived CentOS 7 and Ubuntu 18.04 hosts, and anything provisioned from an AMI or image built years ago and never rebuilt. If you run a managed service (EKS, GKE, AKS) on current node images you are almost certainly on v2 already — but “almost certainly” is a stat away from certain.

3. kube-proxy IPVS: deprecated, not removed

mode: ipvs in KubeProxyConfiguration is deprecated as of v1.37 (KEP-5495). Nothing breaks today; you get warnings in the kube-proxy startup logs. The timeline:

Release	State
v1.35	Warning logs begin
v1.37	Formally deprecated, warnings continue
v1.40	Disabled by default, re-enabled only via feature gate
v1.43	Code removed entirely

The rationale is worth knowing because it kills the usual objection: IPVS mode was never a full replacement for iptables — it still requires iptables underneath and cannot fully implement Kubernetes Services on its own. The successor is nftables, not a return to iptables.

Check what you are running:

kubectl -n kube-system get cm kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep mode:

If it says ipvs, you have from now until v1.40 to move to mode: nftables. That is roughly a year of releases — enough to do it on your own schedule, which is exactly why you should put it on the schedule now instead of meeting it the way people are meeting the static-Pod gate this month.

The pre-upgrade checklist

Run all of this before the first node, on every node:

# 1. Static Pod API references — the upgrade blocker
grep -rlE 'configMapRef|secretRef|configMapKeyRef|secretKeyRef|serviceAccountName|imagePullSecrets|persistentVolumeClaim' \
  /etc/kubernetes/manifests/

# 2. cgroup version — the other upgrade blocker
stat -fc %T /sys/fs/cgroup

# 3. kube-proxy mode — plan, not block
kubectl -n kube-system get cm kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep mode:

# 4. Are you still on kube-dns instead of CoreDNS?
kubectl -n kube-system get deploy | grep -E 'kube-dns|coredns'

Empty output from 1, cgroup2fs from 2, and nftables or iptables from 3 means the upgrade is boring. That is the goal.

Who actually needs to act

You disabled PreventStaticPodAPIReferences at any point since v1.34: you are the target audience for this entire post. That gate no longer exists, so whatever made you disable it now blocks the upgrade. Fix the manifests first, upgrade second.

You run kubeadm control planes you have hand-edited: run the grep on the control-plane nodes specifically. Hand-edited /etc/kubernetes/manifests/ files are where secretRef and serviceAccountName get added by someone solving a problem at 2am.

You run nodes older than about three years: check cgroups before anything else. A kubelet that exits on start looks identical to a broken upgrade, and you will lose an hour finding a one-line answer.

You are on managed Kubernetes with current node images: you are probably clear on 1 and 2. Check 3 and put the IPVS migration in a quarter, not a sprint.

You run mode: ipvs: nothing breaks now. Schedule the move to nftables before v1.40.

Further reading:

What breaks upgrading to Node 26 — same format for the runtime, and the same pattern of failures that produce no error.
What breaks upgrading to Vite 8 — the version you inherited without choosing it, which is the other way these upgrades bite.
GPT-6 Astra for developers — if you are running agents with shell access against a cluster, the safety and approval-policy section applies directly.

Frequently asked questions

What breaks when upgrading to Kubernetes 1.37?

Two changes can block the upgrade outright. First, the PreventStaticPodAPIReferences feature gate was removed, so static Pods that reference API objects are denied admission by the kubelet with no way to opt out — and on kubeadm clusters those static Pods include etcd and kube-apiserver. Second, the kubelet refuses to start on hosts using cgroup v1 unless failCgroupV1 is explicitly set to false. A third change, the deprecation of kube-proxy IPVS mode, only produces warnings in v1.37 and does not break anything yet.

Why do static Pods fail after upgrading to Kubernetes 1.37?

Because the escape hatch was removed, not because the rule is new. The restriction on static Pods referencing API objects shipped in v1.34 behind the PreventStaticPodAPIReferences feature gate, which was enabled by default but could be disabled. Kubernetes v1.37 removed that gate entirely, and the upstream release note states it cannot be disabled anymore. Clusters that turned the gate off to defer the fix are exactly the ones that break on upgrade.

Which API objects can a static Pod not reference in Kubernetes 1.37?

The upstream release note lists ServiceAccounts, ConfigMaps, Secrets, ResourceClaims, CSIDrivers, PersistentVolumeClaims and ClusterTrustBundles. The simplest way to hold the rule is from the implementing pull request: static Pods may only use hostPath and emptyDir volumes. That means serviceAccountName, imagePullSecrets, envFrom.configMapRef, envFrom.secretRef, env.valueFrom.secretKeyRef, projected volumes and PVC-backed volumes are all rejected, not just the ConfigMap and Secret references most summaries mention.

How do I check whether my cluster is affected before upgrading?

On every control-plane and worker node, run: grep -rlE 'configMapRef|secretRef|configMapKeyRef|secretKeyRef|serviceAccountName|imagePullSecrets|persistentVolumeClaim' /etc/kubernetes/manifests/ — any file it prints must be reworked before that node is upgraded. Separately run stat -fc %T /sys/fs/cgroup on each node; cgroup2fs is safe and tmpfs means cgroup v1, which stops the kubelet from starting. If your manifests are generated by kubeadm, Cluster API, Ansible or Helm, audit the template as well or newly provisioned nodes will reintroduce the problem.

Is kube-proxy IPVS mode removed in Kubernetes 1.37?

No. It is deprecated in v1.37 under KEP-5495 and only logs warnings at startup. It is expected to be disabled by default in v1.40, where it can still be re-enabled through a feature gate, and removed entirely in v1.43. The replacement is nftables mode, not iptables. The reasoning is that IPVS mode always required iptables underneath and could never fully implement Kubernetes Services on its own.

What happened to static Pods referencing Secrets before Kubernetes 1.34?

It failed silently, which is why the restriction exists. The static Pod would run on the node, but the mirror Pod — the read-only API representation that makes the Pod visible to kubectl — failed to reconcile. The container was live and effectively invisible to the API server. PR #131837 changed this to deny admission outright so the container is never created, rather than running unobserved.

When was Kubernetes 1.37 released and what is it called?

Kubernetes v1.37, codenamed "Garhwal", reached general availability on 26 August 2026. Alongside the deprecations it graduated sixteen features to stable, including ResourceClaim device status (KEP-4817), device taints and tolerations (KEP-5055), resource health status for Pods (KEP-4680) and SELinuxMount with SELinuxChangePolicy (KEP-1710). It also deprecated the kube-dns subproject in favour of CoreDNS and the --filename flag on kubectl run.

ESLint 10: What Breaks When You Upgrade (and Why ESLint 9 Is Already Unsafe)

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

ESLint 9 reached end of life on August 6, 2026. If your CI is still running eslint@9, it has been running without security patches for four weeks, and nobody is going to tell you. ESLint 10 went GA on February 6, 2026, which means the six-month overlap window the project always gives you is already gone. The headline change is not a new rule or a faster parser — it’s that the eslintrc configuration system, the one built around .eslintrc.json and .eslintrc.js, has been deleted from the codebase. Not deprecated. Not gated behind a flag. Deleted. There is exactly one way to configure ESLint 10: eslint.config.js.

This matters more than most major-version bumps because ESLint has been telegraphing this exact removal since flat config shipped as the default in v9, back in April 2024. Teams had two years of warning. A lot of them used that time to do nothing, because the old config kept working. It stops working now.

Where are you coming from?

The migration cost splits hard across three starting points.

From ESLint 9 with flat config already in place. You’re in the best position. Your eslint.config.js already exists and already works the way ESLint 10 expects. What still hits you: the Node.js version floor moved, the default rule set gained three rules you haven’t seen before, and — if you’re in a monorepo — the config-file lookup algorithm changed in a way that can silently change which rules apply to which files.

From ESLint 9 still leaning on @eslint/eslintrc’s FlatCompat shim. This was the pragmatic middle path a lot of teams took in 2024–2025: write an eslint.config.js, but use FlatCompat.extends() inside it to keep pulling in an old-style shareable config (airbnb-base, an internal eslint-config-company package) that never got a flat-config release. The good news, and it’s not obvious, is that this path still works on ESLint 10 — FlatCompat didn’t die with eslintrc, it’s a separate package and it’s still maintained. You do need to make sure @eslint/eslintrc itself is on a current version, since old copies predate ESLint 10’s internals.

From ESLint 8, or from ESLint 9 with no eslint.config.js at all (meaning you were relying on ESLint 9’s automatic fallback to the legacy format when it doesn’t find a flat config). This is the group that breaks hardest, because that fallback is exactly what got removed. Point ESLint 10 at a project with only .eslintrc.json and no eslint.config.js, and it won’t quietly use the old file — it will fail to find any configuration at all.

The breaking changes, ranked by how much they’ll cost you

1. `eslintrc` is gone. There is no flag to bring it back.

This is the one everyone half-expects and still gets bitten by, because the actual removal is broader than “the old file format stops being read.” Four things go away together:

.eslintrc.js, .eslintrc.json, .eslintrc.yml, and .eslintignore are no longer read, full stop.
The ESLINT_USE_FLAT_CONFIG environment variable, which used to let you force ESLint 9 back onto the legacy system, is no longer honored. Setting it does nothing — it’s not an error, it’s just ignored.
The CLI flags that only made sense for eslintrc are gone: --no-eslintrc, --env, --resolve-plugins-relative-to, --rulesdir, --ignore-path. Scripts that pass these now fail to start.
Linter’s configType constructor option only accepts "flat". Pass "eslintrc" and it throws.

The migration itself, from .eslintrc.json to eslint.config.js, is mechanical once you’ve done it once. Here’s a real one, before and after:

Before — .eslintrc.json:

{
  "root": true,
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "plugins": ["@typescript-eslint"],
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": ["warn", { "argsIgnorePattern": "^_" }]
  },
  "ignorePatterns": ["dist", "node_modules"]
}

After — eslint.config.js:

import js from '@eslint/js';
import globals from 'globals';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  {
    ignores: ['dist/**', 'node_modules/**'],
  },
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    languageOptions: {
      globals: {
        ...globals.browser,
        ...globals.node,
      },
    },
    rules: {
      '@typescript-eslint/no-unused-vars': ['warn', { argsIgnorePattern: '^_' }],
    },
  },
);

Three things changed shape, not just syntax: env became languageOptions.globals pulled from the globals package, extends became an array you spread in directly (tseslint.configs.recommended is already an array of config objects), and no-unused-vars: off disappeared — @typescript-eslint/no-unused-vars doesn’t need you to manually silence the base rule anymore because tseslint.configs.recommended already scopes it correctly per file.

If your only remaining blocker is a shareable config with no flat-config release, that’s what FlatCompat is for:

import { FlatCompat } from '@eslint/eslintrc';
import path from 'node:path';
import { fileURLToPath } from 'node:url';

const compat = new FlatCompat({
  baseDirectory: path.dirname(fileURLToPath(import.meta.url)),
});

export default [
  ...compat.extends('airbnb-base'),
  // the rest of your flat config
];

That’s still a real eslint.config.js — FlatCompat just lets one old-format shareable config live inside it. It’s a bridge, not eslintrc coming back.

2. The config-lookup algorithm changed — silent in monorepos

This one is silent by design, and it’s the change most likely to bite people who did everything “right.” ESLint 10 stopped resolving eslint.config.* from the current working directory. Instead it starts the search from the directory of each file being linted and walks upward. The stated goal is to let a monorepo have a different eslint.config.js per package without extra wiring — which is genuinely useful. The cost is that a file can now silently pick up a different config than it did on ESLint 9, with no warning and no error: the lint just passes or fails differently than before, and the reason is a config file two directories away that you forgot existed. If you run a monorepo, lint every workspace individually right after the upgrade and diff the output against ESLint 9 before you trust it.

3. Three rules just turned on in `eslint:recommended` — also silent

If your config includes js.configs.recommended (formerly eslint:recommended), upgrading adds no-unassigned-vars, no-useless-assignment, and preserve-caught-error to what you’re enforcing — without you touching a single line of your own config. This is the classic silent break: you run the exact command you always run, and it now fails or warns on code that hasn’t changed. If your CI treats warnings as failures, that’s a red build the morning after the bump, with a diff that shows nothing you did wrong.

no-useless-assignment catches the value that’s overwritten before it’s ever read:

function total(items) {
  let sum = 0; // this assignment...
  sum = items.reduce((a, b) => a + b, 0); // ...is immediately replaced, never read
  return sum;
}

preserve-caught-error flags a caught error you throw away instead of chaining:

// before — the original error and its stack are gone
try {
  parseConfig(raw);
} catch (err) {
  throw new Error('Config parsing failed');
}

// after — the original cause survives for whoever debugs this later
try {
  parseConfig(raw);
} catch (err) {
  throw new Error('Config parsing failed', { cause: err });
}

None of this is wrong to enforce — it’s good advice. The problem is finding out about it from a failed deploy instead of from a changelog.

4. `/* eslint-env */` comments go from silently inert to an explicit error

This one has a two-step history worth knowing. Flat config never supported /* eslint-env browser */-style comments — they’ve been silently doing nothing since you moved to flat config on ESLint 9, whether or not you noticed. ESLint 10 closes that silence: the same comment is now reported as a lint error instead of being quietly ignored. If you never migrated those comments to languageOptions.globals, you’ll see brand-new errors pointing at code that “worked” for the last year and a half, because the globals it needs were never actually being declared — the comment just wasn’t doing anything.

/* eslint-env browser, node */
window.dispatchEvent(new Event('ready'));

Move the intent into the config instead, the same way the .eslintrc example above did with env:

{
  languageOptions: {
    globals: { ...globals.browser, ...globals.node },
  },
}

5. The Node.js floor moved, and it’s not just a version-number bump

ESLint 10 requires Node.js ^20.19.0 || ^22.13.0 || >=24. Node 21.x and 23.x — the odd-numbered non-LTS releases — are unsupported outright, and anything below 20.19.0 or 22.13.0 is unsupported even within an otherwise-fine major. In package.json:

// before
"engines": { "node": ">=18" }

// after
"engines": { "node": "^20.19.0 || ^22.13.0 || >=24" }

If your CI image pins an older Node patch inside 20.x or 22.x, npm install may still succeed while the linter itself fails at startup with an error that has nothing obviously to do with Node — install ESLint and it’s already broken before it reads a single file.

6. Removed `context` and `SourceCode` methods break custom rules and old plugins

If you write custom rules, or depend on an internal plugin nobody has touched since 2023, this is where it bites: context.getCwd(), context.getFilename(), context.getPhysicalFilename(), context.getSourceCode(), context.parserOptions, and context.parserPath are all gone, along with SourceCode#getTokenOrCommentBefore(), getTokenOrCommentAfter(), isSpaceBetweenTokens(), and getJSDocComment(). The Linter class itself lost defineParser(), defineRule(), defineRules(), and getRules(). Replacements exist for the ones that matter (context.cwd, context.filename, context.sourceCode, isSpaceBetween()), but a rule that only calls the removed API on a rare code path won’t throw until that path runs — which can mean it passes CI for weeks and then fails on one specific file.

7. `eslint.config.ts` needs a current `jiti`

ESLint 10 drops support for jiti versions before 2.2.0, which matters only if you write your config in TypeScript (eslint.config.ts) and let jiti transpile it on the fly. Under 2.2.0, the failure doesn’t say “upgrade jiti” — it surfaces as an unrelated module-resolution error, which sends most people down the wrong debugging path first.

What doesn’t break

Worth saying plainly, because the framing of “everything breaks” isn’t accurate either. typescript-eslint already supports ESLint 10 (its stated peer range is ^8.57.0 || ^9.0.0 || ^10.0.0), so a project on modern typescript-eslint doesn’t need to touch it for this upgrade. And FlatCompat — the actual escape hatch, as covered above — is alive and shipping.

The one place this stack forces your hand is Astro. eslint-plugin-astro’s current release requires ESLint 10 outright, so an Astro project that upgrades the Astro plugin for any other reason drags ESLint along with it whether the ESLint bump was planned or not. Check both together before you touch either.

When should you upgrade?

Right now, if you’re still on ESLint 9 or earlier. The EOL already happened a month ago as of this writing; there’s no “wait for the dust to settle” version of that argument left.

This week, if you’re on ESLint 9 with flat config already migrated. Your risk surface is the monorepo lookup change and the three new default rules — both are a lint run away from being visible, not a rewrite.

After an audit, if you maintain custom rules or an internal plugin. Grep your rule implementations for getCwd, getFilename, getSourceCode, and parserOptions before you bump the version, not after CI tells you.

In a dedicated branch first, if you run a monorepo. Lint each workspace in isolation, diff the results against ESLint 9, and only then merge — the config-lookup change is exactly the kind of thing that looks fine locally and misbehaves in whichever package you didn’t personally test.

With FlatCompat as a bridge, if you depend on a shareable config that never shipped flat support. That’s not a reason to stay on an unsupported major — it’s the tool that lets you upgrade today and finish the real migration later.

Further reading:

Frequently asked questions

When did ESLint 9 reach end of life?

August 6, 2026. That is six months after ESLint 10 went GA, which is the standard support window the ESLint project gives to the previous major version. After that date, ESLint 9.x no longer receives security patches or bug fixes.

When was ESLint 10 released?

ESLint 10.0.0 reached general availability on February 6, 2026, after an alpha in November 2025. As of this writing the current patch line is in the 10.4.x range.

Can I still use .eslintrc.json with ESLint 10?

No. ESLint 10 does not read .eslintrc.js, .eslintrc.json, .eslintrc.yml, or .eslintignore under any configuration or environment variable. The ESLINT_USE_FLAT_CONFIG variable that used to force the old behavior on ESLint 9 is no longer honored. The only supported configuration file is eslint.config.js (or .mjs/.ts/.cjs).

Does FlatCompat still work on ESLint 10?

Yes. FlatCompat ships from the separate @eslint/eslintrc package and still works on ESLint 10, letting you pull an old-format shareable config into a real eslint.config.js with compat.extends(). Make sure @eslint/eslintrc itself is on a current version, since old copies predate ESLint 10.

What is the minimum Node.js version for ESLint 10?

Node.js ^20.19.0, ^22.13.0, or 24 and above. Node 21.x and 23.x are unsupported, and so is any patch version below 20.19.0 or 22.13.0 within an otherwise-supported major.

Does typescript-eslint support ESLint 10?

Yes. The current typescript-eslint release states a peer dependency range of ^8.57.0 || ^9.0.0 || ^10.0.0, so a project already on a recent typescript-eslint version does not need any changes there to move to ESLint 10.

Pest 5 and PHPUnit 13: What Breaks When You Upgrade (and What Fails Silently)

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

Pest 5 shipped at the end of July 2026, built directly on top of PHPUnit 13, and requires PHP 8.4 as a hard minimum. Pest itself introduces no API-level breaking changes — the pain is entirely inherited from PHPUnit 13’s stricter mocking rules. The part that actually hurts teams is not a fatal error: it’s that PHPUnit 13 turns several common mocking patterns into deprecation warnings instead of failures, so a suite can go fully green while quietly no longer verifying what you think it verifies. If you’re on Laravel 12, there’s a second, blunter problem: the official Pest Laravel plugin for v5 currently requires Laravel 13.23 or newer, so the plugin itself won’t install.

Where are you coming from?

The upgrade effort isn’t uniform. It depends on how many PHPUnit majors you’re jumping in one move.

Pest 4 (PHPUnit 12) → Pest 5 (PHPUnit 13). This is the intended, smallest jump. Pest 4 already required PHP 8.3, so the only hard floor to raise is PHP 8.3 → 8.4. You’re absorbing one wave of PHPUnit deprecations-to-removals (12 → 13).
Pest 3 or earlier (PHPUnit 11 or older) → Pest 5. You’re absorbing two stacked waves at once: PHPUnit 11 → 12 already removed docblock-annotation metadata (you need PHP 8 attributes: #[Test], #[DataProvider], etc.) and mock objects for abstract classes/traits, on top of everything PHPUnit 13 changes below. Skipping straight from 3 to 5 in one composer update is how a 20-minute upgrade becomes a two-day one — go through 4 first, or at least test the 12 jump in isolation.
Raw PHPUnit, no Pest, on PHPUnit 12.5. PHPUnit’s own upgrade rule is explicit: don’t move to 13 if your suite doesn’t already run clean on 12.5. If phpunit --display-deprecations shows anything, fix that first, in place, before touching the Pest or PHPUnit version constraint.

The floor you can’t negotiate: PHP 8.4

Pest 5 requires PHP 8.4.0 or greater, full stop. There’s no “works in practice on 8.3” escape hatch like some Laravel version bumps have. If your team is still on PHP 8.1, 8.2, or 8.3, that’s infrastructure work that happens before you touch composer.json for Pest — not alongside it.

php -v          # need 8.4.0 or higher

Do the PHP bump as its own deploy, verified green on the old test stack, before you also swap the test stack. Otherwise a red CI run after the upgrade tells you nothing about which of the two changes caused it.

Breaking changes, ranked by what actually hurts

1. Laravel 12 can’t use the Pest 5 Laravel plugin (blocking, not silent)

This is the one nobody mentions in the “it’s just a one-line bump” framing, and it’s the first thing that will stop a Laravel shop cold. pestphp/pest-plugin-laravel v5.0.1 declares:

{
  "require": {
    "php": "^8.4",
    "laravel/framework": "^13.23.0",
    "pestphp/pest": "^5.0.1"
  }
}

If your app is on Laravel 12, composer update will refuse to resolve pest-plugin-laravel ^5.0 — Composer will report a conflict, not a mysterious test failure. The fix isn’t a Pest problem: you need Laravel 13.23+ before Pest 5’s Laravel plugin is installable at all. If you’re mid-upgrade on both fronts, sequence it — Laravel first, Pest second — or you’ll spend an afternoon debugging a dependency graph that was never going to resolve.

2. `any()` and `with*()` without `expects()` — the suite that passes but stops verifying (silent)

This is the change that matters most, because nothing in your CI output tells you it happened. PHPUnit 13 hard-deprecates two patterns that were previously the default, lazy way to configure a mock:

// Before: works, silently means "any number of calls, don't verify order"
$mock->method('handle')->with($this->equalTo($payload));

// PHPUnit 13: emits a deprecation, but still runs and still "passes"

Deprecations in PHPUnit are warnings, not failures, unless you explicitly configure failOnDeprecation (or PHPUnit’s own failOnPhpunitDeprecation) in your suite. Which means the realistic failure mode isn’t “upgrade breaks CI on day one” — it’s “CI stays green for weeks while accumulating dozens of deprecation warnings nobody reads, and then either someone turns on strict deprecation failing, or PHPUnit 14 removes the pattern outright and the suite goes red all at once, on a date you don’t control.”

The fix is to make the intent explicit instead of relying on the implicit default:

// If you actually want to verify the call happens:
$mock->expects($this->once())->method('handle')->with($this->equalTo($payload));

// If you don't care whether it's called — use a stub, not a mock:
$stub = $this->createStub(HandlerInterface::class);
$stub->method('handle')->willReturn($result);

The any() invocation-count matcher itself is hard-deprecated for the same reason: pairing expects($this->any()) with a mock is a contradiction — mocks exist to verify interactions, and any() means “I don’t care if this happens.” PHPUnit’s own maintainers frame it plainly: if you don’t want to verify anything, you wanted a stub.

3. Laravel’s `createPartialMock()` collides with rule #2 (silent, Laravel-specific)

This is the same deprecation as above, but worth calling out on its own because it hits a helper most Laravel test suites use without thinking about it. Laravel’s testing trait wraps PHPUnit’s createPartialMock(), and that wrapper’s internal implementation triggers the “with*() without expects()” deprecation on PHPUnit 13 even when your test code looks fine:

// Triggers the deprecation on PHPUnit 13, even though this looks innocent
$class = $this->createPartialMock(NightlyCommand::class, ['runSequenceOfCommands']);

// Fixed: bypass the wrapper, use PHPUnit's builder directly
$class = $this->getMockBuilder(NightlyCommand::class)
    ->onlyMethods(['runSequenceOfCommands'])
    ->getMock();

Grep for it before you upgrade, because the deprecation count can be large if the pattern is common in your suite:

grep -rln "createPartialMock" tests/

4. Real removals — these do fail, immediately, no ambiguity

Unlike the two above, these were already hard-deprecated in PHPUnit 12 and are simply gone in 13. They throw a fatal Error, not a warning, so they surface on the first run — which is actually the easy category to deal with:

// Removed in PHPUnit 13 — fatal error, not a deprecation
$this->assertThat($value, $this->isType('string'));
$this->assertContainsOnly('string', $collection);
$this->assertNotContainsOnly('int', $collection);

// Their specialized replacements, available since PHPUnit 11.5
$this->assertThat($value, $this->isString());  // or just assertIsString($value)
$this->assertContainsOnlyString($collection);
$this->assertContainsNotOnlyInt($collection);

// For collections of objects, the old one is still there
$this->assertContainsOnlyInstancesOf(User::class, $collection);

Also removed: the --dont-report-useless-tests CLI flag, Configuration::includeTestSuite() / excludeTestSuite(), #[CoversNothing] on individual test methods (class-level only now), the #[RunClassInSeparateProcess] attribute, and support for version-constraint strings without an explicit comparison operator. None of these are common in a typical Laravel test suite, but if you maintain a package with custom PHPUnit extensions or CI tooling that shells out to phpunit directly, check your flags.

Coming from withConsecutive() specifically: that one is old news — it was removed back in PHPUnit 10 — but PHPUnit 13 finally ships proper replacements instead of leaving people writing awkward call-count workarounds:

// New in PHPUnit 13
$mock->expects($this->once())
    ->method('handle')
    ->withParameterSetsInOrder(['first'], ['second']);

$mock->expects($this->exactly(2))
    ->method('handle')
    ->withParameterSetsInAnyOrder(['first'], ['second']);

5. Test Impact Analysis needs a coverage driver, or it just doesn’t run (silent)

Pest 5’s headline feature — the Tia Engine, which claims to shrink a 10-minute Laravel suite to about 4 seconds on subsequent runs by only re-running tests affected by your diff — needs PCOV or Xdebug installed to record its baseline dependency graph. Without one, Pest doesn’t error and doesn’t warn loudly; TIA simply never activates, and your suite quietly keeps running at full length every time. If you enabled TIA expecting the speedup and nothing changed, check for a coverage driver before assuming the feature is broken:

php -m | grep -iE "pcov|xdebug"

For a team-wide setup, the sane pattern is to have CI record the baseline once per merge to main (where a coverage driver is cheap to enable) and have local machines consume that cached graph, rather than every developer running a coverage-instrumented baseline locally.

6. No config-file changes — genuinely nothing to do here

Worth stating explicitly because people expect it: the Pest 5 upgrade guide documents no changes to phpunit.xml or any Pest configuration file. If your suite runs clean under PHPUnit 13’s rules, the version bump in composer.json is the entire migration. That’s rare enough in this ecosystem that it’s worth not overthinking.

When should you upgrade?

You’re on Pest 4 / PHPUnit 12, PHP 8.4 is already your baseline, and phpunit --display-deprecations is clean. Upgrade now. This is close to the “2 minutes” the docs advertise, and TIA alone is worth it if your suite has grown past a couple thousand tests.
You’re on Pest 4 but still on PHP 8.3. Raise PHP first, verify the existing suite is still green and deprecation-free on 8.4, then bump Pest as a separate step.
You’re on Pest 3 or plain PHPUnit 11 or older. Don’t skip straight to 5. Go through the PHPUnit 12 wave first (attributes instead of docblocks, no more abstract/trait mocks), confirm the suite is clean, then take the 12 → 13 jump on its own.
You’re a Laravel shop still on Laravel 12. Pest 5’s Laravel plugin is out of reach until you’re on Laravel 13.23+. Either upgrade Laravel first, or stay on pest-plugin-laravel ^4.0 with Pest 4 until you do — don’t let Composer’s dependency resolver make that decision for you mid-upgrade.
Anyone with heavy mock usage in the suite, regardless of version. Run the deprecation grep before you touch composer.json at all. The cost of this upgrade isn’t the version bump — it’s finding out how many of your mocks were only “passing” because nothing was actually being verified.

Further reading:

Frequently asked questions

Does Pest 5 require PHP 8.4?

Yes. Pest 5 requires PHP 8.4.0 or greater as a hard minimum, with no exceptions for PHP 8.1, 8.2, or 8.3. This comes from Pest 5 running on top of PHPUnit 13, which itself requires PHP 8.4 or later.

Can I use Pest 5 with Laravel 12?

Not with the official Laravel plugin. As of pest-plugin-laravel version 5.0.1, the package requires laravel/framework ^13.23.0, so Composer will refuse to install it on a Laravel 12 application. You either need to upgrade to Laravel 13.23 or newer first, or stay on Pest 4 with pest-plugin-laravel ^4.0 until you do.

What happens if my test suite has PHPUnit deprecation warnings before I upgrade?

PHPUnit deprecation warnings do not fail a build by default, so a suite can appear to pass while using patterns that PHPUnit 13 flags, such as the any() invocation matcher or with*() calls without an explicit expects(). PHPUnit officially recommends against upgrading to 13 unless your suite already runs clean without deprecation warnings on PHPUnit 12.5, because those warnings become fatal removals in a future major version without further notice.

Is the any() matcher removed in PHPUnit 13?

No, not yet. The any() invocation-count matcher is hard-deprecated in PHPUnit 13, meaning it still works but triggers a deprecation warning, and it is scheduled for removal in PHPUnit 14. The recommended fix is to use an explicit expectation like expects($this->once()) if you want to verify a call happens, or switch to createStub() if you do not need verification at all.

Do I need Xdebug or PCOV to use Pest 5 Test Impact Analysis?

Yes. The Tia Engine needs a code coverage driver, either PCOV or Xdebug, to record the dependency graph on its first run. Without one installed and enabled, Test Impact Analysis does not raise an error; it simply does not activate, and your suite keeps running every test on every run.

How long does the Pest 5 upgrade actually take?

The official documentation estimates about 2 minutes for the composer.json version bump itself, and that estimate is accurate for the Pest-specific part of the change. The real time cost is auditing your suite against PHPUnit 13 rules beforehand, particularly mock usage patterns and, for Laravel apps, confirming you are already on Laravel 13.23 or newer.

What Breaks When You Upgrade from Symfony 7.4 to 8.1

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

If you’re on Symfony 8.0, you’ve been running unsupported code since July 30, 2026 — 8.0 got exactly eight months of support and it’s over. If you’re on 7.4, you’re fine for years, but you still have to decide whether to stay on the LTS or move to 8.1, released May 29, 2026. Neither path is a rewrite. Both have changes that don’t throw an error — they just quietly change what your application does.

Symfony 7.4 and 8.0 shipped the same day, November 27, 2025, with identical features. The only difference is that 7.4 kept the deprecation layers accumulated since 7.0, and 8.0 deleted them. That’s the whole story of “Symfony 8”: it’s 7.4 with the safety net removed. 8.1, released half a year later, adds real new features on top and is the version you land on if you take the regular (non-LTS) track.

Where are you coming from?

You’re on	Status today (Sep 2026)	What to do
Symfony 8.0	Unmaintained since Jul 30, 2026 — no bug fixes, no security patches	Upgrade to 8.1 now. Same deprecation-free codebase, no code changes required by the BC promise
Symfony 7.4 (LTS)	Bug fixes until Nov 2028, security until Nov 2029	Stay, or move to 8.1 for new features. No urgency either way
Symfony 6.4 (LTS) or older	6.4: bug fixes until Nov 2026, security until Nov 2027. Of the older branches only 5.4 LTS still gets patches, security-only (until Feb 2029)	Go through 7.4 first, without waiting for the 6.4 window to close. Fix every deprecation there with `phpunit --display-deprecations`, then decide 7.4-LTS vs 8.x

The reference table, straight from symfony.com/releases:

Version	Type	Released	PHP min	Bug fixes until	Security until
7.4	LTS	Nov 27, 2025	8.2.0	Nov 2028	Nov 2029
8.0	Regular	Nov 27, 2025	8.4.0	Jul 2026	Jul 2026
8.1	Regular	May 29, 2026	8.4.0	Jan 2027	Jan 2027

Two things worth reading twice: 8.0’s entire support window was eight months, both bug fixes and security together — that’s the standard policy for a non-LTS minor, not a shortened one. And 8.1 requires PHP 8.4, a full two versions ahead of what 7.4 needs. If you’re still on PHP 8.2 or 8.3, raising the PHP version is real infrastructure work, separate from anything in this list — do it first, verify it, then touch composer.json.

High impact

1. XML configuration is gone — and it broke in silence first

This is the one that catches people off guard, because it doesn’t fail the day it should. Symfony 7.4 deprecated XML configuration; Symfony 8.0 removed it outright. If your bundles, routes, or services are configured in XML and nobody was watching the deprecation log during the 7.4 window, the upgrade to 8.0 or 8.1 is a hard stop: the loader is gone, not just discouraged.

// Removed without alternative in Symfony 8.0
ExtensionInterface::getXsdValidationBasePath()
ExtensionInterface::getNamespace()

Routing, FrameworkBundle, and WebProfilerBundle no longer load XML routes at all. YAML remains the default and stays fully supported. PHP is the recommended alternative for code-based configuration, and it changed shape too (see #4). There’s an automated converter for bundle maintainers — symfony-config-xml-to-php — but application-level XML config you’ll be rewriting by hand.

The reason this qualifies as “breaks in silence”: the deprecation notice in 7.4 is just a log line. Nobody greps deprecation logs on a schedule. The failure shows up months later, on the 8.x upgrade, as a fatal error that looks unrelated to anything you changed that week.

2. Security: erased credentials, firewall listeners, error exposure

Three changes land in the same component and compound:

UserInterface::eraseCredentials() and TokenInterface::eraseCredentials() are removed. Use __serialize() to control what survives on the token instead.
Firewall listeners must extend AbstractListener or implement FirewallListenerInterface. Registering a bare callable as a listener no longer works.
hide_user_not_found is gone; use expose_security_errors.

# Symfony <= 7.x
security:
    hide_user_not_found: false

# Symfony >= 8.0
security:
    expose_security_errors: account_status  # none | account_status | all

expose_security_errors is more precise than the boolean it replaces — account_status shows exceptions only for users who supplied the correct password, all hides nothing, none is the safe default. If your security.yaml still has hide_user_not_found, the container fails to compile on 8.x. That one is loud. What isn’t loud: remember-me cookies. RememberMeDetails no longer embeds the user’s fully-qualified class name in the cookie payload. Old cookies issued before the upgrade fail to authenticate silently — the user isn’t shown an error, they’re just logged out and have to sign in again. If you run a high-traffic app, expect a support-ticket spike the week you deploy, not an incident alert.

3. Console commands: static metadata methods removed

// Symfony <= 7.x
class SyncCommand extends Command
{
    protected static function getDefaultName(): string
    {
        return 'app:sync';
    }
}

// Symfony >= 8.0
#[AsCommand(name: 'app:sync')]
class SyncCommand extends Command
{
}

Command::getDefaultName() and getDefaultDescription() are removed — use the #[AsCommand] attribute. Application::add() is replaced by Application::addCommand(). If you register commands dynamically by instantiating Command subclasses and pushing them into the application, this is a mechanical but mandatory rename.

Medium impact

4. Fluent PHP config is gone; there’s a new array-shape format

Symfony 5.3 introduced a fluent, builder-style PHP configuration format (SecurityConfig, FrameworkConfig, and friends). It’s removed in 8.0. What replaces it isn’t a return to arrays-as-usual — it’s a new array-shape PHP format with typed metadata that IDEs and static analyzers can actually understand.

// Removed: fluent PHP config
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $security->firewall('main')->pattern('^/*')->lazy(true);
};

// New: array-shape PHP config
namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return App::config([
    'security' => [
        'firewalls' => [
            'main' => ['pattern' => '^/*', 'lazy' => true],
        ],
    ],
]);

The stated reason is that the fluent builders couldn’t represent every semantic config tree shape, which made keeping Symfony recipes automatically up to date needlessly hard. YAML is still the recommended default; this format is for teams that specifically want PHP.

5. Doctrine: no more auto-mapping entities in controller arguments

The ParamConverter-style auto-mapping of route parameters straight into Doctrine entity arguments is removed. If a controller action typed a Doctrine entity and relied on the bundle resolving it from the route implicitly, that resolution is gone — you now wire it explicitly with #[MapEntity] or fetch it yourself in the action body. DoctrineExtractor::getTypes() is also gone; use getType().

6. HttpFoundation: `Request::get()` removed, method override narrowed

// Removed
$request->get('id');

// Use the specific bag
$request->attributes->get('id');
$request->query->get('id');
$request->request->get('id');

Request::get() searched attributes, then query, then the request body, in that order — convenient and a frequent source of bugs when two bags had the same key. It’s gone; be explicit about which bag you mean. Separately, HTTP method override (X-HTTP-METHOD-OVERRIDE / _method) no longer applies to GET, HEAD, CONNECT, or TRACE — those are meant to be safe and idempotent, and Symfony now enforces it at the request layer instead of trusting the override header.

7. Form: `UrlType` stops guessing a protocol

// Symfony <= 7.4: default_protocol defaults to 'http'
// typing "example.com" into the field saves "http://example.com"

// Symfony >= 8.0: default_protocol defaults to null
// typing "example.com" saves "example.com" — no protocol prepended

This is one of the few 8.0 breaks that doesn’t blow up. Since 7.1, leaving default_protocol unconfigured triggered a deprecation; if nobody read it, the default flips on 8.0 without a word. If your forms use UrlType and you display or link that value later assuming it always has a scheme, it now doesn’t unless the user typed one. Nothing errors; you get a relative-looking string that behaves like a broken link the first time someone clicks it. To keep the old behavior, set 'default_protocol' => 'http' on the field.

New in 8.1 that changes behavior without an error

This is the section worth reading closely if you’re already past 8.0 and evaluating 8.1, because none of these throw — they just do something different.

8. Messenger no longer throws on decode failure

Serializers now return an Envelope wrapping a MessageDecodingFailedException instead of throwing it. If your transport or middleware caught MessageDecodingFailedException around the decode call, that catch block stops firing. The failure isn’t surfaced as an exception anymore — it’s data on the envelope that you have to check for. Code that isn’t updated for this will silently process (or silently drop) a decode failure that used to be impossible to miss.

9. `ParameterBag::getInt()` / `getBoolean()` start throwing

The opposite direction from the previous one: these used to silently coerce an unconvertible value to 0 or false. In 8.1 they throw UnexpectedValueException instead. This is a case where 8.1 turns a previous silent failure into a loud one — good for catching bad input, but it means code that leaned on the old fallback needs a try/catch or upstream validation now.

10. Required collapsed `ChoiceType` renders its placeholder as `hidden`

A required, non-expanded ChoiceType field now marks its placeholder <option> with the hidden attribute instead of just being an empty-value option. Purely visual, but if you have JavaScript or CSS that selects on the placeholder option, or automated UI tests asserting on its markup, this is a quiet DOM change. Restore the old behavior with placeholder_attr: [] if you need it.

What does NOT break

Symfony 8.0 and 8.1 are not “the next 7.x.” They removed deprecations; they didn’t add a wave of new breaking behavior beyond that removal. Most of what breaks on the 7.4→8.0 jump is stuff that was already deprecated and logged in 7.x — if you cleared deprecations on 7.4, the 8.0 upgrade is close to a non-event.
YAML configuration is not going anywhere. It’s explicitly the format Symfony recipes keep targeting.
The 8.1 upgrade from 8.0 needs no code changes under the backward-compatibility promise — 8.1 is a minor version on top of 8.0, not a major.

The actual migration flow

Land on 7.4 first if you’re not there. Even if your target is 8.x, upgrading onto the LTS gives you the deprecation layer to work against.
Run the deprecation report and fix what’s yours:

php bin/phpunit --display-deprecations

To fail the suite only on deprecations from your own code, not from third-party packages you don’t control yet, don’t reach for the old SYMFONY_DEPRECATIONS_HELPER=weak_vendors: that mode was removed in symfony/phpunit-bridge 5.0, and on PHPUnit 10 or newer the bridge doesn’t even register its deprecation handler. The current way is phpunit.dist.xml, the way the Flex recipe ships it:

<phpunit failOnDeprecation="true">
    <source ignoreSuppressionOfDeprecations="true" ignoreIndirectDeprecations="true">
        <include>
            <directory>src</directory>
        </include>
        <deprecationTrigger>
            <function>trigger_deprecation</function>
        </deprecationTrigger>
    </source>
</phpunit>

ignoreIndirectDeprecations drops deprecations triggered by third-party code — useful for triaging what’s actually actionable this sprint. If your suite is still on PHPUnit 9 with simple-phpunit, the equivalent is SYMFONY_DEPRECATIONS_HELPER='max[self]=0'.

Automate the mechanical renames with Rector. rector/rector-symfony ships upgrade sets that handle a chunk of this list — getDefaultName() → attribute, deprecated method calls, and similar — without hand-editing every file.
Update dependencies and let Flex apply new recipes:

composer require symfony/symfony:^8.1 --with-all-dependencies

Grep for what’s specific to your app before you assume the automation caught it:

grep -rln '<?xml' config/
grep -rn "hide_user_not_found\|->get(" config/ src/
grep -rn "getDefaultName\|getDefaultDescription" src/

Diff your config/ tree against a fresh symfony/skeleton on the target branch. Most of what’s on this list lives in configuration files, not framework code, and composer update won’t touch config for you.

When should you upgrade?

On 8.0 today: move to 8.1 immediately. There’s no code-change cost under the BC promise, and every day past July 30, 2026 is a day without security patches.
On 7.4, stable, no pressure for new features: stay. You have until November 2028 for bug fixes and November 2029 for security. There’s no clock forcing a move.
On 7.4, want the newest features or plan to track the regular release cadence: go to 8.1 now, then follow the twice-yearly minors (8.2 is due November 2026). Fix deprecations from XML config, fluent PHP config, and hide_user_not_found before you jump, not during.
On 6.4 or older: 6.4 LTS loses bug fixes in November 2026 and security fixes in November 2027; everything older gets nothing, except 5.4 LTS, which keeps security-only fixes until February 2029. Route through 7.4, clear every deprecation with PHPUnit, then pick LTS-vs-regular based on how much you want the newest features versus a long, quiet support window.

Further reading:

What Breaks When You Upgrade to Vite 8 (and Rolldown)

Marco Orta — Wed, 02 Sep 2026 00:00:00 GMT

Vite 8 shipped stable on March 12, 2026, and it replaces both Rollup and esbuild with a single Rust bundler, Rolldown. Most of what breaks does so quietly: no red error, just different output. And here’s the part that catches people off guard — if you upgraded to Astro 7 any time after its June 2026 release, you got Vite 8 bundled underneath, whether you asked for it or not. This site runs Astro 7.2.2, and its node_modules/astro/package.json pins "vite": "^8.0.13". If you followed the Astro 7 migration, this post is the part nobody told you about.

Where are you coming from?

The list below applies differently depending on how you got here:

You run Vite directly and you’re on Vite 7. The straightforward case. Read the config renames and the CJS interop section, run a build, done.
You’re on Vite 6 or earlier. You’re jumping two majors’ worth of changes at once — the Vite 7 migration (Node 20.19+, ESM output) plus everything below. Do it in two steps: land on 7 first, verify, then go to 8.
You didn’t touch Vite. You upgraded Astro, Nuxt, SvelteKit, or another meta-framework, and Vite 8 came along. This is the group this post is really for. Nobody put “new bundler” in your changelog entry; it just showed up as a vite line in package-lock.json. Everything from here still applies to you — you just didn’t choose the timing.

What actually changed, in one screen

Area	Vite 7	Vite 8
Production bundler	Rollup	Rolldown (Rust)
Dev-time dependency pre-bundling	esbuild	Rolldown
JS transform / minify	esbuild	Oxc
CSS minify	esbuild	Lightning CSS
`build.rollupOptions`	valid	deprecated, renamed `build.rolldownOptions`
Distribution	ESM	ESM only (unchanged, just stricter)
Node.js minimum	20.19+ / 22.12+	same
Install size	baseline	+~15 MB (native binaries)
Default `build.target`	Chrome 107, Safari 16.0	Chrome 111, Safari 16.4

The headline number is real: Vite’s own announcement cites Linear’s production build dropping from 46s to 6s, Ramp at 57% faster, Beehiiv at 64%, Mercedes-Benz.io at 38%. Those are the upside. The rest of this post is the part that doesn’t make the release notes headline.

Breaking changes, ordered by impact

1. CommonJS default imports resolve differently — silently

This is the one worth reading twice, because it produces no build error. Vite 8’s migration guide is explicit: the default import from a CJS module used to resolve inconsistently between dev and build; now it’s consistent, but the rule changed. The default import is the whole module.exports value only if one of these is true — the importer is .mjs/.mts, the importer’s closest package.json has "type": "module", or the CJS module’s __esModule flag isn’t true. Otherwise you get module.exports.default.

In practice, this means a working import can start returning a wrapper object instead of the function you expect:

// cjs-pkg ships: module.exports = { __esModule: true, default: function greet() {} }

import greet from 'cjs-pkg';
greet(); // Vite 7, dev: worked
          // Vite 8, plain .js without "type": "module": TypeError: greet is not a function

The escape hatch is one line, and it buys you time to fix imports one by one instead of all at once:

// vite.config.js
export default defineConfig({
  legacy: { inconsistentCjsInterop: true }, // restores the old, inconsistent behavior
});

It’s marked deprecated on purpose — treat it as a bridge, not a destination. If a third-party package is the one tripping this, the docs ask you to report it to the package author with a link to Rolldown’s CJS interop explanation, not just patch around it forever.

2. `build.rollupOptions` is now `build.rolldownOptions`

This one at least fails loudly enough to notice — a deprecation warning on every build, not a crash yet, because a compatibility shim keeps the old key working:

// Before (Vite 7)
export default defineConfig({
  build: {
    rollupOptions: {
      input: { main: './src/main.ts' },
    },
  },
});

// After (Vite 8)
export default defineConfig({
  build: {
    rolldownOptions: {
      input: { main: './src/main.ts' },
    },
  },
});

worker.rollupOptions gets the same treatment (worker.rolldownOptions). If you have both in a monorepo config that’s shared across packages, grep -rn "rollupOptions" . before you start finds every place at once.

3. `manualChunks` as an object is gone, not deprecated — removed

Buried inside the rename above is a sharper edge: the object form of output.manualChunks is not supported anymore, full stop. Only the function form still works, and it’s marked deprecated too, in favor of Rolldown’s own codeSplitting option.

// Vite 7 — this pattern is common in real configs
build: {
  rollupOptions: {
    output: {
      manualChunks: {
        vendor: ['react', 'react-dom'], // object form
      },
    },
  },
},

// Vite 8 — object form throws at build time; convert to a function, minimum viable fix
build: {
  rolldownOptions: {
    output: {
      manualChunks(id) {
        if (id.includes('node_modules/react')) return 'vendor';
      },
    },
  },
},

This is the one most likely to actually break your build (not just warn), because plenty of copy-pasted Vite configs use the object form for vendor splitting.

4. `build.commonjsOptions` is now a no-op

No warning, no error — it’s just ignored. If your config sets build.commonjsOptions.include, .exclude, or .requireReturnsDefault to work around a specific CJS package, that workaround silently stops applying after the upgrade. The symptom shows up downstream, in whatever the option used to fix, not at the config line itself — which makes it easy to blame the wrong thing.

5. Node.js 20.19+ / 22.12+ is a hard floor, and it’s about `require(esm)`

Same requirement as Vite 7, so if you’re coming from there this changes nothing. But if you’re jumping from Vite 6, this is new: Vite ships ESM-only, and those specific patch versions are the ones where Node supports require(esm) without a flag — the mechanism that lets a CJS-era toolchain still load an ESM-only package. Anything older fails to even install correctly, not just run oddly.

6. Yarn PnP: no official verdict, but it’s not solid

Vite’s own docs don’t carry a “Yarn PnP: unsupported” line, but the rolldown-vite issue tracker has multiple open reports of dependency resolution failing specifically under Yarn’s Plug’n’Play mode — packages that resolve fine with node_modules throwing Failed to resolve import under PnP. If your team runs Yarn Berry with nodeLinker: pnp, treat Vite 8 as “test in a branch before touching CI,” not as a safe drop-in yet.

7. Install size grows by roughly 15 MB

Confirmed in the release announcement: about 10 MB from Lightning CSS (now the default CSS minifier, no longer optional) and about 5 MB from Rolldown’s native binary. Nothing breaks functionally, but if you build Docker images with tight layer budgets or you’re vendoring node_modules into a Lambda bundle, this is a real line item to check — and it applies even if you never touch Vite directly, because it rides in as Astro’s (or Nuxt’s, or SvelteKit’s) dependency.

8. Default browser targets moved up — and old browsers fail without a build warning

build.target defaults jumped: Chrome 107→111, Edge 107→111, Firefox 104→114, Safari 16.0→16.4, aligned to Baseline Widely Available as of January 2026. Vite compiles happily either way — the failure, if you have one, shows up as broken JavaScript in an old Safari in someone’s production analytics, weeks later, with nothing in your build log pointing at the cause. If you have a documented browser support matrix that includes anything older than Safari 16.4, set build.target explicitly instead of trusting the default.

9. Plugins mostly just work — with two real exceptions

Rolldown implements the same plugin API as Rollup, and the framework plugins that matter are already updated: @vitejs/plugin-react v6 uses Oxc instead of Babel for the Refresh transform (v5 still runs fine on Vite 8 if you haven’t upgraded it yet), and @vitejs/plugin-vue needs no changes. Where it actually breaks:

Plugins that lean on the moduleParsed hook: it’s documented as not called during dev at all, to avoid a full AST parse on every file.
Plugins built against esbuild’s own onLoad/onResolve plugin format (not Rollup’s) — those are a different API entirely and Rolldown doesn’t speak it. If a plugin’s README mentions “esbuild plugin,” check for a Rolldown-native replacement before assuming it upgrades for free.

When should you upgrade?

You run Vite directly, already on 7, no exotic CJS dependencies: upgrade now. The build-time win is real and the breaking surface is small if you don’t rely on manualChunks as an object.

You’re on Vite 6: go through 7 first. Vite maintains a rolldown-vite package that’s “Vite 7 with Rolldown, nothing else” specifically as an intermediate step — use it to isolate the bundler change from the version-jump change.

You got here via Astro 7 (or Nuxt, SvelteKit, similar): you’re already running it. The move isn’t “should I” — it’s auditing your existing vite.config for rollupOptions.output.manualChunks as an object and any commonjsOptions overrides, since those are the two that fail or go silent without you touching the framework version at all.

Your team runs Yarn PnP: wait, or pin to rolldown-vite@7.x and watch the open issues before moving to Vite 8 proper.

You maintain a Rollup plugin with heavy moduleParsed or output-hook usage: budget real time, not a config tweak — that’s an API-shape problem, not a rename.

Further reading:

Upgrading to Astro 7 — the framework upgrade that brings Vite 8 with it, and its own separate set of traps.
What breaks upgrading to Node 26 — the runtime side of the same “silent breakage” problem, for the version most Vite 8 installs run on.
What breaks upgrading to TypeScript 7 — same format, same instinct: rank by impact, flag what fails without an error.

Frequently asked questions

Does Astro 7 use Vite 8?

Yes. Astro 7.0.0 already pins "vite": "^8.0.13" in its package.json, and every Astro 7.x release since inherits it. If you upgraded from Astro 6 to Astro 7, you got Vite 8 and its Rolldown bundler automatically, without a separate Vite upgrade step of your own.

What breaks silently when upgrading to Vite 8?

Two things produce no build error at all: CommonJS default-import resolution changed rules (a working "import x from cjs-pkg" can start returning a wrapper object instead of the value you expect), and build.commonjsOptions became a no-op, so any include/exclude/requireReturnsDefault workaround in your config silently stops applying. Both fail downstream, not at the config line, which makes them easy to misdiagnose.

Why did build.rollupOptions stop working in my vite.config.js?

It was renamed to build.rolldownOptions because Vite 8 replaced Rollup with Rolldown as its bundler. The old key still works through a deprecation shim and prints a warning on every build, but it will eventually be removed. worker.rollupOptions follows the same rename to worker.rolldownOptions.

Can I still use manualChunks as an object in Vite 8?

No. The object form of output.manualChunks was removed entirely, not just deprecated, and using it throws at build time. Only the function form still works, and it is itself marked deprecated in favor of Rolldown's codeSplitting option. Vendor-splitting configs copied from older tutorials are the most common place this shows up.

Is Vite 8 compatible with Yarn PnP?

There is no official statement either way in the Vite documentation, but the rolldown-vite issue tracker has multiple open reports of dependency resolution failing under Yarn's Plug'n'Play mode as of this writing. Teams on Yarn Berry with nodeLinker: pnp should test in a branch before rolling Vite 8 into CI, or stay on the rolldown-vite@7.x intermediate package.

Do I need to update @vitejs/plugin-react or @vitejs/plugin-vue for Vite 8?

Not strictly. @vitejs/plugin-vue works unmodified, and @vitejs/plugin-react v5 still runs on Vite 8. Version 6 of plugin-react is the recommended upgrade because it moved from Babel to Oxc for the Fast Refresh transform, which is smaller to install and matches the rest of Vite 8's toolchain, but it is not a hard requirement.

PHP 8.6: What Actually Breaks When You Upgrade

Marco Orta — Sat, 29 Aug 2026 00:00:00 GMT

PHP 8.6 ships on November 19, 2026, and the change most likely to break your application in production is not a removed function — it is three session settings whose defaults flip. session.use_strict_mode, session.cookie_httponly and session.cookie_samesite all change, and the failure mode is silent: nothing throws, users just stop staying logged in on cross-site requests.

Everything else is mostly deprecations, which means warnings rather than fatals. But there are four genuine behavior changes hiding among them, and two of those are the kind that change results without saying anything.

This is the breakage list. If you want the new features — Partial Function Application, clamp(), the SortDirection enum — those are in everything new in PHP 8.6.

How settled is this list?

Worth stating up front, because “PHP 8.6 breaking changes” articles were being published before there was anything to report.

The release timetable is public: alpha 1 landed on July 2, beta 1 and the soft feature freeze on August 13, the hard feature freeze is September 22, RC1 arrives September 24 and RC4 on November 5, and GA is November 19, 2026.

What that means for this article:

The deprecations are settled. They come from RFCs that have already been voted, and voted RFCs do not get un-voted.
The list can still grow. Between now and the hard freeze, RM-approved changes can still land, and bug fixes after that occasionally add upgrade notes.
There is no official migration page yet. php.net/manual/en/migration86.php does not exist at the time of writing — the source of truth today is the UPGRADING file on php-src’s master branch, which is where everything below comes from.

I will update this article after the hard freeze and RC1 on September 24, when the list is effectively final.

The one that will actually break production

Session security defaults flip

Three php.ini defaults change:

Setting	Before	PHP 8.6
`session.use_strict_mode`	`0`	`1`
`session.cookie_httponly`	`0`	`1`
`session.cookie_samesite`	`""`	`"Lax"`

Each one is the right default. Together they are the most disruptive change in the release, because none of them throws an error. Your application keeps running and some users stop being logged in.

cookie_samesite = "Lax" is the one that bites. A Lax cookie is not sent on cross-site POST requests. If anything posts to your application from another origin — a payment gateway returning the user via POST, an identity provider’s callback, an embedded form, a webhook that relies on a session — that request now arrives without a session. The user lands on a login screen for no visible reason.

cookie_httponly = 1 means JavaScript can no longer read the session cookie via document.cookie. That is correct, and it breaks any front-end code that was reading the session ID directly — some older analytics snippets and hand-rolled AJAX auth do this.

use_strict_mode = 1 makes PHP reject session IDs it did not generate itself, which is the actual fix for session fixation. It breaks flows that pass a session ID in from outside.

If you need the old behavior temporarily, set it explicitly rather than relying on the previous default:

; only as a stopgap while you fix the real cause
session.cookie_samesite = "None"
session.cookie_secure = 1   ; required whenever SameSite=None

Note that SameSite=None without Secure is rejected by browsers, so this is not a one-line revert.

The honest advice: do not revert. Set these three explicitly in your php.ini today, on PHP 8.5, and find out what breaks while you still control the timing. That converts a release-day surprise into a Tuesday afternoon.

The behavior changes that stay quiet

`trim()` now strips form feed

trim(), ltrim() and rtrim() add \f (form feed, 0x0C) to their default character list. It was the one ASCII whitespace character they did not strip.

trim("hello\f");
// PHP 8.5 → "hello\f"
// PHP 8.6 → "hello"

This is almost always what you wanted. It is listed here because it changes output silently, and if you have tests asserting on exact strings from parsing fixed-width files, legacy print streams or anything that carries form feeds, they will start failing without an obvious cause.

NUL bytes now throw instead of being tolerated

A large set of functions now throw ValueError when passed a string containing a NUL byte, rather than truncating or behaving unpredictably. The list includes getenv(), putenv(), parse_str(), setlocale(), dl(), openlog(), proc_open() (the $cwd argument), and roughly twenty filesystem functions — file_exists(), is_file(), filesize(), stat() and their relatives.

This is a security hardening measure, and NUL bytes in these arguments have historically been a path-traversal vector. The practical impact is that code passing unsanitized user input to filesystem checks now gets a loud exception instead of quiet nonsense:

// PHP 8.5: returns false, no signal
// PHP 8.6: throws ValueError
file_exists($_GET['path']);   // when $_GET['path'] contains "\0"

If your application does this, the exception is telling you about a bug that was already there.

`unpack()` reinterprets `<` and `>`

unpack() now treats < and > after a format code as endianness modifiers rather than as part of the name. This changes how existing format strings parse:

unpack("s<value", $data);
// PHP 8.5 → key "<value"
// PHP 8.6 → little-endian short, key "value"

unpack("C>name", $data);
// PHP 8.6 → throws (C has no endianness)

Narrow, but if you parse binary formats it is a hard break rather than a deprecation. Grep for unpack( and check whether any format string has a < or > in a name.

`SessionHandlerInterface` wants two more methods

Custom session handlers that do not implement create_sid() and validateId() now emit deprecation notices. If you wrote a database- or Redis-backed session handler by hand, it probably implements the six original methods and not these two — and validateId() is what makes use_strict_mode actually work, so this connects back to the change above.

The deprecations

None of these are fatal in 8.6. They emit E_DEPRECATED, and they are the removal list for PHP 9.

return inside finally. Returning from a finally block discards any return value or exception from the try, which is almost always a bug being hidden. Now deprecated.

function f() {
    try { return 1; }
    finally { return 2; }   // deprecated — silently wins, returns 2
}

Returning a value from a constructor. Returning a value from __construct() or __destruct(), or turning either into a generator, now deprecates at compile time — you will see it even if the code never runs. It passed 39 to 0, and becomes an error in the first major after 8.6.

class Foo {
    public function __construct() {
        return 123;   // deprecated at compile time
    }
}

class Bar {
    public function __construct() {
        if (random_int(0, 1)) {
            return;   // still perfectly legal — a bare return is fine
        }
    }
}

array_filter() throws on an invalid $mode. It used to ignore a bad mode silently; now it raises ValueError. Strictly an improvement, but it can take down code that had been passing a wrong constant unnoticed for years.

php://filter caps chained filters. A limit on how many filters you can chain, as hardening against a known filter-chain exploitation technique. Only relevant if you build filter chains deliberately.

All of mbregex. Every mb_ereg* function is deprecated, because the Oniguruma library behind them is unmaintained. This is the largest deprecation in the release by surface area. The migration is to PCRE — preg_match() and friends, with the u modifier for Unicode:

mb_ereg('^[0-9]+$', $s);      // deprecated
preg_match('/^[0-9]+$/u', $s); // replacement

The patterns are not always a direct translation, so this one deserves real test coverage rather than a find-and-replace.

Type-check and conversion aliases. is_double(), is_long(), is_integer() and doubleval() are deprecated in favor of is_float(), is_int() and floatval(). Also deprecated: metaphone(), strcoll(), spl_object_hash(), spl_classes(), and the SORT_LOCALE_STRING sort flag.

spl_object_hash() is the one worth flagging — replace it with spl_object_id(), which is what you almost certainly meant.

SPL CSV and ArrayIterator methods. SplFileObject::fgetcsv(), fputcsv(), setCsvControl() and getCsvControl() are deprecated, as are ten ArrayIterator methods: getFlags(), setFlags(), asort(), ksort(), uasort(), uksort(), natsort(), natcasesort(), serialize() and unserialize().

Object arguments where they never made sense. array_walk(), mb_convert_variables(), and the zlib and bz2 stream filters now deprecate object arguments.

mysqli odds and ends. mysqli_get_charset() and mysqli_stmt_init() are deprecated. SOAP’s classmap option now rejects integer keys.

What to actually do, in order

Set the three session settings explicitly on PHP 8.5, now. This is the whole risk of the release concentrated in one change, and it is the only one you can test before 8.6 exists. Check every cross-site POST that hits your application.
Turn on deprecation reporting and run your test suite. error_reporting(E_ALL) with a log you actually read. Most of this release surfaces there.
Grep for the specific names. mb_ereg, is_double, is_long, is_integer, doubleval, spl_object_hash, metaphone, strcoll, unpack(. That is a twenty-minute pass and it covers most of the deprecation list.
Check custom session handlers for create_sid() and validateId().
Leave trim() alone unless a test fails. If one does, you have learned something about your input data.

What does not break

Worth saying, because upgrade anxiety fills in blanks that are not there. PHP 8.6 removes nothing that was deprecated in 8.x — the removals land in PHP 9. Your typed properties, enums, readonly classes, fibers and attributes are untouched. If your application runs clean on 8.5 with deprecations silenced, the realistic worst case for 8.6 is a noisy log plus the session change.

The session change is not a small caveat, though. It is the reason this article exists.

Frequently asked questions

When is PHP 8.6 released? November 19, 2026. The hard feature freeze is September 22 and the release candidates run from September 24 to November 5.

What is the most dangerous change in PHP 8.6? The session defaults: session.use_strict_mode and session.cookie_httponly become 1, and session.cookie_samesite becomes "Lax". They fail silently — users stop staying logged in on cross-site POST requests instead of getting an error.

Does PHP 8.6 remove anything? No. It deprecates a great deal — all of mbregex, several type-check aliases, SPL CSV methods — but removals are scheduled for PHP 9. Deprecations emit warnings, not fatal errors.

Is mb_ereg really going away? It is deprecated in 8.6 because Oniguruma, the library behind it, is unmaintained. Migrate to PCRE (preg_match and friends with the u modifier). Patterns do not always translate one to one, so test rather than find-and-replace.

Everything new in PHP 8.6 — the features side: Partial Function Application, clamp(), the SortDirection enum.
What breaks upgrading to Laravel 13 — Laravel 13 requires PHP 8.3 or later, so these two upgrades often land in the same sprint.

The Best MCP Servers for SEO and GEO in 2026: Which One to Connect for Your Case

Marco Orta — Sat, 22 Aug 2026 00:00:00 GMT

There is no single “best MCP server for SEO”: there’s a best one for each kind of data. If you want to read your own site’s real performance, the Google Search Console MCP is free and nobody has more accurate data. If you need third-party data — keywords, competitors, SERPs — the decision sits between DataForSEO (pay per query) and Ahrefs or Semrush (subscription). And if your question is a GEO question — can ChatGPT read and cite my site? — that layer is covered by audit tools like my seo-geo-mcp, which is open source and doesn’t even ask for an API key.

By mid-2026, practically every major SEO platform either has an official MCP server or is racing to ship one. That’s good and bad at once: there’s plenty to choose from, but the “12 best” listicles mix things that don’t actually compete with each other. This guide sorts them by the only question that truly decides: whose data does your agent need?

If you’re not yet clear on what MCP is or how an agent uses these connections, start with the guide to agentic AI, agents and MCP and come back: this piece assumes that base.

The full table

Server	Data it exposes	Price	Type
Google Search Console	Clicks, impressions, CTR, positions for your site	Free	Community only: Google has no official one
Google Analytics 4	Events, conversions, funnels for your site	Free	Official (experimental)
DataForSEO	SERPs, keywords, backlinks, on-page (Google, Bing, Baidu)	Pay per query	Official
Ahrefs	20 tool groups: Site Explorer, Keywords, Site Audit, Rank Tracker, Brand Radar	Unit-based, per plan	Official
Semrush	Keywords (28B+, 142 regional databases), competitive data	Tied to subscription	Official
SE Ranking	180+ tools: keywords, audits, backlinks, AI visibility	Tied to subscription or pay-as-you-go API	Official
Nightwatch	Rankings (Google/Bing/YouTube) + AI visibility	Paid plans	Official
Advanced Web Ranking	48 historical rank-tracking and comparison tools	Agency plan and up	Official
Screaming Frog	Orchestrating crawls and technical audits from the agent	With the license (v24+)	Official, local
Peec AI	Citations and visibility across 8 AI engines (ChatGPT, Perplexity, Gemini, Claude, Copilot…)	Paid plans	Official
seo-geo-mcp	17 on-page + GEO audit tools: robots, AI crawlers, schema, hreflang	Free, no API keys	Open source (npm), local or self-hosted

Tool counts and pricing come from each platform’s documentation and from the comparative write-ups by Nightwatch and MCP.Directory; what lands on your invoice depends on your plan.

How each one connects and what it costs to get in

Verified on September 13, 2026 against each platform’s documentation and pricing page (linked). “Remote” means a server the platform hosts and you reach over HTTP; “local” means a process running on your machine, usually over stdio. List prices in US dollars or euros, before tax and billed monthly unless noted.

Server	Transport	Authentication	Entry price
Google Search Console	Local (stdio), community implementations	Google Cloud credentials (OAuth or service account)	$0
Google Analytics 4	Local (stdio, `pipx run analytics-mcp`)	Google Cloud credentials, read-only scope	$0
DataForSEO	Remote (`mcp.dataforseo.com/v3/mcp`), local HTTP or stdio	OAuth over HTTP; API login and password over stdio	$1 trial credit on sign-up; $50 minimum top-up
Ahrefs	Remote (`api.ahrefs.com/mcp/mcp`)	OAuth or MCP key	Lite plan, $129/month; uses the plan’s API units
Semrush	Remote (`mcp.semrush.com/v2/mcp`)	OAuth or API key	Semrush One Starter, $199/month, or another plan on their list; they include 50,000 API units
SE Ranking	Remote	You authorize the connection with your account	Trial with 100,000 credits, no card; pay-as-you-go API from $50 for 250,000 credits
Nightwatch	Remote (`mcp.nightwatch.io`, SSE)	Bearer token	Starter, €79/month billed yearly (€948/year); MCP on every plan
Advanced Web Ranking	Remote (`api.advancedwebranking.com/mcp`)	OAuth or API key	Agency plan, $279/month
Screaming Frog	Local, alongside SEO Spider v24+ (stdio or Streamable HTTP)	The app’s license	$279/year license; the MCP doesn’t work in the free version
Peec AI	Remote (`api.peec.ai/mcp`)	OAuth or personal access token	Starter, $95/month
seo-geo-mcp	Local (stdio, `npx -y seo-geo-mcp-server`) or self-hosted HTTP	None (optional Bearer token over HTTP)	$0

Two warnings that don’t fit in the table. Ahrefs’ local repository (ahrefs/ahrefs-mcp-server) is archived and its own README tells you not to use it: the official server is the remote one. And neither Google nor Microsoft ships an MCP for their webmaster consoles: Google’s official MCP server list includes Analytics but not Search Console, and the request for an official one is still open; for Bing Webmaster Tools I couldn’t find one from Microsoft either, only community implementations.

Case 1: you want to read YOUR own site’s data

Start here, because it’s free and it’s the most accurate data in existence. The Google Search Console MCP gives your agent direct access to clicks, impressions, CTR and position by query and by page — the same first-party data you see in the console, with no third-party sampling. Mind the name, though: Google doesn’t publish a Search Console MCP. Every implementation is open source and community-built, and all of them require Google Cloud credentials (OAuth or a service account), which is the only installation toll.

Its limit is structural, not the MCP’s fault: Search Console only retains 16 months of history. If you want longer series, your agent has to store snapshots — the problem stops being about connectivity and becomes about storage.

The Google Analytics 4 MCP (official, still experimental) is its natural partner: GSC tells you how people arrive, GA4 what they do afterwards. Together they cover the full funnel without spending a cent.

Case 2: you need third-party data — keywords, SERPs, competitors

This is where the money decision lives, and the criterion is your usage pattern:

DataForSEO charges per query, no subscription: $1 of trial credit when you sign up and top-ups from $50. For agent workflows — bursts of one-off queries rather than continuous monitoring — it usually comes out far cheaper than a full subscription. The trade-off: there’s no UI; it’s a pure data layer, and the quality of the outcome depends entirely on how your agent asks.
Ahrefs splits its tools into 20 groups (Site Explorer, Keywords Explorer, Site Audit, Rank Tracker, Brand Radar…) over its link index, with a unit system per plan starting at Lite. There are so many that its own docs admit they exceed some MCP clients’ limits, which is why it accepts ?tools=essentials or a list of groups in the URL. The practical risk is new and very 2026: an agent in a loop can burn your monthly units in an afternoon. If you connect it, give it a per-session budget (Ahrefs lets you set a monthly unit cap per key).
Semrush plays the coverage card (28 billion+ keywords across 142 regional databases). Its MCP works in ChatGPT, Claude, Cursor, VS Code and Perplexity, and from its Projects API it only exposes the read methods.
SE Ranking has the largest surface (180+ tools) — so large that you should prune what you expose per session: agents struggle to choose among 180 options.

My practical read: for one-off automations and agents, DataForSEO; if you already pay for Ahrefs or Semrush for other reasons, their MCP is an obvious add-on, not a reason to subscribe.

Case 3: rank tracking and technical auditing

Nightwatch and Advanced Web Ranking are rank trackers with an MCP: historical positions, gainers/losers, multi-project comparisons. AWR requires an Agency plan, so it only makes sense for agencies.
Screaming Frog (from v24) ships an official MCP: your agent can orchestrate crawls — “crawl the site and tell me which pages have duplicate titles” — on top of the tool you already used. It runs locally, bound to your license and your machine: the MCP doesn’t work in the free version of the app.

Case 4: GEO — can AI engines read and cite you?

This is the new layer, and the one most often confused with classic SEO. The question is no longer “do I rank?” but “can GPTBot crawl me, does it understand my schema, and am I accidentally blocking the bot that would cite me?”. Two tools attack it from opposite angles:

Peec AI measures the outcome: which AI engines cite you, how much, and who you compete against inside each answer.
seo-geo-mcp — my server, open source — audits the cause: 17 read-only tools that check whether your page is crawlable and citable. It separates training blocks from citation blocks (blocking GPTBot prevents training; blocking OAI-SearchBot erases you from ChatGPT’s answers — many people did the second wanting the first), detects pages that only render client-side (Googlebot runs JavaScript; GPTBot, ClaudeBot and PerplexityBot generally don’t), and validates schema, hreflang, sitemaps and redirects. No API keys: everything resolves through public HTTP, DNS and robots.txt.

What seo-geo-mcp does not do, so you don’t connect it expecting something else: it has no keyword data, no backlinks, no rankings. It’s the auditor, not the database. The combination I run myself: GSC for performance, seo-geo-mcp for diagnosis — that pair covers 90% of the work on a site you own, for free.

The reason this layer is worth the effort has numbers behind it: the Princeton GEO study (KDD 2024) measured that optimizing content for generative engines — citations, statistics, sources — can raise visibility in their answers by up to 40%. How to apply it is covered in the GEO & AEO guide: showing up in ChatGPT.

Connecting one, in 60 seconds

With Claude Code, a remote MCP is one command away (each platform’s docs give you the exact URL):

claude mcp add --transport http ahrefs https://api.ahrefs.com/mcp/mcp

And a local one (like seo-geo-mcp), which Claude Code launches as a process and talks to over stdio. Since it’s published on npm, there’s nothing to clone:

claude mcp add seo-geo -- npx -y seo-geo-mcp-server

Two pieces of advice that prevent regret: connect only the servers you’ll use in that session — each one adds tools to the agent’s context, and too many options make it clumsy — and on paid ones, check consumption after your first sessions: an agent’s query pattern looks nothing like a human’s.

The honest summary

Your own site, zero budget: Search Console MCP + seo-geo-mcp. Both free; they cover performance and diagnosis.
Keyword and competitor research: DataForSEO if you pay per use; Ahrefs/Semrush if you already have the subscription.
Agency with reporting: SE Ranking or Nightwatch, which bundle rank tracking.
Deep technical audits: Screaming Frog v24+ with its local MCP.
Measuring AI citations: Peec AI, once you’ve done the homework in the layers above.

Frequently asked questions

What is an SEO MCP server?

It is a Model Context Protocol server that exposes SEO data or tools — rankings, keywords, backlinks, audits — to an AI agent like Claude or ChatGPT. Instead of copy-pasting reports, the agent queries the source directly: it asks Search Console for positions, launches a crawl in Screaming Frog or audits a page's robots.txt, and reasons over the result.

What is the best MCP server for SEO in 2026?

It depends on the data you need. For your own site's performance, the Google Search Console MCP (free, and the most accurate data available). For third-party data like keywords and SERPs, DataForSEO if you prefer paying per query, or Ahrefs/Semrush if you already hold their subscription. For GEO auditing — whether AI engines can read and cite your site — seo-geo-mcp, which is open source and requires no API keys.

Are there free SEO MCP servers?

Yes. The Google Search Console MCPs (all community-built: Google does not publish an official one) and the Google Analytics 4 MCP are free (they only need Google Cloud credentials), and seo-geo-mcp is open source and works without any API key because it resolves everything through public HTTP, DNS and robots.txt. Those three cover performance and diagnosis for a site you own at zero cost.

What is the difference between an SEO MCP and a GEO MCP?

The SEO one answers classic search questions: rankings, keywords, backlinks. The GEO one answers whether generative engines — ChatGPT, Perplexity, Gemini — can crawl, read and cite your page: whether robots.txt blocks the wrong bot, whether the page depends on JavaScript those crawlers do not execute, or whether the schema is well formed. They are complementary layers: you can rank well on Google and be invisible to AI assistants.

Can an AI agent spend a lot of money through a paid MCP?

Yes, and it is the newest practical risk in this category: an agent in a loop fires bursts of queries that look nothing like human usage, and on unit-based servers like Ahrefs it can consume the monthly quota in one long session. The defense is a per-session budget, connecting only the servers you need, and checking consumption after the first few sessions.

How Much Does a Website Cost in Mexico in 2026? (And When You Shouldn't Pay for One)

Marco Orta — Sat, 22 Aug 2026 00:00:00 GMT

A professional website in Mexico costs, in 2026, between $8,000 and $25,000 MXN (roughly $450–1,400 USD) for a landing page or informational site, between $25,000 and $80,000 MXN ($1,400–4,500 USD) for a custom corporate site, and from $50,000 MXN upward for e-commerce or a web application. On top of that comes what almost no quote itemizes: the domain ($200–800 MXN a year), hosting ($40–300 MXN a month) and maintenance ($1,500–4,000 MXN a month if you delegate it). And there’s a fourth range agencies won’t mention: $0 of development, because some businesses today are better served by a site builder or a Google Business profile than by paying for a site.

I build websites and web systems for a living — meaning I have every incentive to sell you one. That’s why this guide runs backwards from the agency playbook: first the market numbers with their sources, then what actually moves them, and at the end the cases where you should not hire me or anyone else.

If you just came for your number: my quote calculator gives you a range instantly — project type, complexity, features. No email required.

The market ranges in 2026

I crossed this year’s published price studies — Simplixy, GEDX and New Emage among others — with what I quote myself. They agree more than you’d expect:

Site type	2026 range (MXN)	What it typically includes
DIY (site builder)	$0 – $4,000 / year	Template, visual editor, hosting included
Landing page	$8,000 – $25,000	1 page focused on capturing leads or validating an idea
Informational / professional site	$14,000 – $30,000	5–8 pages, custom design, basic SEO
Custom corporate site	$25,000 – $80,000	Own design, optimized content, integrations
E-commerce	$27,000 – $126,000	Catalog, payments, shipping, invoicing
Web application	$36,000 – $250,000+	Custom business logic, users, dashboards

Two warnings about this table, because tables lie easily:

The range within each row is wider than the range between rows. A complex landing page can cost more than a simple corporate site. The site type is the starting point, not the price.
Freelancer vs agency moves the number as much as the project does. The same informational site goes from $5,000–25,000 MXN with a freelancer to $15,900 MXN and up with an agency. Neither is right or wrong: you’re paying for different things — with the agency, management and continuity; with the freelancer, direct contact and fewer layers.

What the quote usually doesn’t itemize

The development price is the big number, but it’s the only one you pay once. These are the ones you pay forever:

Domain: $200–800 MXN a year. It renews annually and must be registered in your name — if your provider registers it under theirs, the day you want to switch you’ll discover your domain isn’t yours. It’s the most expensive fine print in this industry.
Hosting: $40–300 MXN a month on basic plans; more as the site grows. Same rule: your own access, always.
Maintenance: $1,500–4,000 MXN a month if you contract it. Here there’s a real decision: a static informational site can live for years without maintenance; a WordPress with plugins cannot — without updates, getting hacked is a matter of time.
Invisible renewals: the SSL certificate (which should be free with Let’s Encrypt — be suspicious of anyone charging for it separately), plugin or template licenses, and corporate email.

The question I’d ask any quote: “which of this do I pay once and which do I pay monthly — and in whose name does each thing stay?”. The answer tells you more about the provider than their portfolio does.

The three things that actually make a project expensive

After quoting many projects, the factors that move the price are almost always the same three — and none of them is “the design”:

Functionality, not pages. Doubling the number of pages barely moves the price; adding online payments, a client area with login, CFDI invoicing or an integration with your internal system can double it. Each of those features is software that has to be built and tested.
Content and decision complexity. A project where the client brings copy, photos and a clear structure costs hours; one where everything gets decided in meetings costs weeks. You’re billed for time, and time goes into deciding.
Urgency. “I need it in two weeks” is a multiplier, not a detail. Compressing a project means shelving others, and that gets charged.

That’s why I distrust fixed catalog prices (“website: $9,999”) as much as quotes with no breakdown: both hide which row of the table you’ll land in after signing.

When you should NOT pay for a website

This section doesn’t appear in agency guides, for obvious reasons:

If your business lives within a five-block radius — a diner, a salon, a repair shop — your highest-return digital investment is a well-maintained Google Business profile (free) plus WhatsApp Business (free). A $15,000 MXN website won’t bring you more customers than that.
If you’re still validating the idea, a builder like Wix or a one-page template site ($0–4,000 MXN/year) is enough to test. Paying for custom development before knowing whether the business works is building the house before the foundation.
If you sell through marketplaces and it’s going well, your own site is diversification, not urgency. It comes eventually, but it doesn’t have to be today.

When is it worth it? When the site has a concrete job to do — capture leads, sell, automate something you currently do by hand — and you can put a number on that job. At that point the site stops being an image expense and becomes an investment with measurable return. I wrote about measuring it in the GEO & AEO guide: an $80,000 site that neither Google nor ChatGPT can read serves nobody.

How I quote (so you can compare against what you’re offered)

My quote calculator is public and needs no signup: you pick a project type (landing, corporate, e-commerce, web app, API, mobile app), a complexity level and concrete features, and it returns the range in pesos or dollars on the spot. For typical projects it goes from $3,600 MXN (a minimal landing) to the hundreds of thousands of a full application — the same orders of magnitude as the table above, because Mexico’s serious development market converges on those numbers.

What actually varies between providers — and where the real competition is — is the usual: a clear breakdown, whose name the domain and hosting stay under, and whether the person quoting will still be around in a year. Ask those three things before asking the price.

If you’d rather discuss the project directly, my web development service explains how I work.

Frequently asked questions

How much does a professional website cost in Mexico in 2026?

Market ranges in 2026: a landing page between $8,000 and $25,000 MXN (about $450–1,400 USD); a professional informational site of 5–8 pages between $14,000 and $30,000 MXN; a custom corporate site between $25,000 and $80,000 MXN; and e-commerce from around $27,000 MXN. Add the recurring costs: domain ($200–800 MXN/year), hosting ($40–300 MXN/month) and maintenance ($1,500–4,000 MXN/month if contracted).

Which is cheaper: a freelancer or an agency?

The freelancer almost always quotes lower: an informational site runs $5,000–25,000 MXN with a freelancer, while agencies start around $15,900 MXN for similar projects. But they charge for different things: the agency bills management, a team and continuity; the freelancer offers direct contact and fewer layers. The useful criterion is not the price but the breakdown, domain ownership, and who will maintain the site a year from now.

How much does it cost to maintain a website per month in Mexico?

The minimum recurring costs are hosting ($40–300 MXN a month on basic plans) and the domain ($200–800 MXN a year). Contracted maintenance — updates, security, minor changes — runs between $1,500 and $4,000 MXN monthly in the market. A well-built static site can live on the minimum; a WordPress with plugins needs active maintenance or ends up hacked.

When should you NOT pay for a website?

When the business is purely local with a short radius (a diner, a salon), where a free Google Business profile and WhatsApp Business yield more; when the business idea is not yet validated, where a $0–4,000 MXN/year site builder suffices; and when sales already work through marketplaces, making your own site diversification rather than urgency. A custom site pays off when it has a measurable job: capturing clients, selling, or automating.

What makes a website more expensive: design or features?

Features. Doubling the page count barely moves the price, but adding online payments, a client area, CFDI invoicing or integrations with internal systems can double it, because each feature is software that must be built and tested. The other two heaviest factors are how clear the client-provided content is, and deadline urgency.

Should the domain and hosting be in my name?

Always. If the provider registers the domain under their own name, the business does not own its own address on the internet, and switching providers becomes a negotiation. Before signing, confirm the domain stays in the client's name and that hosting credentials are handed over. It is the question that prevents the most problems in the whole engagement.

Marco Orta — Blog

Meta Banned General-Purpose AI Chatbots on WhatsApp: What It Means for Your Business (and What It Doesn't)

What the rule says, word for word

Who left WhatsApp (and who came back)

Why ChatGPT is back in Europe and Brazil

What your business can still do with AI on WhatsApp

What does change for you (and has nothing to do with the ban)

1. From October 1, service replies are billed

2. Meta now sells its own AI agent

3. The terms are being reorganized on September 23

Meta’s agent, or one connected to your business?

Five questions to ask your bot vendor

Frequently asked questions

Did Meta ban AI chatbots on WhatsApp?

Can my business use an AI chatbot on WhatsApp in 2026?

Why does ChatGPT work on WhatsApp in Europe but not in Mexico or the US?

Can my WhatsApp number be suspended for using AI?

How much does Meta's AI agent for businesses cost?

Are AI chatbot replies on WhatsApp billed?

Why Online Stores Crash During Mexico's Buen Fin (and How to Prevent It): The 2026 Technical Guide

What those five days look like

1. Shared hosting has a ceiling, and it’s in writing

2. Caching: what can be cached and what can’t

3. Your payment gateway has a limit too

4. The problem nobody mentions: cash at OXXO locks your inventory

5. Overselling: two people buy the last unit

6. What runs in the background

7. Test it first with fake traffic

If your store runs on Shopify or Tiendanube

The two-weeks-before checklist

Frequently asked questions

When is Buen Fin 2026?

Why do online stores crash during Buen Fin?

Does Cloudflare's free plan protect a store from Buen Fin traffic?

Does a pending OXXO payment lock my inventory?

How do I load test an online store?

Laravel Octane + FrankenPHP: What Actually Breaks (I Reproduced Every Leak)

The lab

Before it even starts: pcntl, zip and the musl binary

1. Singletons: the leak everyone describes isn’t the one that bites

2. Static state grows until the worker restarts

3. --max-requests=0 doesn’t mean “unlimited” on FrankenPHP

4. Config injected into a singleton goes stale, and can poison the worker

5. What FrankenPHP adds: threads, $_ENV and exit()

6. The Swoole-only features fail silently

7. Packages: mostly fine in 2026

Is it worth it? The numbers

The checklist before you switch

Frequently asked questions

Does a singleton that receives the request leak between requests in Laravel Octane?

What does --max-requests=0 do with Octane and FrankenPHP?

Which Octane features do not work with FrankenPHP?

Why does Laravel Octane fail with Undefined constant SIGINT on FrankenPHP?

Is $_ENV reset between requests in FrankenPHP worker mode?

How much faster is Laravel Octane with FrankenPHP?

OpenAI Shuts Down GPT-4, o1 and o3-mini on October 23: What Breaks in Your Code (It's Not Just the Model Name)

What shuts down, and what OpenAI says to use instead

What the failure looks like

1. The model you never wrote: library defaults

2. Tools on Chat Completions now need reasoning turned off

3. max_tokens: renamed, and now it has to pay for thinking

4. Fine-tuned models have no successor

5. o1-pro and gpt-image-1: different parameters, not new names

6. The bill

The audit: three greps and a real request

The rest of OpenAI’s calendar this year

Frequently asked questions

Which OpenAI models shut down on October 23, 2026?

What should I replace gpt-4 and gpt-3.5-turbo with?

What error does the OpenAI API return for a retired model?

Does LangChain still use gpt-3.5-turbo by default?

Why does gpt-5.6 fail with "Function tools with reasoning_effort are not supported"?

Is the gpt-5.6 migration more expensive?

What happens to my fine-tuned gpt-3.5-turbo model?

Chrome Removes XSLT: What Breaks in Sitemaps, Feeds and CFDI Invoice Tools

The dates

What breaks, what you see, how to fix it

Sitemaps and feeds: the decoration breaks, not the file

What about Google?

What to do with the sitemap

3. `--max-requests=0` doesn’t mean “unlimited” on FrankenPHP

5. What FrankenPHP adds: threads, `$_ENV` and `exit()`

3. `max_tokens`: renamed, and now it has to pay for thinking

5. `o1-pro` and `gpt-image-1`: different parameters, not new names

Dockge: if all you want is to edit `compose.yaml` files in a browser

`pricing.type`: the one that decides

`pricing.category`: which rate was applied