DEV Community: Marco Orta

Laravel 13: What Actually Breaks When You Upgrade (and What Doesn't)

Marco Orta — Mon, 21 Sep 2026 08:29:07 +0000

Laravel 12 stopped receiving bug fixes on August 13, 2026. Since then only security patches remain, and those run out on February 24, 2027. If you have a production app on 12, you are already in the last window.

The good news is that Laravel 13 really is a small upgrade. The official docs estimate 10 minutes and say most applications can upgrade "without changing much application code." That is true.

The bad news is the nuance almost nobody is covering: minimal breaking changes is not zero breaking changes. The official upgrade guide flags two high-impact changes, two medium-impact ones, and roughly fifteen low-impact ones. And if your application caches PHP objects, uses upsert on MySQL, or excludes the CSRF middleware in tests, one of them is going to bite.

This article is the complete list, with the concrete code for each change. If what you need is the general upgrade procedure — backup, branch, composer update, verification — that lives in the guide to upgrading Laravel to the latest version; here we go straight to what breaks.

First: where you are and how urgent this is

This is the official support table, not the one making the rounds:

Version	Supported PHP	Released	Bug fixes until	Security until
Laravel 13	8.3 – 8.5	Mar 17, 2026	Q3 2027	Mar 17, 2028
Laravel 12	8.2 – 8.5	Feb 24, 2025	Aug 13, 2026	Feb 24, 2027
Laravel 11	8.2 – 8.4	Mar 12, 2024	Sep 3, 2025	Mar 12, 2026 ❌
Laravel 10	8.1 – 8.3	Feb 14, 2023	Aug 6, 2024	Feb 4, 2025 ❌

Two things worth reading carefully in that table:

Laravel 11 has received no security patches since March 12, 2026. If you're there, you aren't "a little behind" — you're uncovered.
Laravel 12 is not LTS. Laravel stopped shipping LTS releases years ago; the current policy is uniform across every major — 18 months of bug fixes and 2 years of security.

flowchart TB
    A["Which version are you on?"] --> B["Laravel 12"]
    A --> C["Laravel 11"]
    A --> D["Laravel 10 or older"]
    B --> B1["✅ Jump straight to 13<br/>Read this list and do it"]
    C --> C1["⚠️ No security patches<br/>since Mar 12, 2026"]
    C1 --> C2["Go 11 → 12 → 13,<br/>one major at a time"]
    D --> D1["🚨 Fully end of life"]
    D1 --> C2

Entry requirement: PHP 8.3

Laravel 13 requires PHP 8.3 minimum and supports up to 8.5. No more, no less: if you read somewhere that "in practice it needs 8.4," that's wrong — 8.3 works.

php -v          # you need 8.3.0 or higher
composer -V     # and an up-to-date Composer 2.x

If you're coming from Laravel 12 on PHP 8.2, this is the only real infrastructure work in the upgrade. Do it before touching composer.json, not at the same time, so that if something breaks you know what broke it.

High impact

There are two. Both affect practically every application.

1. Dependencies in `composer.json`

No surprises, but there are more packages than people remember:

{
  "require": {
    "php": "^8.3",
    "laravel/framework": "^13.0",
    "laravel/tinker": "^3.0"
  },
  "require-dev": {
    "laravel/boost": "^2.0",
    "phpunit/phpunit": "^12.0",
    "pestphp/pest": "^4.0"
  }
}

The two most commonly forgotten are laravel/tinker to ^3.0 and the jump to PHPUnit ^12.0. If you use Pest, you need ^4.0.

And if you installed the global Laravel installer:

composer global update laravel/installer

With Herd, updating Herd is enough.

2. The CSRF middleware changes name and behavior

This is the significant change in the release, and the one most likely to quietly break your tests.

VerifyCsrfToken is renamed to PreventRequestForgery, and it isn't just a rename: it now performs origin verification by reading the browser's Sec-Fetch-Site header, on top of the usual token validation.

use Illuminate\Foundation\Http\Middleware\PreventRequestForgery;
use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken;

// Laravel <= 12.x
->withoutMiddleware([VerifyCsrfToken::class]);

// Laravel >= 13.x
->withoutMiddleware([PreventRequestForgery::class]);

VerifyCsrfToken and ValidateCsrfToken still exist as deprecated aliases, so your app won't explode on day one. But:

Referencing them directly stops being a good idea, especially when excluding middleware in tests or route definitions.
The middleware configuration API now exposes preventRequestForgery(...).

Where this really bites is test suites that call withoutMiddleware([VerifyCsrfToken::class]) expecting to disable the protection: because the alias points elsewhere, the exclusion may not apply the way you assumed. Grep for it before upgrading:

grep -rn "VerifyCsrfToken\|ValidateCsrfToken" app/ tests/ routes/ bootstrap/

Since you're hardening request forgery protection anyway, this is a good moment to check which security headers your domain is actually returning in production:

Free tool: HTTP Security Headers — Analyse a site's HTTP security headers (HSTS, CSP, X-Frame-Options and more) and get a grade plus the ones you are missing.

Medium impact

3. `serializable_classes` in the cache config

The default cache configuration now includes serializable_classes => false. It's a hardening measure against deserialization gadget chain attacks: if your APP_KEY leaks, without this protection an attacker could inject serialized PHP objects into the cache and chain magic methods until they achieve code execution.

The price is that if your application deliberately stores PHP objects in cache, it stops working unless you explicitly declare which classes may be unserialized:

// config/cache.php
'serializable_classes' => [
    App\Data\CachedDashboardStats::class,
    App\Support\CachedPricingSnapshot::class,
],

If you were caching arbitrary objects, you have two ways out: an explicit allow-list like the one above, or migrating to object-free payloads (plain arrays). The second is more work and the better idea.

Watch out for one detail: these errors don't show up at deploy time, they show up the first time someone reads a cache entry that contained an object. Which means in production, a while later. Flush the cache on deploy and cover it with a test.

4. `upsert` with MySQL or MariaDB

Laravel now validates that uniqueBy isn't empty, and throws InvalidArgumentException instead of generating invalid SQL:

// Laravel >= 13.x: this now blows up with InvalidArgumentException
DB::table('stats')->upsert($rows, [], ['views']);

The curious part is that the MySQL and MariaDB drivers ignore the value of uniqueBy — they always use the table's primary and unique indexes to detect existing records. The validation applies regardless. So if your code passed an empty array because "MySQL ignores it anyway," you now have to pass the real columns.

Low impact (the ones that will actually bite)

This is where the real value is, because nobody lists these and they're the ones that surface three weeks after the deploy.

5. Cache prefixes and session cookie name

The default prefixes move from underscore to hyphen:

// Laravel <= 12.x
Str::slug((string) env('APP_NAME', 'laravel'), '_').'_cache_';
Str::slug((string) env('APP_NAME', 'laravel'), '_').'_database_';
Str::slug((string) env('APP_NAME', 'laravel'), '_').'_session';

// Laravel >= 13.x
Str::slug((string) env('APP_NAME', 'laravel')).'-cache-';
Str::slug((string) env('APP_NAME', 'laravel')).'-database-';
Str::slug((string) env('APP_NAME', 'laravel')).'-session';

It only affects you if you don't have those values defined in your configuration and rely on the framework fallback. The symptom is ugly and confusing: the entire cache is invalidated at once and every active session is logged out the moment you deploy, because the keys and the cookie name changed.

To avoid it, pin the values explicitly before upgrading:

CACHE_PREFIX=myapp_cache_
REDIS_PREFIX=myapp_database_
SESSION_COOKIE=myapp_session

6. `JobAttempted` now exposes the exception

The event swaps a boolean property for the exception object:

// Laravel <= 12.x
$event->exceptionOccurred;   // bool

// Laravel >= 13.x
$event->exception;           // Throwable|null

It's a change for the better — now you know what failed, not just that it failed — but any listener reading exceptionOccurred stops working. And since it's a boolean read inside an if, the failure is silent: null is falsy, so your listener simply stops reacting.

7. `QueueBusy`: `$connection` becomes `$connectionName`

A pure rename, for consistency with the rest of the queue events. If you monitor queues with your own listener, update it.

grep -rn "QueueBusy" app/

8. `Container::call` respects nullable defaults

$container->call(function (?Carbon $date = null) {
    return $date;
});

// Laravel <= 12.x: a Carbon instance
// Laravel >= 13.x: null

It now matches the constructor injection behavior introduced in Laravel 12. If you had code relying on the container resolving the class despite the = null, the result changes without warning.

9. Domain route precedence

Routes with an explicit domain are now evaluated before routes without one. This fixes the catch-all subdomain case, which previously depended on registration order.

If you do multi-tenancy by subdomain, or you declare domain routes after general ones, review your matching. It's one of the few changes on this list that can alter which controller handles a request.

10. `DELETE` with `JOIN`, `ORDER BY`, and `LIMIT` on MySQL

Previously, in a delete with a join, the ORDER BY and LIMIT clauses were silently ignored. Now they're compiled and sent to the database.

In practice: code you believed was bounded (->limit(100)) but was actually deleting without a limit can now throw QueryException, because MySQL and MariaDB don't support that syntax in joined deletes.

It's an awkward change but a healthy one — it was lying to you. If you run into it, inspect the generated SQL before touching anything:

Free tool: SQL Formatter / Beautifier — Format and beautify your SQL code with ease.

11. Polymorphic pivot table names

When inferring the table name for a polymorphic pivot model with a custom class, Laravel now pluralizes. If you relied on the singular inferred name, declare the table explicitly on the pivot:

class Taggable extends MorphPivot
{
    protected $table = 'taggable';   // this used to be inferred
}

12. Collection serialization restores eager-loaded relations

When a model collection is serialized and restored — the usual case in queued jobs — relations loaded with with() are now present again after deserialization.

That's usually what you want. But if your job counted on the relations not being there (to force a fresh reload from the database, say), it now works with potentially stale data. That bug is especially treacherous because nothing fails: it just processes old data.

13. `Str` factories reset between tests

Laravel now clears custom Str factories during test teardown. If you defined a deterministic UUID or ULID generator once — in a setUpBeforeClass or a global helper — and expected it to persist across methods, you now have to define it in each test or in setUp.

Symptom: tests that pass in isolation and fail in the suite.

14. `extend` callbacks are bound to the manager

Custom driver closures registered via extend now have the manager as $this, not whatever was there before. If you used $this inside the closure expecting the service provider, move it into a capture:

// Before: $this was the service provider
Cache::extend('mydriver', function ($app) {
    return $this->createStore($app);      // no longer works
});

// Now
$provider = $this;
Cache::extend('mydriver', function ($app) use ($provider) {
    return $provider->createStore($app);
});

15. Bootstrap 3 pagination view names

// Laravel <= 12.x
pagination::default
pagination::simple-default

// Laravel >= 13.x
pagination::bootstrap-3
pagination::simple-bootstrap-3

Only relevant if you reference those view names directly. The old names were confusing — default wasn't the actual default — and now they're explicit.

16. `Js::from` stops escaping Unicode

It now uses JSON_UNESCAPED_UNICODE by default. If you have tests or output comparisons expecting è instead of è, update the expectations. Any accented character triggers this.

17. The PHP 8.5 polyfill and global helpers

This is the easiest one to miss. Laravel 13 adds a dependency on symfony/polyfill-php85, which on PHP below 8.5 defines global functions such as array_first() and array_last() if they don't already exist.

The conflict: the historical array_first() from laravel/helpers accepted a callback to return the first element matching a condition. The polyfilled one only returns the array's first element. Same apparent signature, different behavior.

If you still carry laravel/helpers or your own global helpers with those names, always use Arr:

use Illuminate\Support\Arr;

Arr::first($array, fn ($value) => $value->active);

Very low impact: only if you maintain packages

If you implement framework contracts yourself, there are new methods to add. If you only consume Laravel, skip this section entirely.

Contract	Method to add
`Illuminate\Contracts\Cache\Store`	`touch($key, $seconds)`
`Illuminate\Contracts\Bus\Dispatcher`	`dispatchAfterResponse($command, $handler = null)`
`Illuminate\Contracts\Routing\ResponseFactory`	`eventStream(...)`
`Illuminate\Contracts\Auth\MustVerifyEmail`	`markEmailAsUnverified()`
`Illuminate\Contracts\Queue\Queue`	`pendingSize`, `delayedSize`, `reservedSize`, `creationTimeOfOldestPendingJob`

On top of that, instantiating a model while that model is still booting now throws LogicException:

protected static function boot()
{
    parent::boot();

    (new static())->getTable();   // LogicException on Laravel 13
}

And the HTTP client's throw and throwIf signatures now declare their callbacks explicitly, which only matters if you override those methods in a custom response class.

What does NOT break, whatever you may have read

A couple of false claims are circulating about this upgrade:

app/Http/Kernel.php does not disappear in Laravel 13. That file was removed in Laravel 11, with the new application structure. If you're coming from 12 you no longer have it.
Laravel 13 does not require PHP 8.4. The minimum is 8.3 and the supported range goes up to 8.5.
VerifyCsrfToken is not removed. It remains a deprecated alias. Migrating it is wise, but it won't take your deploy down.
There are no "zero breaking changes." The documentation itself says minimal, and flags two high-impact changes. The gap between "minimal" and "zero" is exactly this article.

The upgrade, in practice

With the full list in front of you, the procedure is short:

# 1. New branch, always
git checkout -b upgrade/laravel-13

# 2. PHP 8.3+ before anything else
php -v

# 3. Pin cache and session prefixes so you don't invalidate everything
#    (CACHE_PREFIX, REDIS_PREFIX, SESSION_COOKIE in your .env)

# 4. Grep for what you know changes
grep -rn "VerifyCsrfToken\|ValidateCsrfToken" app/ tests/ routes/ bootstrap/
grep -rn "exceptionOccurred\|QueueBusy" app/
grep -rn "array_first\|array_last" app/

# 5. Update dependencies
composer update --with-all-dependencies

# 6. Clear everything
php artisan optimize:clear

# 7. Tests
php artisan test

Laravel also offers an assisted route: if you have Laravel Boost ^2.0 installed, the /upgrade-laravel-v13 command walks the upgrade from Claude Code, Cursor, OpenCode, Gemini, or VS Code. And for large projects, Shift is still the paid option that automates the bulk of it.

One last step almost nobody takes, and it saves surprises: diff your configuration files against laravel/laravel on the 13.x branch. Many changes on this list — serializable_classes being the obvious one — live in config/, not in the framework, and don't arrive on their own with composer update.

One catch when you copy, though: the 13 skeleton's config/session.php ships 'serialization' => 'json'. If your app was on php and you sync that value as-is, every active session is invalidated on deploy and every user has to log in again. For a seamless upgrade, keep it at php. Moving to json is the recommended hardening against deserialization attacks, but only if you don't store PHP objects in the session, and only when you're fine forcing that re-login.

Free tool: Text Diff Checker — Compare two texts and highlight the differences line by line, with unified and side-by-side views and ignore case or whitespace. All in your browser.

Checklist before you merge

[ ] PHP 8.3 or higher on local, CI, and production
[ ] laravel/framework ^13.0, laravel/tinker ^3.0, phpunit ^12.0 or pest ^4.0
[ ] Zero references to VerifyCsrfToken in tests and routes
[ ] CACHE_PREFIX, REDIS_PREFIX, and SESSION_COOKIE pinned explicitly
[ ] config/cache.php reviewed if you cache PHP objects
[ ] Every upsert() call passes a non-empty uniqueBy
[ ] JobAttempted and QueueBusy listeners updated
[ ] Domain routes reviewed if you use subdomains
[ ] Test suite green as a whole, not just file by file
[ ] Cache flushed on deploy

Conclusion

Laravel 13 is an honest upgrade: 10 minutes for most apps, and the new capabilities — the first-party AI SDK, JSON:API resources, Queue::route(), PHP attributes for middleware and jobs, Cache::touch(), vector search with whereVectorSimilarTo() — arrive without demanding a rewrite in exchange.

But "minimal" is not "zero," and the changes that actually hurt aren't the two high-impact ones — those are documented and surface immediately — but the low-impact ones that fail silently: the cache that invalidates wholesale, the listener that stops reacting, the job that processes stale data, the test that only fails in the suite.

That date has passed: August 13, 2026. Since then, every bug you find in Laravel 12 is yours.

Frequently asked questions

When does Laravel 12 support end?

Laravel 12 stopped receiving bug fixes on August 13, 2026 and stops receiving security patches on February 24, 2027. Laravel applies the same policy to every major version: 18 months of bug fixes and 2 years of security. Laravel 12 is not an LTS release.

Which PHP version does Laravel 13 require?

Laravel 13 requires PHP 8.3 as a minimum and supports up to PHP 8.5. It is not true that it requires PHP 8.4: it works correctly on 8.3. If you are coming from Laravel 12 on PHP 8.2, raising the PHP version is the only real infrastructure work in the upgrade.

What are the high-impact breaking changes in Laravel 13?

There are two. The first is updating dependencies in composer.json: laravel/framework to ^13.0, laravel/tinker to ^3.0, laravel/boost to ^2.0, phpunit/phpunit to ^12.0, and pestphp/pest to ^4.0. The second is that the CSRF middleware VerifyCsrfToken is renamed to PreventRequestForgery and adds origin verification through the Sec-Fetch-Site header. VerifyCsrfToken still exists as a deprecated alias.

Is app/Http/Kernel.php removed in Laravel 13?

No. That file was removed in Laravel 11 with the new application structure, not in Laravel 13. If you are coming from Laravel 12 your project no longer has it and there is nothing to do about it.

Why did my entire cache disappear after upgrading to Laravel 13?

Because the default cache, Redis, and session prefixes changed from underscore to hyphen: from myapp_cache_ to myapp-cache-. It only affects applications that rely on the framework fallback instead of defining those values in their configuration. The effect is that every cache key changes and active sessions are logged out. To avoid it, pin CACHE_PREFIX, REDIS_PREFIX, and SESSION_COOKIE in your .env before upgrading.

How long does upgrading from Laravel 12 to Laravel 13 take?

The official documentation estimates 10 minutes for a typical application. In practice, the time goes into raising PHP to 8.3 if you were on 8.2, reviewing third-party packages that do not yet declare Laravel 13 compatibility, and checking the low-impact changes that fail silently. With Laravel Boost 2.0 installed you can use the /upgrade-laravel-v13 command to have an AI assistant guide the process.

Originally published on ortamarco.me.

The AI model your business runs on is being retired: the 2026 shutdown calendar

Marco Orta — Mon, 21 Sep 2026 08:20:03 +0000

OpenAI already shut down the Assistants API on 26 August 2026. The next cutoffs are 24 September, when it retires the Videos API and sora-2; 28 September, for the last legacy completion snapshots; and 23 October, for gpt-3.5-turbo and gpt-4. If your business runs a chatbot, an email classifier or any AI automation that was built for you in 2023 or 2024, there is a very high chance it is wired to one of those last two models. And on shutdown day it will not degrade gracefully: it will return an error and stop working.

This is not speculation or industry chatter. These are dates published by the providers themselves on their own deprecation pages, with six months' notice. The problem is that the notice arrives by email to the developer account that created the API key — which half the time belongs to an agency that no longer works with you.

This article is the full calendar, how to find out in three minutes whether it affects you, and what to do if it does. If what you need is what each model costs, that lives in the guide to OpenAI, Claude and Gemini API pricing; here we go straight to what shuts down and when.

What nobody told you when you bought it

AI models are not software you buy once. They are a service with an expiry date, and the provider decides the date.

OpenAI puts it plainly in its documentation: "software relying on OpenAI models may need occasional updates to keep working." Anthropic writes almost the same sentence. Translated into the language of the person paying the invoice: the chatbot you were handed as "finished" carries mandatory maintenance, and nobody put it in the quote.

This changes a decision plenty of businesses got wrong. When you asked for a quote to automate something with AI, you compared the implementation price and the monthly token cost. What you did not compare — because nobody showed you — was how often you would be paying for a migration. And on that, as we will see, providers are nothing alike.

First: does this affect you? The three-minute check

Before reading the calendar, find out which model you actually use. Not what you think you use: what is written in the code.

If you have access to the OpenAI dashboard

Sign in to platform.openai.com with the account that pays for the API.
Go to Usage and switch the breakdown to group by model.
Look at the last 30 days. Those names are what you are really running.

If you have access to the Anthropic console

Open the Usage page in the Claude Console.
Click Export.
The CSV gives you usage broken down by API key and by model. Anthropic documents this exact procedure for auditing deprecated models.

If you have access to nothing

This is the most common case, and it is the finding in itself. If nobody at your company can log into the provider's dashboard:

The API key belongs to a third party. The retirement notice goes to them, not to you.
You cannot audit the spend, so you also do not know whether you are overpaying.
You cannot migrate without them, which means the continuity of a business process depends on that person picking up the phone.

All three are governance problems, not technical ones, and they are fixed the same way: the AI provider account is opened in the company's name, paid by the company, and the external developer is added as an invited user. If this is your situation, that is the first job — before any migration.

Free tool: LLM Token Counter & AI Cost Calculator — Count the tokens in your text or prompt and estimate the cost across GPT-5, Claude, Gemini, Kimi K3, Grok and DeepSeek. Exact OpenAI counting, per-call and monthly costs, with prompt caching.

OpenAI's shutdown calendar

These are the dates published on OpenAI's official deprecations page, checked on 16 August 2026 and reconfirmed on 13 September 2026. I have bolded the ones that hit small businesses hardest.

Shutdown	What dies	Recommended replacement
26 Aug 2026 (already happened)	Assistants API	Responses API + Conversations API
24 Sep 2026	`sora-2`, `sora-2-pro`, Videos API	no replacement
28 Sep 2026	`gpt-3.5-turbo-instruct`, `babbage-002`, `davinci-002`, `gpt-3.5-turbo-1106`	`gpt-5.6-terra`
1 Oct 2026	`gpt-5.4-cyber`	`gpt-5.6-cyber`
23 Oct 2026	`gpt-3.5-turbo-0125`, `gpt-4-0613`, `gpt-4-turbo`, `gpt-4-1106-preview`, `gpt-4o-2024-05-13`, `o1`, `o1-pro`, `o3-mini`, `o4-mini`, `gpt-4.1-nano`, `gpt-image-1`	`gpt-5.6-sol` / `gpt-5.6-terra` / `gpt-5.6-luna` (`gpt-image-1` → `gpt-image-2`)
31 Oct 2026	Evals: existing evals become read-only	Promptfoo (OpenAI's migration path)
30 Nov 2026	`v1/prompts` API and reusable prompts, Agent Builder, Evals dashboard and API	Prompts in your own code · Agents SDK or ChatGPT Workspace Agents · Promptfoo
1 Dec 2026	`gpt-image-1-mini`, `gpt-image-1.5`, `chatgpt-image-latest`	`gpt-image-2`
11 Dec 2026	`gpt-5-2025-08-07`, `gpt-5-mini-2025-08-07`, `gpt-5-nano-2025-08-07`, `gpt-5-pro-2025-10-06`, `o3-2025-04-16`, `o3-pro-2025-06-10`	`gpt-5.6-sol` (`reasoning.mode: pro` for the pro ones) / `gpt-5.6-terra` (mini) / `gpt-5.6-luna` (nano)
20 Jan 2027	`gpt-realtime`, `gpt-audio`, `gpt-4o-audio`, `gpt-4o-realtime` and mini variants	`gpt-realtime-2.1` (`gpt-realtime-2.1-mini` for the realtime minis) / `gpt-audio-1.5`
26 Feb 2027	`whisper-1`, `gpt-4o-transcribe`, `gpt-4o-mini-transcribe`, `gpt-4o-transcribe-diarize`	`gpt-transcribe` / `gpt-live-transcribe`

Two of those dates are closer than the headline one, and easy to miss because they read like small print next to it. 24 September retires the Videos API along with sora-2 and sora-2-pro — with no replacement listed, so anything built on video generation needs a different plan, not just a different model string. 28 September retires the last of the old completion-style snapshots (gpt-3.5-turbo-instruct, babbage-002, davinci-002, gpt-3.5-turbo-1106) into gpt-5.6-terra. Neither is wired into as many small-business chatbots as gpt-3.5-turbo or gpt-4 are — but if your stack touches either one, your date is 24 or 28 September, not 23 October.

And a third one shows that six months' notice does not apply to everything: gpt-5.4-cyber was announced on 11 September and shuts down on 1 October, twenty days later. The six-month minimum OpenAI promises covers generally available models, not its whole catalogue, so do not assume it for variants like this one.

Three readings of that table matter more than the table itself:

1. 23 October is the big one. gpt-3.5-turbo and gpt-4-0613 are the models that appear literally in every tutorial from 2023 and 2024. Any integration copied from a blog, a course or the documentation of that era has them hardcoded. And because they worked without complaining for three years, nobody has touched them since. (For what actually changed in the replacements, see the GPT-5.6 launch rundown.) ⚠️ And if the GPT-6 Astra launch on 3 September tempts you to migrate straight there: for a chatbot or a classifier that is an expensive mistake. Astra costs 20x the input and 33x the output of gpt-3.5-turbo, and its million-token window hides a 2x surcharge past 272K. The migration ladder by workload type is in GPT-6 Astra for developers. And if you're the one migrating the code: changing the name isn't enough, because LangChain and LlamaIndex still default to gpt-3.5-turbo and the substitutes reject tools on Chat Completions unless you turn reasoning off. The details, with audit greps, are in what breaks in your code on October 23.

2. Whole APIs are shutting down, not just models. The Assistants API, Agent Builder, the Evals platform and reusable prompts all disappear. That is not fixed by changing a string: it is rewriting the integration. Anyone who built on Assistants is looking at days of work, not minutes.

Reusable prompts are the sneakiest case, because the prompt text is not in your repository: it is stored in the OpenAI dashboard, and your code only references it with prompt: { id: "pmpt_…" } in the Responses API call. On 30 November the v1/prompts API and those prompt objects shut down, so the official migration guide asks you to take the content out of the dashboard, move it into your code and send it as input. Evals also has an intermediate step: from 31 October your existing evals become read-only, a month before the dashboard and API disappear.

3. Pinned snapshots die even when the model "lives on". Look at gpt-5-2025-08-07. GPT-5 is not disappearing as a family, but that specific snapshot is. If your code pins the date — which is the good practice for reproducible results — then you are on the shutdown calendar even while running a model that feels current.

Anthropic's calendar works differently

Anthropic publishes the same thing on its model deprecations page, but with one difference that changes how you plan.

Model	Status	Retirement
`claude-opus-4-1-20250805`	Retired	5 Aug 2026
`claude-opus-4-20250514`, `claude-sonnet-4-20250514`	Retired	15 Jun 2026
`claude-3-7-sonnet-20250219`, `claude-3-5-haiku-20241022`	Retired	19 Feb 2026
`claude-3-haiku-20240307`	Retired	20 Apr 2026
`claude-sonnet-4-5-20250929`	Active	not sooner than 29 Sep 2026
`claude-haiku-4-5-20251001`	Active	not sooner than 15 Oct 2026
`claude-opus-4-5-20251101`	Active	not sooner than 24 Nov 2026
`claude-opus-5`, `claude-sonnet-5`, `claude-fable-5`	Active	2027

Careful not to read those "not sooner than" entries as shutdown dates: they are floors, not announcements. As of 13 September 2026 none of the three Claude 4.5 models has an announced deprecation, and with the 60 days' notice Anthropic commits to, none of them can be retired before 12 November.

The difference is in the notice period, and it is a big one:

Provider	Committed advance notice
OpenAI	6 months for generally available models · 3 months for specialised variants · 2 weeks for preview models
Anthropic	60 days for publicly released models
Google (Gemini)	Its deprecations page sets no notice period: it tracks "the announced earliest shutdown dates"

Sixty days is not much. claude-opus-4-1 was announced on 5 June and switched off on 5 August: two months exactly. If your business slows down in August, or your developer is on holiday, or nobody simply reads that email, the entire notice window passes you by.

This does not make Anthropic a bad choice — its models are excellent, and the retirement pace is the flip side of a very high release pace. It means the notice period is a product feature you should compare before choosing, the same as price or latency. And it appears in none of the comparison posts doing the rounds.

Gemini: two shutdowns between September and October

Google publishes its own on the Gemini API deprecations page, checked on 13 September 2026. Between September and December 2026 there are two dates, plus one that has already passed and is worth checking if your integration dates from 2025:

Shutdown	What dies	Recommended replacement
1 Jun 2026 (already happened)	`gemini-2.0-flash`, `gemini-2.0-flash-001`, `gemini-2.0-flash-lite`, `gemini-2.0-flash-lite-001`	`gemini-3.6-flash` / `gemini-3.1-flash-lite`
30 Sep 2026	`gemini-omni-flash-preview`	`gemini-omni-1.1-flash`
2 Oct 2026	`gemini-2.5-flash-image`	`gemini-3.1-flash-image`

Two details in that table. gemini-omni-flash-preview, the video generation model, launched on 30 June and shuts down three months later: the textbook example of why you do not build a business process on a preview. And for gemini-2.5-flash-image — the original Nano Banana — the official page lists gemini-3.1-flash-image-preview as the replacement, but that preview was already shut down on 25 June 2026 and the same page gives the stable version, gemini-3.1-flash-image (Nano Banana 2), as its replacement, which is where it makes sense to migrate directly.

Gemini 2.5's text models (gemini-2.5-pro, gemini-2.5-flash, gemini-2.5-flash-lite) still have no announced shutdown date.

The trap that catches the most people: where you run it changes the date

This is the detail nobody has written up properly, and the one that produces the most expensive surprises.

The dates above are the original provider's. If you consume the same model through somebody else's cloud, the dates are different.

Anthropic says so explicitly: its dates apply to the Claude API, the Claude Platform on AWS and Microsoft Foundry. Amazon Bedrock and Google Cloud Vertex AI set their own retirement schedules, so the same model's status and dates can differ.
The same is true of OpenAI: Azure OpenAI publishes its own retirements table, which is not always in sync with OpenAI direct.

flowchart TB
    A["Same model,<br/>three different dates"] --> B["Provider's direct API"]
    A --> C["Azure OpenAI / Microsoft Foundry"]
    A --> D["Amazon Bedrock / Google Vertex"]
    B --> B1["Date on the official<br/>deprecations page"]
    C --> C1["Microsoft's own schedule"]
    D --> D1["Cloud operator's<br/>own schedule"]
    B1 --> E["⚠️ Check the table for<br/>WHERE YOU RUN IT,<br/>not the model maker's"]
    C1 --> E
    D1 --> E

The practical consequence: if your integration goes through Bedrock or Azure, the table you need is not the one I just published. It is your cloud's. Setting the alarm for the wrong date is as bad as not setting one.

What else breaks, and it isn't a model

Beyond the shutdowns, there are silent retirements that break code without any model dying.

The live example right now: Anthropic deprecated the temperature, top_p and top_k parameters as of Claude Opus 4.7. It does not ignore them — it returns a 400 error if you send them with anything other than the default value. Any integration that tuned the model's "creativity" with temperature: 0.7 — which is practically every integration from 2023–2024 — stops working the moment you move to a current model.

This matters because it dismantles the naive plan. Plenty of people assume migrating means swapping "gpt-4" for "gpt-5.6-sol" and done. Sometimes it is. But you may also be facing:

Parameters that are no longer accepted (the case above).
Different response formats, if you used structured output.
Entire APIs rewritten (Assistants → Responses).
Prompts that stop performing the same. A new model is not the old one but better: it is a different one. Prompts tuned by trial and error against gpt-4 can do worse on gpt-5.6-sol until they are readjusted.

That last point eats the most budget and is the one that never gets quoted.

The migration procedure

If you have a technical team, this is the order that works. If you do not, skip to the next section.

1. Inventory before touching anything

Search the whole codebase for model strings, not just the obvious file:

# OpenAI models hardcoded in the code
grep -rn "gpt-3.5-turbo\|gpt-4-0613\|gpt-4-turbo\|gpt-4o-2024" \
  --include="*.php" --include="*.js" --include="*.ts" --include="*.py" .

# Prompts stored in the OpenAI dashboard (v1/prompts shuts down 30 Nov 2026)
grep -rn "pmpt_\|prompt_id" .

# Anthropic models
grep -rn "claude-3\|claude-sonnet-4-2025\|claude-opus-4-2025" .

# And what nearly everyone forgets: environment variables and config
grep -rn "MODEL" .env .env.example config/ 2>/dev/null

Also check the places where the model name is not in the repository at all: n8n or Make panels, serverless functions, cron jobs, and any third-party automation consuming your key.

This kind of break stays invisible until the exact day for a specific reason: a hardcoded model ID needs no validation to keep working. It succeeds every single time you call it, for as long as the model is alive, then fails on the very next call after retirement. There is no warning header on the 200 responses the week before, no gradual dip in quality to notice — the API goes straight from working to a 400 or 404 the moment the shutdown date arrives. If nothing in your code specifically catches that error, the person using your product just sees something break, with nothing in the interface pointing at the real cause.

That is also why it is worth pulling your API logs now, not only grepping your code. A spike in 400 or 404 responses from api.openai.com or api.anthropic.com around a retirement date is the model dying in production — and it is usually a customer who reports it first, not a dashboard.

2. Pin the version, don't use the alias

If your code says plain "gpt-4", you are using an alias the provider repoints whenever it likes. That looks convenient and is exactly the opposite: it means your system's behaviour can change on a Tuesday without you touching anything.

The correct practice is to pin the dated snapshot and control yourself when you move up. Yes, that puts you on the shutdown calendar — but it puts you there predictably, which is precisely what you want.

3. Compare side by side before switching

Do not swap the model in production and wait to see what happens. Take 30 or 50 real cases from your history, run them through the old model and the new one, and compare outputs side by side. It is an afternoon's work and it is the difference between a migration and an incident.

Free tool: Text Diff Checker — Compare two texts and highlight the differences line by line, with unified and side-by-side views and ignore case or whitespace. All in your browser.

4. Put the provider behind your own layer

This is the work that makes the next shutdown boring. Instead of calling the provider's SDK from twenty places, call it from one:

// A single place where the decision of which model to use lives.
// The rest of the application asks for "reasoning" or "classification",
// not for "gpt-5.6-sol".

const MODELS = {
  reasoning:      { provider: 'openai',    model: 'gpt-5.6-sol' },
  classification: { provider: 'openai',    model: 'gpt-5.6-terra' },
  summarisation:  { provider: 'anthropic', model: 'claude-sonnet-5' },
} as const;

export async function complete(task: keyof typeof MODELS, prompt: string) {
  const { provider, model } = MODELS[task];
  return provider === 'openai'
    ? callOpenAI(model, prompt)
    : callAnthropic(model, prompt);
}

With that in place, the next shutdown is editing one line of an object and re-running step 3's comparison. Without it, it is find-and-replace across twenty files and hoping.

You do not need a framework for this. LangChain or LlamaIndex solve the same problem and bring far more baggage than a small business needs; thirty lines of your own usually do the job without adding a dependency that can also be deprecated.

If you have no technical team: what to demand, and from whom

For the owner or operations lead who will not be touching code, the job is different — and more important.

What to ask, in writing, from whoever maintains your integration:

Which exact model each process uses, with the full name and snapshot date. "We use ChatGPT" is not an answer.
Which platform it runs on — direct API, Azure, Bedrock, Vertex — because the real date depends on it.
The shutdown date for each one, taken from that platform's table.
Who receives the deprecation emails. If it is an account you do not control, change that this week.
What the migration costs and who pays for it. This is the uncomfortable question, and it needs asking now, not in October.

And what belongs in the contract from here on: deprecation maintenance is not an enhancement or a nice-to-have — it is what keeps the system switched on. Either it is covered by a retainer, or it is priced up front. Discovering it on shutdown day, with the process already down, is the worst negotiating position available.

I say this from the uncomfortable side of the table: I make a living building these integrations. And even so, a client who does not understand that this carries maintenance is a client who will feel ripped off a year from now — rightly.

What the switch costs (and why you sometimes come out ahead)

Migrating is not always a net expense. Newer models tend to be considerably cheaper per token than the ones they replace, and considerably more capable, so three effects offset each other:

In your favour: the replacement's price per million tokens is usually lower. A process that cost X on gpt-4 can cost a fraction on its successor.
In your favour: more capable models need shorter prompts for the same quality, and a shorter prompt is fewer tokens.
Against you: reasoning models burn internal tokens that you also pay for. Switching to one of those by accident can multiply the bill even as the unit price drops.

The only honest way to know is to measure it with your real data before switching. The numbers and the method are in the OpenAI, Claude and Gemini API pricing guide, and if you want to estimate a specific prompt's consumption before sending it, the token counter alongside does it with no signup.

Free tool: Tokenizer Visualizer — Paste text and see exactly which tokens a language model splits it into, with their IDs. Check why Spanish costs more tokens than English.

The radical way out: make it un-switchoffable

There is one way to make this article never apply to you: run the model yourself.

An open model running on your own hardware cannot be retired by anyone. It keeps working exactly the same three years from now, with the same outputs, no deprecation emails and no date on the calendar. For stable internal processes — classifying email, extracting data from documents, summarising — it is a real option, and today it runs on affordable hardware.

It is not free: you pay in hardware, in electricity, and in quality that trails the frontier models. I wrote the full analysis, with the machine I use and measured numbers, in AI without sending data outside: a local LLM for small firms. The continuity section of that article is exactly this problem seen from the other side.

For most people the sensible call is not picking a side but splitting: provider models for what needs frontier quality, your own model for the stable processes you would rather not tie to anybody's calendar.

Frequently asked questions

What exactly happens on shutdown day?

The request fails. There is no degradation and no automatic substitution: the model stops being reachable and the API returns an error. Anthropic says it literally — "requests to retired models will fail" — and OpenAI that the model or endpoint "will no longer be accessible." If your application does not handle that error, what the end user sees is a broken screen.

I use ChatGPT in the browser, not the API. Does this affect me?

Far less. The dates in this article are for the API, which is what integrations consume. In the ChatGPT app, retired models are swapped for the current one automatically and at most you notice it answers differently. The serious risk is to anything automated.

How do I know if my chatbot uses the Assistants API?

Ask whoever built it, and if you cannot, check the OpenAI dashboard: if assistants appear under Assistants, it is in use. The code gives it away too — it will call endpoints under /v1/assistants or /v1/threads. If you have not migrated yet, that one is no longer a countdown: the Assistants API already shut down on 26 August 2026, so a chatbot still calling it is already broken, not about to be.

Is migrating just changing the model name?

Sometimes yes, sometimes no. Swapping the string is enough if you only used plain text generation. But you may need to rewrite if you used the Assistants API, if you send already-deprecated parameters — temperature returns a 400 error on current Claude models — or if your prompts were tuned against the old model. Budget for the output comparison, which is the part that actually takes time.

How often will this happen again?

Permanently. OpenAI gives at least 6 months' notice for generally available models; Anthropic, 60 days. At that pace, the realistic plan is a model review every six months and a small migration once a year. It is recurring maintenance, like upgrading the framework or renewing an SSL certificate.

Does using LangChain or a chatbot SaaS protect me?

Partly, with caveats. An abstraction layer makes the switch cheaper, but it does not stop the underlying model dying or remove the need to revalidate quality. And if the middleman is a SaaS, you inherit its calendar and the risk that it deprecates features of its own — which is exactly what OpenAI did with Agent Builder, its own product, retiring on 30 November 2026.

Conclusion: put it in the calendar today

Boiled down to what to do this week:

Find out which model you actually use. OpenAI dashboard grouped by model, or the CSV export from the Claude console. Three minutes.
Check which platform it runs on, because that is what determines the real date.
Set an alarm for every date that applies to you: 24 September 2026 if you use Sora or the Videos API; 28 September if you still call old completion-style models; 30 September or 2 October if you generate video or images with Gemini (gemini-omni-flash-preview, gemini-2.5-flash-image); 23 October if any gpt-3.5-turbo or gpt-4 shows up in your inventory; 31 October and 30 November if you use Evals, Agent Builder or prompts stored in the dashboard; 1 December if you generate images with gpt-image-1.5 or gpt-image-1-mini; and 11 December if you pin gpt-5 or o3 snapshots. (If you were still calling the Assistants API, that alarm already went off on 26 August — check today whether it is broken.)
If your code calls the Responses API with prompt: { id: "pmpt_…" }, copy that prompt into your repository. The text lives in the OpenAI dashboard, not in your code, and on 30 November 2026 the v1/prompts API and reusable prompts shut down. The official guide says to move the content into your code and send it as input. If the account belongs to your agency, ask them for it now, not on 30 November.
Verify who receives the deprecation emails. If it is not somebody at your company, fix that before anything else.
And ask what the migration costs, while there is still room to negotiate it calmly.

Model shutdowns are not an exotic technical problem: they are ordinary maintenance for a technology moving fast. What is a problem is finding out about them on the day the chatbot stops answering.

If you have an AI integration in production and cannot answer question 1 on that list, get in touch and we will review it. Auditing which models you run and when they die is a short job, and it is better done weeks before the shutdown than the day after.

Originally published on ortamarco.me.

Node 26: What Breaks When You Upgrade, and When the Jump Is Worth It (LTS Guide)

Marco Orta — Mon, 21 Sep 2026 08:19:46 +0000

Node 26 shipped on May 5, 2026 and enters LTS on October 28. It's a calm upgrade — the list of things that actually break is short, and almost all of it has been warned about for years — but it has one property no previous version had: it's the last release of the two-per-year model. Starting with Node 27, the project moves to one release per year, and every release is LTS. The odd/even distinction that spent a decade deciding which version you could run in production disappears.

That makes this upgrade more than a version bump: it's the last train on the old schedule, and it's worth boarding knowing what's inside. Here's what really breaks, sorted by impact, and at the end the full calendar so you can decide when to move.

First: where are you coming from?

The effort depends on your starting point:

From Node 24 (the current LTS): the comfortable scenario. The incompatible changes are few and very localized; for most projects the migration is checklist work, not refactoring work.
From Node 22: still reasonable, but with more fronts — you absorb everything that changed in 24 (V8, permissions, minimum glibc) plus what's new in 26. Node 22 leaves maintenance in April 2027, so you have a real deadline.
From Node 25: odd releases were never for production, and this was the last one that will ever exist. Jump to 26 without thinking twice.

The schedule change: Node 27 debuts a new model

The official project announcement sums it up:

Aspect	Through Node 26	From Node 27 on
Major releases per year	2	1
LTS versions	Even-numbered only	All of them
Short-lived odd versions	Yes	Gone
Alpha channel	Didn't exist	6 months, allows semver-major changes
Total support per version	36 months	36 months (unchanged)

The concrete dates that affect you:

Node 26: Active LTS from October 28, 2026, maintenance from October 20, 2027, end of life on April 30, 2029.
Node 27: alpha channel opens October 28, 2026 (the same day 26 goes LTS), release on April 22, 2027, and it will also be LTS.
Node 24: Active LTS until October 20, 2026, when it moves to maintenance (critical and security fixes only); end of life on April 30, 2028.

The exact dates come from the schedule.json in Node's release repository, the file the project itself works from; the new schedule was announced on the Node.js blog.

The practical consequence: you'll no longer have to memorize which versions "count". Every release from here on is production-grade, and one release per year means fewer migrations per decade for your team. If you maintain libraries, the part that concerns you is the alpha channel: six months to test breaking changes before each release ships.

High impact

1. The internal `_stream_*` modules are gone

The removal with the most shrapnel, because it doesn't break your code: it breaks old dependencies. The internal modules _stream_readable, _stream_writable, _stream_duplex, _stream_transform, _stream_passthrough and _stream_wrap — deprecated since Node 12 — have been removed entirely. Any require('_stream_readable') now throws MODULE_NOT_FOUND.

No package maintained in recent years does that, but ecosystems drag fossils along. To find out whether you have one:

grep -rn "_stream_" node_modules --include="*.js" -l | head

If something shows up, you have two exits: update that package to a version using the public API (node:stream), or — if it's abandoned — replace it. The readable-stream polyfill covers most cases where the package is yours and you just need a mechanical migration.

2. Undici 8: the global `fetch` gets strict

Node 26 ships Undici 8.0, the implementation behind the global fetch. It brings stricter header validation and changes to redirect handling. If your code builds requests with dynamically generated headers — from a database, from user input, from another API — what used to pass silently can now throw a TypeError.

The pattern that shows up most in practice:

// If any value carries \n or \r (e.g. a token copied with a trailing newline),
// Undici 8 rejects it instead of silently sanitizing.
const res = await fetch(url, {
  headers: { Authorization: `Bearer ${token}` },
});

The right fix is not catching the error: it's sanitizing the value at the edge, where it enters your system (token.trim() when you read it). Having the request blow up before it leaves is the good behavior — with Undici 7 that token with a \n would travel and fail at the server on the other side, which is far harder to debug.

3. Native addons: mandatory recompilation

NODE_MODULE_VERSION moves to 147, so every compiled addon (bcrypt, sharp, better-sqlite3, canvas…) needs to be rebuilt or ship prebuilds for the new ABI. The error is unmistakable:

Error: The module was compiled against a different Node.js version using NODE_MODULE_VERSION 137.

npm rebuild solves it locally; in CI and Docker, rebuilding the image on the new base is enough. The detail that can actually stall you: the build requirements went up — GCC 13.2 minimum, and Python 3.9 support was dropped from the build toolchain. If you compile addons inside an old Debian/Alpine image, update the image before fighting the wrong error.

Free tool: Docker Compose Validator — Validate your compose.yaml against the official Compose schema and catch key typos, wrong types and YAML errors, with the exact line. All in your browser.

Medium impact

4. `module.register()` is runtime-deprecated

The async module-hooks API — the one used by instrumentation loaders, on-the-fly transpilation and APM agents — now emits a runtime deprecation. The designated replacement is the synchronous module.registerHooks() API.

This reaches you mostly through third parties: observability agents (Datadog, New Relic, OpenTelemetry) and tools like tsx live in that layer. The action item isn't rewriting anything of yours: it's updating those dependencies to the versions that already migrated before moving production to 26.

5. `writeHeader()` removed from the HTTP server

http.Server.prototype.writeHeader() was an undocumented alias of writeHead(). It's gone. If it appears in your code, the fix is literal, letter for letter:

// Before
res.writeHeader(200, { 'Content-Type': 'application/json' });
// Now
res.writeHead(200, { 'Content-Type': 'application/json' });

A grep -rn "writeHeader" src/ tells you in seconds whether you're affected. Frameworks (Express, Fastify, Nest) have always used the documented API; this bites hand-written HTTP code from many years ago.

6. `type: "module"` packages: the extensionless-CJS exception is gone

In packages declared as ESM, loading a CommonJS file without an extension relied on a historical resolver exception that Node 26 removes. If a "type": "module" package of yours had a require of a path without an explicit .cjs/.js, it now fails. The fix is adding the extension — which is what ESM resolution always asked for.

Low impact

localStorage with no backing file returns undefined instead of throwing. If you probed availability with try/catch around localStorage, invert the check: it's a plain if now.
QuotaExceededError becomes a DOMException-derived interface. Only affects code comparing the error by constructor or numeric code.
Several crypto APIs advance in the deprecation cycle — one reaches end of life and others start warning at runtime. If you see no warnings with --pending-deprecation today, you're not affected.
assert accepts printf-style messages in assertion errors. It's an addition, but it changes text output: if your CI parses assert messages (bad idea, while you're here), review it.

What does NOT break, even if you've read otherwise

The Temporal API doesn't break Date. Temporal arrives enabled by default in Node 26, but it's an addition: all your Date code keeps working exactly as (badly as) before. Migrating is optional and gradual — I have a full guide to Temporal in Node 26 with the conversion table from date-fns and dayjs.
Running TypeScript directly is now stable. node app.ts works with no flags: type stripping left experimental status. The only thing that "breaks" is the --experimental-transform-types flag, which was removed precisely because the feature graduated — if you had it in an npm script, delete it and move on.
V8 14.6 only adds. Map.prototype.getOrInsert(), Iterator.concat() and the rest of the Chromium 146 features are additions with zero migration cost.

The upgrade, in practice

The order that produces the fewest surprises:

Install 26 next to your current version, not over it. With fnm or Volta it's one command, and rolling back takes seconds.
npm rebuild (or delete node_modules and reinstall) to regenerate native addons against ABI 147.
Run the suite with deprecations visible:

   node --pending-deprecation --trace-deprecation ./node_modules/.bin/vitest run

The module.register() and crypto ones show up here, with a stack trace to the culprit.

grep for the fossils: _stream_, writeHeader(. Two minutes that save you a production surprise.
Update your agents (APM, telemetry, loaders) to versions that declare Node 26 support — it's the layer that takes longest.
Review the engines field in your package.json and your critical dependencies: npm ls --depth=0 plus a glance at EBADENGINE warnings during install.

When should you upgrade?

New project: start on 26 today. There's no reason to begin something that will live for years on 24.

Production on 24: the sensible window opens on October 28, 2026, when 26 enters LTS and eight days after 24 moves to maintenance — with 24 supported until April 2028 there's no rush, but no reason to wait until the end either: the longer you wait, the further this list drifts from fresh memory.

Production on 22: move now. April 2027 looks far away until it doesn't, and the 22 → 26 jump is bigger than 24 → 26.

Frequently asked questions

When does Node 26 enter LTS?

On October 28, 2026, according to schedule.json in the nodejs/Release repository. Node 26 shipped as the Current release on May 5, 2026, moves to maintenance on October 20, 2027, and its end of life is scheduled for April 30, 2029. It has no announced codename yet.

What changes in the Node.js release schedule starting with Node 27?

Starting with Node 27 (April 2027) the project moves from two major releases per year to one, and every release will be LTS: the odd/even distinction disappears. A six-month alpha channel is added (the Node 27 alpha opens on October 28, 2026) where breaking changes are tested before release. Total support per version remains 36 months.

What breaks when upgrading from Node 24 to Node 26?

Little, and very localized: the removed internal stream* modules (affects very old dependencies), the removed writeHeader() HTTP server alias, Undici 8 with stricter header validation in fetch, the runtime deprecation of module.register(), and native addon recompilation due to the ABI change to NODE_MODULE_VERSION 147. For most projects it is checklist work, not refactoring work.

Can I run TypeScript directly in Node 26?

Yes. Type stripping is stable in Node 26: node app.ts works with no flags. The --experimental-transform-types flag was removed precisely because the feature is no longer experimental; if you had it in a script, just delete it.

How long is Node 24 supported?

Node 24 moves from Active LTS to maintenance on October 20, 2026 (critical and security fixes only from then on) and its end of life is scheduled for April 30, 2028, so there is no immediate urgency to leave it. The recommended migration window to 26 opens on October 28, 2026, when 26 enters LTS.

Does the Temporal API in Node 26 break code that uses Date?

No. Temporal ships enabled by default but it is a new API that coexists with Date: it does not change or remove any existing behavior. Migrating to Temporal is optional and can be done gradually, file by file.

Originally published on ortamarco.me.

DEV Community: Marco Orta

Laravel 13: What Actually Breaks When You Upgrade (and What Doesn't)

First: where you are and how urgent this is

Entry requirement: PHP 8.3

High impact

1. Dependencies in composer.json

2. The CSRF middleware changes name and behavior

Medium impact

3. serializable_classes in the cache config

4. upsert with MySQL or MariaDB

Low impact (the ones that will actually bite)

5. Cache prefixes and session cookie name

6. JobAttempted now exposes the exception

7. QueueBusy: $connection becomes $connectionName

8. Container::call respects nullable defaults

9. Domain route precedence

10. DELETE with JOIN, ORDER BY, and LIMIT on MySQL

11. Polymorphic pivot table names

12. Collection serialization restores eager-loaded relations

13. Str factories reset between tests

14. extend callbacks are bound to the manager

15. Bootstrap 3 pagination view names

16. Js::from stops escaping Unicode

17. The PHP 8.5 polyfill and global helpers

Very low impact: only if you maintain packages

What does NOT break, whatever you may have read

The upgrade, in practice

Checklist before you merge

Conclusion

Frequently asked questions

When does Laravel 12 support end?

Which PHP version does Laravel 13 require?

What are the high-impact breaking changes in Laravel 13?

Is app/Http/Kernel.php removed in Laravel 13?

Why did my entire cache disappear after upgrading to Laravel 13?

How long does upgrading from Laravel 12 to Laravel 13 take?

The AI model your business runs on is being retired: the 2026 shutdown calendar

What nobody told you when you bought it

First: does this affect you? The three-minute check

If you have access to the OpenAI dashboard

If you have access to the Anthropic console

If you have access to nothing

OpenAI's shutdown calendar

Anthropic's calendar works differently

Gemini: two shutdowns between September and October

The trap that catches the most people: where you run it changes the date

What else breaks, and it isn't a model

The migration procedure

1. Inventory before touching anything

2. Pin the version, don't use the alias

3. Compare side by side before switching

4. Put the provider behind your own layer

If you have no technical team: what to demand, and from whom

What the switch costs (and why you sometimes come out ahead)

The radical way out: make it un-switchoffable

Frequently asked questions

What exactly happens on shutdown day?

I use ChatGPT in the browser, not the API. Does this affect me?

How do I know if my chatbot uses the Assistants API?

Is migrating just changing the model name?

How often will this happen again?

Does using LangChain or a chatbot SaaS protect me?

Conclusion: put it in the calendar today

Node 26: What Breaks When You Upgrade, and When the Jump Is Worth It (LTS Guide)

First: where are you coming from?

The schedule change: Node 27 debuts a new model

High impact

1. The internal _stream_* modules are gone

2. Undici 8: the global fetch gets strict

3. Native addons: mandatory recompilation

Medium impact

4. module.register() is runtime-deprecated

5. writeHeader() removed from the HTTP server

6. type: "module" packages: the extensionless-CJS exception is gone

Low impact

What does NOT break, even if you've read otherwise

The upgrade, in practice

When should you upgrade?

Frequently asked questions

When does Node 26 enter LTS?

1. Dependencies in `composer.json`

3. `serializable_classes` in the cache config

4. `upsert` with MySQL or MariaDB

6. `JobAttempted` now exposes the exception

7. `QueueBusy`: `$connection` becomes `$connectionName`

8. `Container::call` respects nullable defaults

10. `DELETE` with `JOIN`, `ORDER BY`, and `LIMIT` on MySQL

13. `Str` factories reset between tests

14. `extend` callbacks are bound to the manager

16. `Js::from` stops escaping Unicode

1. The internal `_stream_*` modules are gone

2. Undici 8: the global `fetch` gets strict

4. `module.register()` is runtime-deprecated

5. `writeHeader()` removed from the HTTP server

6. `type: "module"` packages: the extensionless-CJS exception is gone