DEV Community: ushiro

33 Things in Three Vendors' OpenAPI Specs Existed for Exactly One Day

ushiro — Tue, 06 Oct 2026 12:00:00 +0000

An OpenAPI spec reads like a contract. It is versioned, it is machine-readable, it generates your
client. It is also a file the vendor edits, and nothing in it records what it said last week.

I have been diffing the published specs of OpenAI, Anthropic and Groq and keeping every key that
appears: 2,802 operations, parameters, enum variants and beta markers. Of those, 215 are no
longer there.

157   parameters
 29   enum variants
 27   whole operations
  2   beta markers

The removals are not evenly aged. Sorted by how long each one was in the file:

 76   over a year
 87   under a year
 17   under 30 days
 33   first seen and last seen on the SAME DAY
  2   excluded — a defect in my own collection, see the notes

That last line is the one I did not expect.

Fourteen of them landed on a single afternoon

On 2025-03-22, OpenAI's spec gained four operations for fine-tuning checkpoint permissions:

POST   /fine_tuning/checkpoints/{permission_id}/permissions
GET    /fine_tuning/checkpoints/{permission_id}/permissions
DELETE /fine_tuning/checkpoints/{permission_id}/permissions
DELETE /fine_tuning/checkpoints/{fine_tuned_model_checkpoint}/permissions

Read the path parameters. Three of them key the collection on {permission_id} — the id of a
thing inside the collection you are listing. The fourth keys the same collection on the
checkpoint. They cannot both be right, and a GET .../{permission_id}/permissions that returns a
list of permissions is a path that was never going to ship in that shape.

The next capture did not have any of them. Fourteen keys — four operations and their ten
parameters — in and out, same date.

And some land on endpoints you actually call

POST /chat/completions carried a parameter called instance_id on 2024-02-09 and on no other
day I have.

POST /responses listed computer-preview as a tools[] variant on 2025-03-11 and not
afterwards.

Anthropic's POST /v1/messages carried user_profile_id from 2026-04-16 to 2026-06-22 — 67
days, long enough that a client generated in May has a field for it. Six of Anthropic's
/v1/environments operations carried a sessionKey parameter on 2026-04-08 and lost it on
2026-04-09. I do not know what any of these were for, and I am not going to guess; what I can say
is that they were in the published document and then were not.

What this does and does not mean

It does not mean the API changed. This is the part I had to be careful about, and the clearest
example is Anthropic's tool_choice.

On 2024-10-03 three enum variants — auto, any, tool — stop appearing. tool_choice: auto
obviously still works. What happened is that the schema moved those values behind a $ref, and
the shape my reader looks for stopped matching. The parameter tool_choice is still in the file
and still marked present; only the three variant keys went to zero.

So "removed from the spec" means the key is no longer where it was in the document. Sometimes
that is a deprecation. Sometimes it is a refactor of the YAML. The 27 removed operations are the
subset I would trust furthest — a path disappearing is hard to do by accident — and even there,
OpenAI's six Assistants file endpoints going on 2024-04-15 is the documented v2 migration, not a
surprise.

What it does mean is that the file is not a record of itself. If you want to know when
user_profile_id appeared, the current spec cannot tell you, and neither can the changelog —
there was no entry for it.

What I would actually do about it

Pin the spec file, not the URL. Vendor it into your repo with a hash and diff it on a
schedule. Every one of the findings above is a git diff someone could have had for free; the
only reason I have them is that nobody else kept the old copy.

Treat a generated client as a snapshot with a date on it. A client generated between April and
June of 2026 has an user_profile_id field that no longer exists upstream. Nothing failed, and
nothing told you.

Watch for same-day keys before you build on one. A capability that appears in the spec and
nowhere in the changelog, docs or release notes is a capability that may not survive the week.
Fourteen of OpenAI's did not survive the day.

Notes on the numbers

Three vendors only — OpenAI (1,605 keys), Anthropic (1,069) and Groq (128). They are the ones
publishing a machine-readable spec at a stable URL; most of the vendors I track do not, which is
why the comparison stops at three.

first_seen is a floor, not an introduction date, for 153 of the keys: 90 OpenAI, 38 Groq and
25 Anthropic were already in the file on the first capture I have. Everything in this post keys
off removals, where the date is observed rather than inferred — but a lifespan that starts at a
floor is a lower bound.

Two rows have a last_seen earlier than their first_seen (an OpenAI uploads parameter and a
Groq stream_options). That is a defect in my own collection, not a vendor doing something
strange, and both are excluded from the 33.

The removed keys, per vendor, with the dates:
aichangewatch.com/api-features

I Published a Median Model Lifespan. Seven Weeks Later the Same Query Said 219 Days More.

ushiro — Fri, 02 Oct 2026 12:00:00 +0000

On 2026-08-01 I computed how long an AI model lives, from the day it shows up to the day its
vendor says it will be switched off. The answer was 197 days, over 57 models.

I ran the same query on 2026-09-22. It now says 416 days, over 74 models.

Nothing happened to the models. Seventeen models joined the sample, and the middle of it moved
seven months. That is not a metric with noise in it; that is a metric whose value is mostly
determined by who is in the denominator.

Here is the denominator.

528, 290, 74

528   models where I have a recorded arrival date
290   models where a vendor has published a shutdown date
 74   models that have both        ← every lifespan number comes from here

That is 14% of the models I can name. The other 86% split into two piles, and both piles are
excluded for reasons that are not random:

454 models have an arrival and no announced end. They are alive, or at least nobody has said otherwise. A model that never gets a shutdown date never enters the average, no matter how long it runs.
216 models have a published shutdown date and no arrival I can point to. Mostly vendors whose deprecation table lists models their changelog never announced.

So the measurable population is: models that were born after I started watching and have since
been sentenced. Long-lived models are systematically underrepresented, because a model that is
still running contributes nothing until the day someone schedules its execution.

The median is a fact about vendors, not about models

Split the 74 by who made them:

vendor	models measurable	median	range
Google	27	211d	7 – 499
Azure	20	488d	212 – 1,017
OpenAI	16	537d	272 – 1,240
AWS	8	535d	483 – 920
Moonshot	2	183d	183 – 188
Anthropic	1	608d	—

Google is 36% of the sample and its median is less than half of everyone else's. Not because
Google's models die young in some general sense, but because Google ships a lot of -preview
models and publishes end dates for them. The shortest span in the whole set is
gemini-3.1-pro-preview: 7 days, arriving 2026-03-01 and scheduled off 2026-03-08.

Anthropic contributes exactly one model to a statistic about model lifespans.

Now re-read the headline number. "The median model lives 416 days" is, mechanically, "Google's
preview cadence and Azure's back catalogue, mixed in whatever proportion happened to have both
dates on record this week." Change which vendors publish end dates — not which models exist — and
the number moves. Which is exactly what it did between August and September.

The longest life in the set is a join across two vendors

gpt-4 measures 1,240 days: arrival 2023-06-01, shutdown 2026-10-23.

The shutdown is OpenAI's, from OpenAI's deprecation page. The arrival is Azure's, from an Azure
"What's New" entry — and Azure's What's New is monthly, so the day component is not a
measurement, it is the first of the month. 29 of the 74 arrival dates in this sample are month
floors like that — 39% of the population carries up to 30 days of error on one end.

Is it wrong? It is the same model, and the metric is defined as first record across the sources
I read, which is what it says on the page. But "first record across sources" and "launch date"
are different quantities, and the gap between them is entirely determined by which source I
happened to add first.

What is actually solid here

Not the median. Three other things from the same rows are:

The spread. Q1 is 216 days and Q3 is 570. The interquartile range is a year. Whatever the
centre is, half the measurable models fall in a band that wide, which is enough on its own to
say that planning against a "typical" model lifetime is not a thing you can do.

454 models have no announced end. That is not a lifespan estimate, it is a disclosure fact,
and it needs no denominator games: the vendor has published nothing.

The vendors' own stated policies. Anthropic publishes a 60-day minimum and AWS publishes six
months. Those are commitments, not observations, and they do not move when my crawl coverage
changes. If you need a number to plan against, use those — and note that only two vendors of the
fifteen I read publish one at all.

What I would actually do about it

Ask any "average model lifespan" figure for its n and its denominator. Mine is 74 out of 528.
A figure quoted without those two numbers is quoting the shape of somebody's crawl.

Don't derive a migration budget from a central tendency. Derive it from the one date that is
about your model: whether the vendor has published a shutdown date for the exact string you send
in the API call, and what their stated notice period is.

Watch the arrival side, not just the retirement side. Every vendor here publishes retirements
somewhere. Far fewer publish arrivals in a form you can date, which is precisely why 216 models
have an end and no beginning.

What this measures

Published vendor documentation across 15 vendors, read on 2026-09-22, model names matched on
normalised strings. A model is counted once, at its earliest published shutdown date. Successor
models are excluded from the retirement side — counting them stamps the replacement with the
retirement date of the model it replaces.

By the time you read this the live figure will be different, and that is the point of the post
rather than a disclaimer on it.

The lifespan section, recomputed on every load, with the count it was drawn from:
aichangewatch.com/insights

8 of the 26 Codes Behind HTTP 429 Are Not Rate Limits. Backoff Will Never Clear Them.

ushiro — Tue, 29 Sep 2026 12:00:00 +0000

The retry-on-429 loop is the most copied piece of LLM plumbing there is. Catch the status, sleep,
double the sleep, try again. Every SDK ships one and every tutorial recommends it.

I read the published error documentation of 9 model vendors and pulled out every code they put
behind HTTP 429. There are 26 of them. Here is what they actually mean — the right-hand column is
the vendor's own stated cause, shortened to fit; nothing below is my paraphrase of their intent.

anthropic  rate_limit_error                    A rate limit, OR the monthly spend cap. Same code.
aws        ThrottlingException                 Exceeding the account quotas for Amazon Bedrock.
aws        ModelNotReadyException              The model is not ready to serve inference requests.
cohere     Too Many Requests                   The rate limit has been exceeded.
deepseek   Rate Limit Reached                  You are sending requests too quickly.
google     rate_limit_exceeded                 Per-minute or per-second request or token limit.
google     too_many_requests                   Too many requests in a short period of time.
google     quota_exceeded                      You have exceeded your daily quota.
groq       Too Many Requests                   Too many requests in a given timeframe.
mistral    Too many requests                   Exceeded the rate limit for your subscription tier.
openai     Rate limit reached for requests     You are sending requests too quickly.
openai     Slow down                           Your request rate increased too quickly.
qwen       Throttling                          (no cause published)
qwen       Throttling.AllocationQuota          (no cause published)
qwen       Throttling.BurstRate                Call frequency spiked suddenly.
qwen       Throttling.RateQuota                Call frequency (RPS/RPM) triggered rate limiting.
qwen       Throttling.ServiceOverloaded        Network resources are in an overloaded state.
qwen       Throttling.ResourceExhausted        Network resources are in a saturated state.

openai     Credit balance exhausted            Your organization has no prepaid credits remaining.
openai     Organization spend limit reached    Your organization reached its enforced spend limit.
openai     Organization usage limit reached    Reached its OpenAI-assigned usage limit.
openai     Project spend limit reached         Your project reached its enforced spend limit.
qwen       CommodityNotPurchased               Workspace subscription not purchased.
qwen       PrepaidBillOverdue                  Workspace prepaid bill expired.
qwen       PostpaidBillOverdue                 Model inference service expired.
qwen       BudgetLimitExceeded                 The configured budget has been exhausted.

The blank line is mine — the vendors publish one list. Everything under it is documented as a
billing or account state, not a rate.

The vendors say so themselves

I did not classify these. The vendors did, in the remedy they print next to the code:

openai / Credit balance exhausted — "Add credits to continue using the API."

openai / Project spend limit reached — "Increase or remove the spend limit in your project
settings."

qwen / CommodityNotPurchased — "Purchase workspace service first."

qwen / BudgetLimitExceeded — "You will be unable to make further API calls until the budget
limit is increased or reset."

All four of the OpenAI ones and all four Qwen ones need a human to spend money or raise a
limit. No amount of sleeping changes them. A loop that retries a 429 six times with exponential
backoff spends about a minute confirming that your credit card is still not on file, and then
raises the same error it would have raised immediately — except now it looks like a transient
capacity problem in your logs.

The same condition is a 402 at four other vendors

This is the part that makes the status code useless as a signal.

condition	vendor	status
out of money	DeepSeek	402 Insufficient Balance
out of money	Anthropic	402 billing_error
out of money	Cohere	402 Payment Required
out of money	Google	402 payment_required
out of money	OpenAI	429 Credit balance exhausted
out of money	Qwen	429 PrepaidBillOverdue

"You have run out of balance" is DeepSeek's 402. "Your organization has no prepaid credits
remaining" is OpenAI's 429. Same sentence, different half of the 4xx range.

If you run more than one vendor behind one client — which is the entire point of most gateway
code — a handler that branches on the status code will fail-fast on DeepSeek and retry-loop on
OpenAI, for the identical business condition.

Google, which serves both, spells out the consequence in the remedy on its own 402:

"Add credits to your billing account, or turn on auto-reload. Don't retry: the request won't
succeed until credits are added."

That instruction is correct, and it is printed on the status code that nobody retries anyway. The
codes that actually end up inside retry loops are the 429s, and that is where it is missing.

Qwen does it inside a single vendor. "Workspace subscription not purchased" is
CommodityNotPurchased, a 429. "Model Studio service is not activated" is
AccessDenied.Unpurchased, a 403.

Anthropic puts both meanings on one code

Branching on the vendor's code instead of the status is the obvious fix, and for one vendor it is
not enough. rate_limit_error is Anthropic's only 429, and its documented cause now reads:

"Your organization has hit a rate limit, reached its usage tier's monthly spend cap, or reached
a spend limit on the Claude Code workspace. A tier spend-cap 429 has no retry-after header and
keeps failing until access resumes."

One code, one status, and the two cases need opposite handling. Anthropic tells you how to tell
them apart — the absence of Retry-After — which means the discriminator is a missing header.

Two more that aren't what they look like

aws / ModelNotReadyException is a 429 and has nothing to do with your request rate. The
model is warming. AWS documents that its own SDK "will automatically retry the operation up to 5
times" — so if you wrapped the SDK in your own retry loop, you have 5×N attempts and a timeout
budget you did not plan.

google / quota_exceeded is a 429 that says "You have exceeded your daily quota." Google's
own remedy is "Wait until the quota resets or request a quota increase." An exponential backoff
capped at a few minutes will exhaust itself against a counter that resets tomorrow. Google
publishes a separate code — rate_limit_exceeded — for the per-minute case, and that one's remedy
does say "Wait and retry with exponential backoff." One vendor, one status, two opposite
instructions.

What the 26 actually split into

15   clear on their own if you back off
 1   a rate limit OR a spend cap, on one code          anthropic / rate_limit_error
 1   clears at the daily reset, not on your timer      google / quota_exceeded
 1   clears when the model finishes warming            aws / ModelNotReadyException
 8   do not clear until a person spends money

Only 3 of the 9 vendors mention the Retry-After header anywhere in their error documentation —
OpenAI, Mistral, and Anthropic, whose mention is that the spend-cap case does not send one. The
header may well be on the wire elsewhere; it is not in the docs you would read to write the
handler.

What I would actually do about it

Branch on the vendor's code, not the status. Every vendor here returns a machine-readable code
in the body. The status tells you which half of the 4xx range someone chose; the code usually
tells you what happened — with Anthropic's as the exception you have to special-case.

Give the money errors their own path. They are not retryable and they are not transient —
they are an outage with a billing cause, and they should page someone rather than dissolve into a
retry counter. Alerting on "429 rate" makes exactly this class invisible.

Cap unknown 429s, don't trust them. Treating an unrecognized 429 as retryable is fine.
Retrying it 6 times with a 60-second ceiling because "429 means slow down" is what turns a
five-second failure into a minute of held connections.

What this does and does not measure

This is the vendors' published documentation, read on 2026-09-28 — not traffic. If a vendor
returns a code it never documented, I do not have it, and several of these docs are visibly
incomplete: Qwen publishes no cause text at all for two of its four throttling codes.

It moves, too. A week before publishing this I counted 21 codes, not 26: Google has since
documented too_many_requests and a 402, OpenAI a second rate code, Qwen a budget one and two
capacity ones, and Anthropic rewrote its single cause to name the spend cap. A post about error
semantics going stale in under a week is not an aside — it is the same reason the handler you
wrote last year is describing a set of conditions that no longer matches.

Corrected 2026-10-03. This went out saying 24 codes. It was 26: my own extractor was reading
Qwen's page with a selector the vendor had changed, and it dropped two of their throttling codes
along with the cause and remedy text on 36 rows. The vendor's page was right the whole time; the
count I published was mine being wrong about it. Fixed, and the piece now matches the page.

That cuts one way only. Every code above is one the vendor chose to write down, and the eight that
need a credit card are documented as clearly as the ones that need patience. They are behind the
same three digits anyway.

I track these pages and keep what they overwrite. The 182 documented error codes across 9
vendors, one page each, with the vendor's own cause and remedy:
aichangewatch.com/errors

A Vendor Deleted a Shutdown Date and Nothing Told Anyone. So I Counted the Next 90 Days.

ushiro — Thu, 24 Sep 2026 12:00:00 +0000

On 2026-07-28, Google's deprecation page listed October 16, 2026 as the shutdown date for
gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite.

On 2026-08-03, the date was gone.

As I write this the same page reads "No shutdown date announced" for all three, and the string
2026-10-16 appears on it zero times. No changelog entry, no banner, no email. The page simply
says something different than it did a week earlier.

Nothing was wrong on either day. A team that read it in late July scheduled a migration against
an October deadline. A team that read it a week later saw no deadline at all. Both read the
vendor's own documentation. Neither had any way to know the other reading existed.

That is not carelessness. It is what a page does when it stores state instead of history: it
can be correct every single day and still never tell you it changed. I wrote that one case up
with the full before-and-after
here;
this post is what happened when I stopped looking at one case and counted all of them.

I run a crawler over the deprecation pages of 15 model vendors for exactly this reason — it reads
them daily and keeps what they overwrite. Which means I can ask a question the pages themselves
can't answer: what does the next quarter actually look like, across all of them at once?

The next 90 days

62 models are scheduled for removal between 2026-09-24 and 2026-12-22.

Sep (24-30)   12
Oct           28
Nov           12
Dec (1-22)    10

By vendor. The two right-hand columns turned out to matter more than the count:

vendor	shutdowns	names a successor	states when it was announced
OpenAI	36	31	1
Azure	13	10	0
AWS	6	0	6
Google	6	6	0
xAI	1	1	0
total	62	48	7

Read those two columns as a pair

Migrating off a model is two questions. What do I move to, and how much time do I have.

OpenAI, Azure and Google answer the first one well — 47 of their 55 shutdowns name a replacement.
None of them tell you when the clock started. AWS is the exact mirror: all six of its entries
carry an announcement date, and not one names a successor.

Across all 62, exactly one record carries both facts.

It is gpt-5.4-cyber. Announced 2026-09-11, removed 2026-10-01, with gpt-5.6-cyber named as
the target. Twenty days.

For scale, Anthropic publishes a 60-day minimum and AWS publishes six months, both as stated
policy you can go and read. Those are commitments you could hold someone to, and the gap between
them is real: the same Claude model gets 60 days of notice on one platform and 184 on the other,
which I measured in the same write-up.

There is no published policy behind the twenty. It is just what the page happened to say that
week.

So the one entry this quarter that answers both halves is also the shortest runway in it. That
reads less like coincidence than like a shape: a vendor that publishes an announcement date has
made notice into something measurable, and a vendor that doesn't has nothing to be measured
against.

The column I refuse to fill in

"States when it was announced" means the vendor printed a date on its own page. When they don't,
I leave the field null.

I do not substitute the timestamp of my own crawler, even though I have one for every record
and it would fill that column nicely. My crawler runs hourly, so its timestamp measures my
polling interval plus whenever the vendor got around to editing. Writing that into a field
labelled announced would turn my latency into a vendor commitment.

Seven out of 62 is an unsatisfying number to publish. It is also the only honest one.

The successor column follows the same rule: it holds the model the vendor names, not the model I
think you should use.

The ones that can't be counted at all

34 deprecations in the archive were announced with no shutdown date.

They aren't in the 62 and they never will be, because a calendar view has nowhere to put them.
If you are running one of those, your model is formally deprecated, has no announced end, and
will not appear in any quarterly list until somebody assigns it a date — possibly with twenty
days' notice.

What I would actually do about it

Four of these dates land within a week of this post. sora-2 and sora-2-pro plus three dated
variants go on
2026-09-24, no successor named. babbage-002, davinci-002, gpt-3.5-turbo-1106 and
gpt-3.5-turbo-instruct go on 2026-09-28. AWS retires Nova Canvas and Nova Reel on 2026-09-30.
Azure retires gpt-4o and o3-mini on 2026-10-01.

Pin the dated model string, not the alias. A lot of the entries above are dated variants —
sora-2-2025-10-06 and its siblings. Point your code at the undated name and you are on whatever
the vendor last mapped it to, and the variants do not all retire on the same day.

Snapshot the page you are planning against. This is the one that would have caught the Google
case, and it does not require what I built. A scheduled job that curls the deprecation page and
commits the HTML to a repo gives you a diff and a date. The entire problem is that you cannot see
July's version from inside August — a cron job and 20 lines of YAML fixes that for one vendor.

The full 62 with dates and successors, plus a page per model:
aichangewatch.com/deprecations

A Model Google Lists as Shut Down Answered Me Today. Read `modelVersion` Before You Trust It.

ushiro — Mon, 21 Sep 2026 12:00:00 +0000

Google's Gemini deprecation page defines its terms up front:

Once a model is "shutdown", it is completely turned off, and the endpoint is no longer
available.

The same page marks already-shutdown models with a grey row, and gemini-3.1-flash-lite-preview
is grey. Shut down. Endpoint gone.

I called it on 2026-09-20:

curl -s "https://generativelanguage.googleapis.com/v1beta/models/\
gemini-3.1-flash-lite-preview:generateContent?key=$KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"What is 7 times 6? Answer with the number only."}]}]}'

HTTP 200
"42"

No error, no warning header, no notice in the payload.

One field says what actually happened

{
  "candidates": [ ... ],
  "modelVersion": "gemini-3.1-flash-lite",
  "usageMetadata": { "totalTokenCount": 16, "serviceTier": "standard" }
}

I asked for gemini-3.1-flash-lite-preview. I was served gemini-3.1-flash-lite — the GA model
named in the replacement column of the very row that says the preview is shut down.

Calling the GA name directly confirms they are the same thing now:

request = gemini-3.1-flash-lite          -> modelVersion = gemini-3.1-flash-lite
request = gemini-3.1-flash-lite-preview  -> modelVersion = gemini-3.1-flash-lite

The retired ID resolves to its successor. Your call succeeds. A different model answers it.

Before you generalise this — two things that are NOT the story

I went looking for "vendor ignores its own shutdown dates" and did not find it. Two corrections
I had to make to my own reasoning, both from reading the page more carefully:

The dates in that table are not shutdown dates. The page says so explicitly:

The shutdown dates listed in the table indicate the earliest possible dates on which a model
might be retired. We will communicate the exact shutdown date to users with advance notice.

So a model still running past the date in its row is not a broken promise. It is the documented
behaviour. Two other previews — gemini-3.1-flash-image-preview and gemini-3-pro-image-preview
— are past their June 25 dates and still live, and their rows are not grey. Google is not
claiming they are shut down. Nothing is wrong there.

The scope is small. Of the 32 rows the page marks as already shut down, exactly two still
appear in the live ListModels output:

gemini-3.1-flash-lite-preview   -> gemini-3.1-flash-lite   (generation verified)
gemini-2.5-pro-preview-tts      -> countTokens returns 200 (generation not tested)

Thirty of thirty-two are genuinely gone. This is a narrow gap, not a pattern of neglect.

Why the narrow version still matters

An alias is the kind choice. The alternative is a hard failure on the shutdown date, which takes
down every service still pointing at the old name — including the ones whose owners never read
the deprecation page. Google kept those callers running and pointed them at the model it had
already told everyone to migrate to. If your code is "call an LLM, get text back," this saved
you an outage and cost you nothing.

But nobody types -preview into a config file by accident. You pin a specific model ID for one
reason: you want the same model next month that you had this month.

That is the property the alias silently removes. Your request still succeeds, your tests still
pass, your error rate stays flat — and the weights answering are not the weights you evaluated
against. Prompts tuned on that preview, a golden-output suite, a published benchmark, a cached
embedding space, a customer-facing behaviour you signed off on: all measured against a model
that the vendor says is turned off.

The failure mode is not an outage. It is quiet drift behind a green dashboard.

Nobody has said how long this lasts

Here is the part I want to be clearest about, because it is the part that should change what you
do.

The aliasing is not documented anywhere I can find. The deprecation page does not mention
aliases, redirects, or fallbacks — the words do not appear on it. It says the opposite: that a
shut-down model's endpoint is no longer available. There is no stated policy for how long a
retired ID keeps resolving, no commitment that it will keep working tomorrow, and no announcement
channel for the day it stops.

Which means you cannot plan against it. The behaviour I measured today is not a feature you were
offered and it is not a guarantee you can hold anyone to. It is an undocumented grace period of
unknown length, and the day it ends, the failure will look exactly like the outage the alias was
preventing — except now it arrives with no date attached, because the date already passed months
ago and you stopped watching.

Treat it as time to migrate, not as a migration you can skip.

What to actually do

Log modelVersion on every call. One field, and the only thing in the response that tells
you what answered. If you store nothing else about a request, store this.

Assert on it where it matters. A suite that exists to prove your prompt still behaves should
fail when the model underneath changes, not when the output finally drifts far enough for a human
to notice:

const res = await model.generateContent(req);
if (res.modelVersion !== EXPECTED_MODEL) {
  throw new Error(`served by ${res.modelVersion}, pinned ${EXPECTED_MODEL}`);
}

Read a retirement row as "the answer may change", not "the call may fail". Those are
different events, and only one of them pages you.

Most LLM plumbing I see checks the status code and reads candidates[0]. Everything between
those two is treated as noise. Here the entire signal was in the noise.

Verified against the live pages and API on 2026-09-20. I keep a record of these dates and what
they said before they changed:
aichangewatch.com/deprecations

My CLS Was 0 Until I Throttled the Network. Then It Was 0.11.

ushiro — Fri, 18 Sep 2026 13:00:00 +0000

Every measurement I took said my Cumulative Layout Shift was 0. Lighthouse, a headless Chrome
run, reloading the page and staring at it — all zero. The pages were shifting anyway.

The number was wrong because of how I was loading the page, and the shift itself came from a CSS
selector I would have called harmless.

Why an unthrottled measurement reads zero

Layout shift needs two paints to happen. The browser lays something out, more bytes arrive, and
it lays it out differently.

On a fast connection to a nearby server, the entire HTML document lands in one chunk. There is no
second paint, so there is no shift to record — on a page that genuinely shifts for real users on
real connections. The measurement isn't noisy. It is confidently, reproducibly zero.

You have to slow the page down until the streaming actually streams.

// Drive Chrome over CDP: --headless=new --remote-debugging-port=9222
await client.send('Emulation.setCPUThrottlingRate', { rate: 4 });
await client.send('Network.emulateNetworkConditions', {
  offline: false,
  latency: 300,
  downloadThroughput: (0.5 * 1024 * 1024) / 8,
  uploadThroughput: (0.5 * 1024 * 1024) / 8,
});

And record the shifts with the sources attached, because a bare CLS number tells you nothing
about which element moved:

await client.send('Page.addScriptToEvaluateOnNewDocument', {
  source: `
    window.__shifts = [];
    new PerformanceObserver((list) => {
      for (const entry of list.getEntries()) {
        if (entry.hadRecentInput) continue;
        window.__shifts.push({
          value: entry.value,
          sources: entry.sources.map((s) => ({
            node: s.node && s.node.nodeName + '.' + (s.node.className || ''),
            from: s.previousRect,
            to: s.currentRect,
          })),
        });
      }
    }).observe({ type: 'layout-shift', buffered: true });
  `,
});

Cache-bust the URL on every run. A warm CDN edge undoes the throttling you just configured.

Throttled, the same pages that had measured 0 came back at 0.110 and 0.025.

The selector

The layout is a content column with an optional sidebar. Some pages have the sidebar, some don't,
and the shell was deciding for itself which case it was in:

/* Two columns, unless there is no rail inside me. */
.shell { grid-template-columns: minmax(0, 1fr) 274px; }
.shell:not(:has(.termrail)) { grid-template-columns: minmax(0, 1fr); }

That reads as elegant. The container asks a question about its own contents and answers it. No
prop drilling, no flag to keep in sync, no way for the class and the markup to disagree.

It is also a bet — that the child parses before first paint.

Where that bet loses

The rail is the shell's last child. Here is what that means on a real page of mine:

HTML document        407,197 characters
.shell opens at       11,722
.termrail appears at 134,567   ← 122,845 characters later

The browser sees .shell open, looks inside for .termrail, does not find it yet, and paints
the content column at full width. 122,845 characters later the rail arrives, :has() starts
matching, and the column is re-laid out 274px narrower.

Everything the user had already started reading moves left. That is the 0.110.

The bet wins on a short page — the whole thing arrives before first paint and :has() is right
the first time. It loses in exact proportion to how much HTML you ship, which means it fails worst
on your biggest, most content-heavy pages. Those are usually the ones that matter.

The fix is to move the decision earlier

The information was available on the server the whole time. The only reason it wasn't in the
markup is that :has() made it feel unnecessary.

// The server already knows whether this page has a rail.
<div className={keys.length ? 'shell has-rail' : 'shell'}>

.shell { grid-template-columns: minmax(0, 1fr) 274px; }
.shell:not(.has-rail) { grid-template-columns: minmax(0, 1fr); }

The class now rides the container's opening tag. On that page it lands 122,845 characters ahead
of the element it used to depend on. Re-measured under the same throttling: 0.

The rule I took from it

Not "avoid :has()". The rule is narrower:

Never gate a grid or flex track count on :has(<descendant>). Put the signal on the container's
opening tag.

Anything that changes how much space siblings get — column counts, track sizes, flex-basis,
display on a wrapper — is a layout decision, and a layout decision keyed off a later element is
a race you lose on long pages.

:has() is fine where being wrong for a moment costs nothing. These are still in my stylesheet
and I have no plans to remove them:

:root:has(.gl-page) { scroll-behavior: smooth; }

Nothing reflows if that flips halfway through the load.

Two things worth keeping

A performance number you measured without throttling is not a measurement. It is a statement
about your connection. The default in headless Chrome is your own network and CPU, and both are
faster than what your users have.

Watch entry.sources, not the score. The total told me there was a problem, once I could see
one at all. It was the previous and current rects on the sources array — a column that was 1180px
wide and became 906px — that named the element and pointed straight at the selector.

This came out of a project that crawls the docs of 15 AI vendors and records every change with
the date it happened: aichangewatch.com

Search Console Shows Your Canonical Tag. Googlebot Never Gets It.

ushiro — Tue, 15 Sep 2026 12:00:00 +0000

grep found my <link rel="canonical">. Search Console's URL Inspection showed it. It was still
landing outside <head> for the crawler that actually indexes the site.

Here is the check that finally showed it, on a dynamic route in Next.js 15.5:

#    HTML bytes   </head> at   canonical at
1       151,428        4,766         103,412

The tag exists. It is 98,000 characters past the end of the head.

Why `grep` can't see this

Every tool I reached for first answers a different question than the one that matters.

curl -s https://example.com/some-page | grep -c 'rel="canonical"'
# 1

That 1 is true and useless. Google ignores canonical and hreflang found outside <head>
in the raw HTML. React moves the tag into the head on the client, so a browser never shows you
anything wrong either — open DevTools and it is sitting in <head>, exactly where you put it.

The question is not whether the tag is present. It is whether it appears before </head>.

import urllib.request

UA = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
req = urllib.request.Request("https://example.com/some-page", headers={"User-Agent": UA})
html = urllib.request.urlopen(req).read().decode("utf-8", "ignore")

head, canon = html.find("</head>"), html.find('rel="canonical"')
print(head, canon, "inside" if 0 <= canon < head else "OUTSIDE")

The cause is a design decision, not a bug

Next 15.2+ streams metadata by default. The shell flushes as soon as the page body is ready, and
whatever generateMetadata returns is injected later — after </head> has already gone out on
the wire.

Next knows some clients cannot cope with that, so it keeps an exception list of user agents that
get a blocking render instead. It lives in next/dist/shared/lib/router/utils/html-bots.js:

const HTML_LIMITED_BOT_UA_RE =
  /[\w-]+-Google|Google-[\w-]+|Chrome-Lighthouse|Slurp|DuckDuckBot|baiduspider|yandex|sogou|bitlybot|tumblr|vkShare|quora link preview|redditbot|ia_archiver|Bingbot|BingPreview|applebot|facebookexternalhit|facebookcatalog|Twitterbot|LinkedInBot|Slackbot|Discordbot|WhatsApp|SkypeUriPreview|Yeti|googleweblight/i;

Read the two Google patterns closely. [\w-]+-Google matches anything ending in -Google.
Google-[\w-]+ matches anything starting with Google-. Neither one matches the string
Googlebot.

Run it yourself:

const { HTML_LIMITED_BOT_UA_RE: re } =
  require('next/dist/shared/lib/router/utils/html-bots.js');

for (const ua of ['Googlebot', 'AdsBot-Google', 'Mediapartners-Google',
                  'Google-InspectionTool', 'Bingbot', 'Applebot']) {
  console.log(re.test(ua) ? 'blocking ' : 'streaming', ua);
}

Output on next@15.5.21:

streaming Googlebot
blocking  AdsBot-Google
blocking  Mediapartners-Google
blocking  Google-InspectionTool
blocking  Bingbot
blocking  Applebot

This is deliberate. The reasoning is that Googlebot executes JavaScript, so it will see the tag
after React relocates it — but only if the URL reaches the rendering queue, which is a second
pass and not guaranteed. The ad crawlers and the link-preview bots, which genuinely only read raw
HTML, are on the list.

The part that cost me the most time

Google-InspectionTool is the user agent behind URL Inspection in Search Console.

It matches Google-[\w-]+. It gets a blocking render. So the one tool you would naturally reach
for to verify the problem is served a complete, correct document — while plain Googlebot, the
thing that actually crawls you, is served the streamed one.

Bingbot is on the list too, so Bing Webmaster Tools looks healthy as well. Two independent
consoles agreeing that everything is fine is not confirmation here. They are both talking to the
blocking path.

It only happens sometimes, and only on some routes

This is what kept it hidden. Two conditions have to line up.

It is timing-dependent. Fetch a URL once, on its own, and the metadata almost always lands
inside <head> — the response is fast enough that the injection wins the race. It surfaces under
back-to-back load, which is what a crawler actually does to you. Measured across 116
/{provider}/{category} URLs fetched in sequence:

User agent	canonical outside `<head>`
Chrome	21 / 116
Googlebot	16 / 116
Bingbot	0 / 116

Bingbot's zero is the control: same URLs, same moment, blocking render, never broken.

It is dynamic routes only. Anything served from ISR replays a complete, already-assembled
document, so the streaming race never happens. The x-nextjs-cache response header tells you
which kind of route you are looking at:

$ curl -sI https://example.com/some-hub | grep -i x-nextjs-cache
x-nextjs-cache: STALE      <- replayed from cache, safe

$ curl -sI https://example.com/some-dynamic-page | grep -i x-nextjs-cache
                           <- no header, rendered per request, at risk

If everything you serve is statically generated or ISR-cached, none of this applies to you.

The fix

htmlLimitedBots in next.config.mjs lets you supply your own regex. One catch worth knowing:
it replaces Next's list rather than extending it. base-server.js reads
config.htmlLimitedBots || HTML_LIMITED_BOT_UA_RE_STRING, so writing /Googlebot/i there would
silently drop Bingbot, Applebot, Twitterbot and everything else.

Build it from Next's own source, so the list cannot go stale underneath you:

import { createRequire } from 'node:module';
const require_ = createRequire(import.meta.url);

const FALLBACK = '[\\w-]+-Google|Google-[\\w-]+|Chrome-Lighthouse|Slurp|DuckDuckBot';

let nextBots;
try {
  nextBots = require_('next/dist/shared/lib/router/utils/html-bots.js')
    .HTML_LIMITED_BOT_UA_RE.source;
} catch {
  nextBots = FALLBACK; // only if that internal path moves
}

export default {
  htmlLimitedBots: new RegExp(`Googlebot|${nextBots}`, 'i'),
};

After deploying, the same back-to-back measurement:

canonical outside <head>, Googlebot UA:  0 / 116

Re-checked ten days later on a dynamic route, ten parallel requests: </head> at 4,766,
canonical at 2,248, every single time.

Blocking costs nothing at this size. Median response with a Googlebot UA was 144–317ms.
Bingbot — already blocking, on the same URLs — was 129–222ms. Browsers keep streaming, because
Chrome does not match the pattern.

What this is not

It is an indexing signal, not a reachability one. Canonical outside <head> never stopped a
single crawl, and it explains nothing about crawl volume, coverage, or a page missing from the
index entirely. I checked whether it explained my own indexing gap before believing that it did,
and it did not — the pages I most wanted indexed were ISR-cached, so their canonical had been in
<head> the whole time.

What it does mean is narrower, and still worth fixing: on dynamic routes, some fraction of
Googlebot's fetches were told nothing about which URL is canonical or which language alternates
exist. On a site with one URL per thing, that fraction is a rounding error. On a site with ten
locales pointing at the same content, it is the entire signal.

The general lesson is one I keep relearning. When you verify a crawler-facing behaviour, send the
crawler's user agent, and check the thing's position, not its presence.

This came out of a project that crawls the docs of 15 AI vendors and records every change with
the date it happened: aichangewatch.com

My "Last Hour" Query Returned 1,252 Rows. The Real Answer Was 68.

ushiro — Fri, 11 Sep 2026 12:00:00 +0000

I run AI Change Watch, a small independent project that
crawls what 15 AI vendors publish about their own models — deprecation tables, lifecycle pages, pricing
and SDK releases — and records every time one of them changes.

Every so often I check whether the crawler is still alive by counting recent runs. The query is the
obvious one:

SELECT COUNT(*) FROM crawl_runs
WHERE started_at > datetime('now', '-1 hour');

It returned 1,252. The true number of runs in that hour was 68.

No error. No warning. A plausible-looking integer, roughly eighteen times too large, from a query that
reads correctly in review.

The two halves of the comparison are different formats

crawl_runs.started_at is written by application code, as ISO 8601:

2026-08-24T17:40:41.965Z

SQLite's datetime() returns its own format, which uses a space instead of T and has no
fractional part or zone suffix:

sqlite> SELECT datetime('now', '-1 hour');
2026-08-24 16:54:52

Both are strings. SQLite has no dedicated date type — dates are TEXT, REAL or INTEGER by convention —
so > here is a text comparison, byte by byte.

And that is where it goes wrong, at exactly one character:

position 11	value	byte
stored	`T`	`0x54`
cutoff	`' '`	`0x20`

T sorts above a space. So for every row whose date part is the same day as the cutoff, the
comparison stops at position 11, finds 0x54 > 0x20, and answers greater — no matter what time it
actually is. A run from 00:03 that morning is "in the last hour."

The fix is to make the cutoff the same shape as the column:

-- wrong: 1252 rows
WHERE started_at > datetime('now', '-1 hour')

-- right: 68 rows
WHERE started_at > strftime('%Y-%m-%dT%H:%M:%SZ', 'now', '-1 hour')

Why it survived so long

Because both of its failure modes are comfortable.

For freshness checks it fails loud. The number comes out too big, which means a stalled crawler
still looks busy. This is the dangerous direction — it is precisely the check whose whole job is to tell
you something stopped, and it is biased toward saying everything is fine.

For windowed audits it fails safe. -1 day or -7 day pulls in the entire boundary day, so a
review window is wider than you stated, never narrower. Nothing is missed; you just quietly reviewed
more than you meant to. Nobody notices being handed extra.

Neither shows up in the output. You do not get a type error, a coercion warning, or an empty result that
makes you look twice. You get rows, and they are real rows, and they are formatted like the ones you
wanted.

Where this bug actually lives

Here is the part I found most interesting once I went looking. My shipped code was never affected.

Nothing under src/ or web/ calls SQLite's datetime('now') or julianday('now') at all. Every
bound in the application is built in JavaScript:

const since = new Date(Date.now() - 86_400_000).toISOString();
// '2026-08-23T17:40:41.965Z'  — same shape as the column

Which emits the identical T/Z form, so the comparison is like-for-like everywhere it ships.

The bug lived entirely in hand-written operational queries — the ones I type into a console to
answer a question right now. That is the least-examined code in any project:

no test covers it
no reviewer reads it
it exists for ninety seconds and produces a number you then repeat to someone

Several "runs in the last hour" figures I had quoted before finding this were inflated by it. The
application was healthy the whole time; the instrument was wrong.

If you can't change the format on both sides

Two escape hatches, in the order I'd reach for them.

Normalise the cutoff, not the column. Rewriting stored data is a migration; rewriting a cutoff is a
line. strftime above is the clean version, but if you already have datetime() calls scattered through
a script, patching them in place also works:

WHERE started_at > replace(datetime('now', '-1 hour'), ' ', 'T') || 'Z'

I prefer strftime — it states the format it produces instead of repairing one — but this is fine when
you are editing twenty ad-hoc queries and want a mechanical change.

Or stop storing dates as text. SQLite has no date type; the documentation offers three conventions —
ISO-8601 TEXT, Julian day as REAL, and Unix epoch as INTEGER — and the whole class of bug in this post
only exists in the first one. Integers compare as numbers, so there is no format to disagree about:

WHERE started_at_ms > (unixepoch('now', '-1 hour') * 1000)

The trade is readability. 1787143241965 in a console tells you nothing, and every query you write by
hand now needs a conversion to be legible. For a table I mostly read by eye I kept the text column and
fixed the cutoffs. For one I only ever compared, I would not.

Worth knowing which trade you made, rather than discovering it at position 11 of a string.

How to find this in your own code

Grep for the mixed forms. If both of these return hits in the same project, you have the ingredients:

rg "datetime\('now'|julianday\('now'"     # SQL-side clocks
rg "toISOString\(\)"                      # JS-side timestamps

The bug is not either one. It's a comparison with one of each on opposite sides.

Cross-check any window with a grouping. This is the cheap, general test, and it needs no knowledge of
the storage format:

SELECT substr(started_at, 1, 13) AS hour, COUNT(*)
FROM crawl_runs
GROUP BY hour ORDER BY hour DESC LIMIT 5;

If the hourly buckets don't sum to what your windowed query claimed, the comparison is the reason. That
is how I found the 68.

Look at your columns before you compare them. One SELECT started_at FROM crawl_runs LIMIT 1 would
have shown me the T at any point in the preceding months.

The general form of this, which is not really about SQLite: a comparison between two values that were
produced by different systems is a format assumption, whether or not you wrote it down. Text
comparison will not tell you when the assumption is wrong. It will answer the question you literally
asked, in a shape indistinguishable from the answer you wanted.

Found 2026-08-24, fixed the same day. The tracker this came out of is at
aichangewatch.com — it records what AI vendors change in their
own docs, which involves a lot of timestamps that have to be comparable across sources.

"Application error: a client-side exception has occurred" Is a Stale Chunk 404

ushiro — Tue, 08 Sep 2026 12:00:00 +0000

For a while it would, occasionally, break in the browser after I shipped something. Not on load — on the
next click.

The symptom

You have the site open. You navigate — Home, a provider page, anything with a client transition. Instead
of the page you get a white screen and one line:

Application error: a client-side exception has occurred
(see the browser console for more information)

Reload and it's gone. Everything works. You can't reproduce it on demand.

Two properties make this genuinely hard to place:

It's intermittent. It hits some tabs and not others, some navigations and not others.
The message is deliberately empty. That string is React's production error boundary refusing to leak details. It is the same message for every uncaught render error, so it tells you nothing about which one you have.

The trap: the server is fine, and that misleads you

The first thing I did was look at the server. All of it was clean:

$ wrangler tail changewatch-web
... "exceptions": [] ... "exceptions": [] ... "exceptions": [] ...

Every request. And Home returned 200 across every filter, every provider, every page size I tried. No
500, no thrown exception, no failed render.

That reads as "the server is healthy, so the bug is in my component code" — and it sends you into the
one place the problem is not. It took me longer than it should have to state the actual reason the logs
were empty:

Worker logs never contain client exceptions. The error happened in the browser, after the response
was delivered and logged as a success. A clean server log is not evidence about the client. It's silence
about the client.

The one request that names it

Open DevTools, keep the Network tab open, and reproduce the navigation. You are looking for a 404 on a
/_next/static/... path:

GET /_next/static/chunks/app/[locale]/layout-4f2c9a1b8e.js   404

If it's there, you are done diagnosing. That is deployment skew, and the underlying error is a
ChunkLoadError — React caught it, and the boundary printed the generic line.

You can confirm it in the Console, which will have the real message that the page refused to show you:

ChunkLoadError: Loading chunk app/[locale]/layout failed.
(error: https://.../_next/static/chunks/app/[locale]/layout-4f2c9a1b8e.js)

Why a redeploy does this

Next.js splits your app into hashed chunks and loads them on demand. A page you open is not the whole
app — it's an HTML document plus the chunks needed so far. The chunks for a route you haven't visited
yet are fetched at the moment you navigate there.

The hash in a chunk's filename is derived from its contents. Change layout.tsx and
layout-4f2c9a1b8e.js becomes layout-91d0c73aa2.js.

Now put those two facts together with how static assets are hosted. On Workers Assets — and on most
static hosting, this is not Cloudflare-specific — only the current build's assets exist. Deploying
replaces the set. The old hashed filenames stop resolving.

So the sequence is:

A browser loads the site on build A. The document and the initial chunks are A's.
You deploy build B. A's chunk files are gone.
That still-open tab navigates. It requests the chunk name it learned from A.
404. ChunkLoadError. Generic error boundary.

Which explains both properties from the top. Intermittent, because it only affects tabs that were
loaded before the deploy and then navigated after it. Fixed by reload, because a reload fetches the
new document, which references B's chunk names.

It also explains why this feels like it's getting worse when you're actively working: during a session
where you deploy six times in an hour, every tab you left open is a candidate. At a normal release
cadence it only touches people who happened to have the site open across the deploy.

Two fixes, and they are not equivalent

Recover automatically. Add an error boundary that recognises this specific failure and reloads
instead of rendering the message:

// app/[locale]/error.tsx
'use client';

export default function Error({ error }: { error: Error }) {
  if (error.name === 'ChunkLoadError') {
    window.location.reload();
    return null;
  }
  return <p>Something went wrong.</p>;
}

This is the honest fix for a user-facing site: the reload is what the visitor would have done anyway, so
do it for them. The cost is that you have taken a class of error and made it invisible — if something
else ever produces a ChunkLoadError, you now have a silent reload loop instead of a report.

Keep old builds around. Some platforms let you retain previous deployments' static assets so old
chunk names keep resolving for a while. This removes the 404 rather than reacting to it, and it is
strictly better where it's available. It was not an option for me.

I went with neither, deliberately. My traffic is small, my deploys are frequent, and the failure costs a
reload — so I recorded what it was, in writing, and stopped investigating it. The expensive part of
this bug was never the impact. It was the three separate times I opened the wrong file looking for it.

The general shape

The thing I'd actually want to keep from this:

A generic error message plus a clean server log is a specific combination, not an absence of
information. It means the failure is downstream of your logs — in the browser, in the CDN, in the
network — and it should send you to a different tool, not to a closer reading of your components. I kept
re-reading the server side because that was the side I could see.

A hashed filename is a contract with a build that may no longer exist. Anything that caches, retries,
prefetches or holds a reference across a deploy is exposed to it. Long-lived tabs are just the most
common case.

Reproduce it before you fix it. You can trigger this on demand: open the site, deploy, then click a
link in the old tab without reloading. If it doesn't reproduce, you have a different problem, and the
error boundary above would have hidden it from you.

`No test suite found in file` on All 71 Files: Your `vite` Override Has No Upper Bound

ushiro — Fri, 04 Sep 2026 12:00:00 +0000

pnpm test had been ending like this for a while:

 ❯ test/analyzeChange.test.ts  (0 test)
 ❯ test/rowMapper.test.ts      (0 test)
 ... 69 more ...

 Test Files  no tests
      Tests  no tests

Every one of the 71 files printed No test suite found in file, and the run exited non-zero.

I read that as a config problem. It looks exactly like one: a bad include glob, a projects entry
pointing at the wrong directory, a environment mismatch — the kind of thing where the runner is fine
and your setup is wrong. So it sat there. Meanwhile the actual state was that 845 tests had not
executed once in that window, and nothing on the screen said so in those words.

The cause was a line I had written myself, for a good reason, four months earlier.

A security override with no upper bound

In pnpm-workspace.yaml:

overrides:
  # Security patch: dev-only vite advisories (fs.deny bypass / path traversal / launch-editor).
  # Force the patched vite that vitest transitively pulls. Not shipped to production.
  vite: ">=6.4.3"

I don't depend on vite directly. It arrives transitively under vitest. A batch of dev-only advisories
came out, the patched version was 6.4.3, and an override was the shortest way to guarantee every copy in
the tree was at or above it.

>=6.4.3 is not a pin. It is an open-ended range, and an override outranks whatever the dependent
declares. So when vite 8.1.4 shipped, pnpm resolved it — even though vitest 3.2.7 declares
^5 || ^6 || ^7.0.0-0, which does not include 8.

That is the part worth internalising: the peer range vitest publishes is exactly the guard that would
have stopped this, and overrides is the mechanism that tells the resolver to ignore it. I had opted
out of the safety check and left a note explaining why, and the note said nothing about the ceiling
because at the time there was nothing above.

Why vite 8 produced zero suites instead of an error

Vite 8 moved its transform pipeline to rolldown/oxc, and the module-runner contract changed with it.
Vitest loaded all 71 files without throwing, evaluated them, and got no registered suites back.

From the runner's point of view that is indistinguishable from a file with no describe/test in it —
so it reported the honest thing it could see, once per file:

No test suite found in file

There was one fingerprint of the real cause in the noise, and I had been scrolling past it:

The `esbuild` option is deprecated, please use `oxc` instead

That warning is vite 8 announcing itself. Nothing in the output ever named a version mismatch.

The fix is one character class

  # Capped below 8, and the missing cap is why the ENTIRE test suite was dead. This range had no upper
  # bound, so vite resolved to 8.1.4 while vitest 3.2.7 declares ^5||^6||^7.0.0-0. Vite 8 moved to
  # rolldown/oxc and changed the module-runner contract: vitest loaded all 71 test files, got no suites
  # back, and reported "No test suite found in file" for every one of them. `vitest run` then exits
  # non-zero with "Tests: no tests" — which reads like a config problem, not like 71 silently unrun
  # files, and it stayed unnoticed. Nothing else in either workspace depends on vite (`pnpm why vite`
  # lists only vitest, vite-node and @vitest/mocker), so the cap costs nothing. Raise it when vitest
  # supports vite 8.
  vite: ">=6.4.3 <8"

Before adding a cap, check who is actually asking for the package:

$ pnpm why vite
  vitest
  vite-node
  @vitest/mocker

Only the test runner. Nothing in either workspace consumes vite at build time or ships it to
production, so constraining it has no blast radius. If the answer had included the framework or the
bundler, the cap would have been a real decision instead of a free one.

vite dropped to 7.3.6. All 71 files collected. 845 tests, all passing.

Then one of them failed

Not a regression from the dead window — the suite came back clean on everything that had been touched
while it was down. The failure was older than that, and it was real.

lifecycleColumns() reads the extracted facts for a deprecation event and turns them into database
columns. It handled the shutdown date and the successor model:

for (const f of facts) {
  const after = typeof f.after === 'string' ? f.after : undefined;
  if (!after) continue;
  if (f.kind === 'date' && / shutdown$/.test(f.label)) {
    if (!shutdownAt || after < shutdownAt) shutdownAt = after;
  } else if (f.kind === 'model' && / successor$/.test(f.label) && !successor) {
    successor = after;
  }
}

There is no branch for the deprecated date. So events.announced_at was NULL — not for some rows,
for every row ever written.

That column is the start of the notice period. Without it you cannot compute how much warning a vendor
actually gave before switching a model off, which for a site whose entire subject is model lifecycles is
not a cosmetic gap.

The test that catches it already existed, and had existed the whole time. Its name is
shutdown date, successor and announcement date, and thirty lines up it verifies the occurredAt value
'2025-06-10T00:00:00.000Z' — the vendor's own "deprecated on" column. The extraction was there. The
assertion was there. Only the mapping to a database column was missing, and the one process that would
have said so was returning no tests.

The fix is the missing branch:

} else if (f.kind === 'date' && / deprecated$/.test(f.label)) {
  // Earliest, for the same reason as shutdownAt: on a batch announcement the notice period a reader
  // is actually inside is the one that started first.
  if (!deprecatedAt || after < deprecatedAt) deprecatedAt = after;
}

The second guard was also down

While fixing that I ran the type checker, which I had not done in a while either:

$ pnpm run typecheck
$ echo $?
2

rowMapper.ts line 98 was reading a deprecatedAt field off the return value of a function whose
declared return type did not have one. It could not compile. CI was in the same state.

So both automated checks on this repository were failing, in two different ways, and neither of them was
loud enough to interrupt anyone. One said no tests and looked like configuration. The other exited 2 in
a step nobody was reading.

What I changed afterwards

A security override needs an upper bound too. The reason you write one is that you know better than
the resolver about a specific lower edge. That knowledge does not extend upward. >=x published today
is a bet on every major version that ships after you stop paying attention.

no tests is a failure state, not a neutral one. A run that collects zero suites should be treated
the same as a run that fails, because the information content is identical: you do not know whether your
code works. It exits non-zero already; the gap was in my reading, not in the tool.

Check the peer range before overriding. vitest 3.2.7 → ^5 || ^6 || ^7.0.0-0 was a two-second lookup
that would have told me exactly where the ceiling belonged.

The existing announced_at values are still NULL. Backfilling them needs a re-parse of the archived
page snapshots, which is a separate job. The column is populated correctly going forward.

I write these up while building AI Change Watch, which crawls
LLM vendor documentation and records every deprecation, shutdown date and price change with the date it
happened.

A `middleware.ts` Rewrite Silently Disables ISR in Next.js 15.5

ushiro — Tue, 01 Sep 2026 12:00:00 +0000

Every page on my site declared export const revalidate = 300. Nine locales served from ISR.
The tenth — the one that is actually canonical, the one crawlers hit most — re-rendered from scratch
on every single request for weeks.

The difference between them was not a page, a config flag, or a deployment. It was that the tenth
locale's URL went through a NextResponse.rewrite() in middleware.ts.

I run AI Change Watch, a Next.js App Router site on Cloudflare
Workers (via OpenNext) that crawls what AI vendors publish about their own models and records every
change. en is served unprefixed (/deprecations), the other nine locales are prefixed
(/ja/deprecations). That unprefixed mapping was one line of middleware.

What the headers said

Measured on production, 2026-08-06. Same page, same component tree, same revalidate = 300 — only
the routing path differs:

/bot, /rankings                (rewritten in middleware)
  Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
  (no x-nextjs-* headers at all)

/ja/bot, /ja/rankings          (passed through with next())
  Cache-Control: s-maxage=300, stale-while-revalidate=...
  x-nextjs-prerender: 1

private, no-store on a page whose whole point is to be cached. And not "cached badly" — there are
no x-nextjs-* headers on those responses whatsoever, which means Next never treated the request as
a route that has an incremental cache entry. Nothing was written, so nothing could ever be read.

Why this hides so well

Three things kept this invisible for weeks, and I think each one is general.

The prefixed locales are fine. Any "is my ISR working?" check you run against /ja/... passes.
The bug is per-path, and it only touches the paths middleware rewrote.

Probing the prefixed form of the broken URL measures nothing. /en/bot 307-redirects to the
canonical /bot (verified again today), so curl -I /en/bot returns a redirect and tells you
nothing about the page. You have to test the unprefixed URL. I burned an eight-minute polling
loop on /en/bot before noticing that.

Pages still refresh, so content never looks stale. Deploys change the buildId, the buildId is part
of the cache key space, and this repo deploys several times a day — so the whole cache was being
invalidated often enough that no page was ever visibly out of date. revalidate = 300 was decorative,
and deployment frequency was covering for it. (There was a second, independent reason revalidation
never ran on this stack; that one is
its own post.)

The cause

This is vercel/next.js#83862 — "SWR Cache-Control
disabled after Next.js 15.5 when using a rewrite middleware", open, filed 2025-09-16, reported
against 15.4.2-canary.2 through 15.5.3. I reproduce it on 15.5.21.

The explanation in the issue is that Next matches the pre-rewrite path against the
dynamic-route regexes. /bot matches nothing (the real route is app/[locale]/[provider]/page.tsx),
so the response falls back to the private, no-store default. That mechanism is upstream's account
and the internals are not something I can observe from outside; what I can state is the header pair
above, and that it flips based solely on whether the rewrite happened in middleware.

The important consequence is that it is a write-side failure, not a read-side one. No entry is
ever created for those keys. So nothing that improves cache lookup can help.

Two things that did not fix it

Rewriting the rewrite. There is no shape of NextResponse.rewrite() that avoids this. It is not
a matcher problem or an ordering problem.

Serving ISR from the adapter's routing layer (OpenNext's enableCacheInterception: true) looked
like the perfect workaround: resolve the cache before NextServer is ever invoked, and the pre-rewrite
path matching stops mattering. Cache hits did work — I have x-opennext-cache: HIT on prefixed
locales to prove it. It still could not fix English, because the cache was empty for those keys, and
then it took the site down:

Error in routingHandler
  at Object.send (worker.js:116290)     at computeCacheControl (worker.js:120329)
  at generateResult (worker.js:120394)  at cacheInterceptor (worker.js:121493)

On a stale entry the interceptor has to dispatch the background re-render itself, and at that
point I had no revalidation queue bound. Inside NextServer that same failure is caught and logged as
a warning. In the routing layer it wasn't caught, so the request returned 500. Two properties made it
much worse than an ordinary bug: it threw before the render, so the entry could never refresh and
the 500 was permanent per URL; and it only fired once an entry passed its revalidate window, so
pages died one at a time over several hours — 12 URLs before I reverted it.

If you take one thing from this post, take that shape: a failure that is caught in one layer and
uncaught in the layer you moved it to.

The fix

Move the rewrite out of middleware and into next.config.mjs. A config rewrite lands in the routes
manifest, which the adapter's routing layer applies to the internal request, so NextServer receives a
plain /en/... request with no x-middleware-rewrite header — the exact path /ja/... always took.

async rewrites() {
  const reserved = 'en|ja|zh|es|de|fr|ko|pt|it|tr|api|_next|sitemaps';
  return {
    afterFiles: [
      { source: '/', destination: '/en' },
      { source: `/:seg((?!(?:${reserved})(?:/|$))[^/]+)`, destination: '/en/:seg' },
      { source: `/:seg((?!(?:${reserved})(?:/|$))[^/]+)/:rest*`, destination: '/en/:seg/:rest*' },
    ],
  };
}

Middleware keeps the /en/... → /... redirect. Redirects are unaffected; only rewrites are.

afterFiles, not beforeFiles. afterFiles runs only when no real route matched, so
/sitemap.xml, /robots.txt, /icon.svg and friends resolve as themselves before this pattern is
consulted, and drop out of the exclusion list for free. With beforeFiles every one of them needs an
explicit exclusion, and each missing exclusion is a 404 on a canonical URL.

The exclusion regex has two traps

Both of these produce a config that builds fine and 404s in production.

Trap 1: anchor each alternative to a segment boundary. The negative lookahead has to end with
(?:/|$), not $. With $ alone it only fires when the reserved word ends the path:

                 $ only                    (?:/|$)
/bot          -> /en/bot                 -> /en/bot
/ja/bot       -> /en/ja/bot   ← 404      -> (no rewrite)  ✓
/en/bot       -> /en/en/bot   ← 404      -> (no rewrite)  ✓
/api/contact  -> /en/api/contact ← 404   -> (no rewrite)  ✓
/sitemaps/1   -> /en/sitemaps/1 ← 404    -> (no rewrite)  ✓

That table is RegExp.exec output, not a sketch. It is also the same family of bug as writing bare
api in a matcher, which swallows /api-features — a page of mine that 404'd on its canonical URL
for exactly that reason.

Trap 2: root-level dynamic routes are not protected. The "real routes win first" property of
afterFiles is gated on the adapter's static route matcher. /sitemaps/[id] is root-level and
dynamic, so it is not covered, and it has to be named in reserved by hand. If you add a root-level
dynamic route later, it needs the same entry — there is nothing to remind you.

How to check it, in the order that actually works

1. Test the compiled regex, not the source string. What runs is the pattern Next compiles into
.next/routes-manifest.json, and it is not what you typed. Build to a scratch directory
(NEXT_DIST_DIR=.next-rwtest next build), read the manifest, and assert every URL class you care
about — locale-prefixed, /en/-prefixed, /api/*, /_next/*, root-level files, root-level dynamic
routes, the feeds. All four shadowing bugs above were caught this way before deploying, and none of
them was visible in the source.

2. Then check the unprefixed URL on production. Today, on the same pages, 2026-08-27:

$ curl -sI https://aichangewatch.com/bot | grep -i 'cache\|nextjs'
Cache-Control: s-maxage=3600, stale-while-revalidate=31532400
x-nextjs-cache: STALE
x-nextjs-prerender: 1
x-nextjs-stale-time: 300

$ curl -sI https://aichangewatch.com/deprecations | grep -i 'nextjs'
x-nextjs-cache: HIT
x-nextjs-prerender: 1

x-nextjs-prerender: 1 is the header that was absent before, and it is the one to look for.
x-nextjs-cache: MISS on its own proves nothing — that is the earlier post's subject.

What I still haven't proven

Whether this reproduces off this adapter. Every measurement here is Next 15.5.21 + @opennextjs/cloudflare on Cloudflare Workers. The upstream issue is not adapter-specific and the reporters were not on my stack, but I have not tested Vercel or a plain next start myself.
Why the no-store fallback is chosen. I am quoting the issue's explanation of the path matching, not something I read out of the runtime.
The 500 attribution. That the interceptor threw at Object.send before the render is read off the stack trace and the fact that the 500s stopped on revert. I did not instrument it.

If you serve a default locale unprefixed on App Router, the check is one command and the failing case
looks completely healthy: full-SSR responses are correct, just uncached. Test the URL your users get,
not the internal one.

The site this came out of is AI Change Watch — vendor deprecation
tables, pricing and SDK changelogs, diffed on a schedule. The pages in the measurements above are
real ones; /deprecations is the one with the highest cache-hit value, which is why it was the first
thing I noticed serving no-store.

The iCalendar Spec Says 75 Octets, Not 75 Characters

ushiro — Thu, 27 Aug 2026 12:00:00 +0000

One of the things it publishes is a subscribable calendar: every announced model shutdown, as .ics,
so a date the vendor moves updates in your calendar instead of in a changelog you forgot to read.

The English feed worked immediately. The Japanese one was rejected.

Same code. Same events. The only difference was the language of the text inside.

The line that RFC 5545 actually specifies

Section 3.1:

Lines of text SHOULD NOT be longer than 75 octets, excluding the line break.

Not 75 characters. 75 octets.

For ASCII those are the same number, which is exactly why this survives every test you are likely to
write. SUMMARY:gpt-4-32k shutdown (OpenAI) is 36 characters and 36 bytes. Nothing to notice.

Then the same field comes back translated:

SUMMARY:code-davinci-001 提供終了（OpenAI）

That is 30 characters. It is 49 octets — Japanese runs about 3 bytes per character in UTF-8. A
folder that counts characters looks at 30, decides no fold is needed, and emits a line that is legal by
its own arithmetic and illegal by the spec's.

Longer titles cross 75 octets while still well under 75 characters, and that is the line the parser
rejects.

Why counting characters isn't the only bug

The obvious fix — count bytes instead — introduces a second one if you write it the obvious way.

// Still broken.
const bytes = Buffer.from(line, 'utf8');
for (let i = 0; i < bytes.length; i += 75) {
  out.push(bytes.subarray(i, i + 75).toString('utf8'));
}

Slicing a UTF-8 buffer at a fixed offset cuts through the middle of a character. Byte 75 lands in
the second of the three bytes that make up 終, and you emit half a codepoint on one line and the other
half on the next. Some parsers replace it with U+FFFD, some abort the file.

So the fold has to be counted in bytes but taken at character boundaries:

export function foldLine(line) {
  const enc = new TextEncoder();
  if (enc.encode(line).length <= 75) return line;

  const out = [];
  let cur = '', curBytes = 0;
  // The first line gets 75 octets; every continuation gets 74, because the leading
  // space that marks it as a continuation counts toward the limit too.
  let limit = 75;

  for (const ch of line) {          // iterating a string yields whole codepoints
    const n = enc.encode(ch).length;
    if (curBytes + n > limit) {
      out.push(cur);
      cur = ''; curBytes = 0; limit = 74;
    }
    cur += ch;
    curBytes += n;
  }
  if (cur) out.push(cur);

  return out.map((l, i) => (i === 0 ? l : ` ${l}`)).join('\r\n');
}

Three things in there are easy to leave out and each one produces a file that mostly works:

for (const ch of line), not line[i]. Indexing a JS string walks UTF-16 code units, so an emoji
or any astral-plane character gets split at the surrogate pair. Iterating with for...of yields whole
codepoints.

The limit drops from 75 to 74 after the first line. The continuation marker is a single leading
space and it counts. Keep the limit at 75 and every folded line is one octet over — which is the same
bug you just fixed, only harder to see because it only shows up on lines long enough to fold.

\r\n, not \n. RFC 5545 wants CRLF. Plenty of parsers tolerate bare LF, right up until one
doesn't.

The other one: your UID is not a display string

An .ics feed served in ten languages raises a question the spec answers but does not warn you about:
what is the UID?

If you build it from the localized summary, the same shutdown gets a different UID in every language.
Subscribe to two of them and your calendar shows two entries for one event, forever, with no way to
tell they are the same thing.

So the UID has to be keyed on the entity, never the presentation:

UID:shutdown-o1-preview@aichangewatch.com
UID:shutdown-davinci-002@aichangewatch.com

Model slug, no locale. I checked the two live feeds while writing this:

en feed:  262 UIDs
ja feed:  262 UIDs
shared:   262            ← identical sets

Which means a person subscribed to both gets one entry per shutdown, not two. The second subscription
overwrites the first rather than duplicating it. That is the correct failure mode — a collision beats
a double-booking, because a duplicate calendar entry is something the user has to notice and clean up by
hand.

It also means you cannot use the UID to carry the language. If you need that, it belongs in the calendar
name (X-WR-CALNAME), not the identity.

What I check now

The whole class is "a spec said octets and I read characters", and it is worth one assertion in a test
rather than a careful reading:

const body = renderCalendar(events);
for (const line of body.split('\r\n')) {
  expect(Buffer.byteLength(line, 'utf8')).toBeLessThanOrEqual(75);
}

Run it against the localized feed, not the English one. The English feed cannot fail this test,
which is precisely why it is not the one to run it on. Mine currently reports:

en feed:  6,545 lines,   0 over 75 octets,  506 continuation lines
ja feed:  6,606 lines,   0 over 75 octets,  567 continuation lines

The 61 extra lines in the Japanese feed are the folds the English one does not need. That gap is the
bug, made visible: same events, same code, more lines — because the same sentences take more bytes.

The tracker this came out of is at aichangewatch.com — the
shutdown calendar it generates is at
/deprecations/calendar.ics.

DEV Community: ushiro

33 Things in Three Vendors' OpenAPI Specs Existed for Exactly One Day

Fourteen of them landed on a single afternoon

And some land on endpoints you actually call

What this does and does not mean

What I would actually do about it

Notes on the numbers

I Published a Median Model Lifespan. Seven Weeks Later the Same Query Said 219 Days More.

528, 290, 74

The median is a fact about vendors, not about models

The longest life in the set is a join across two vendors

What is actually solid here

What I would actually do about it

What this measures

8 of the 26 Codes Behind HTTP 429 Are Not Rate Limits. Backoff Will Never Clear Them.

The vendors say so themselves

The same condition is a 402 at four other vendors

Anthropic puts both meanings on one code

Two more that aren't what they look like

What the 26 actually split into

What I would actually do about it

What this does and does not measure

A Vendor Deleted a Shutdown Date and Nothing Told Anyone. So I Counted the Next 90 Days.

The next 90 days

Read those two columns as a pair

The column I refuse to fill in

The ones that can't be counted at all

What I would actually do about it

A Model Google Lists as Shut Down Answered Me Today. Read `modelVersion` Before You Trust It.

One field says what actually happened

Before you generalise this — two things that are NOT the story

Why the narrow version still matters

Nobody has said how long this lasts

What to actually do

My CLS Was 0 Until I Throttled the Network. Then It Was 0.11.

Why an unthrottled measurement reads zero

The selector

Where that bet loses

The fix is to move the decision earlier

The rule I took from it

Two things worth keeping

Search Console Shows Your Canonical Tag. Googlebot Never Gets It.

Why grep can't see this

The cause is a design decision, not a bug

The part that cost me the most time

It only happens sometimes, and only on some routes

The fix

What this is not

My "Last Hour" Query Returned 1,252 Rows. The Real Answer Was 68.

The two halves of the comparison are different formats

Why it survived so long

Where this bug actually lives

If you can't change the format on both sides

How to find this in your own code

"Application error: a client-side exception has occurred" Is a Stale Chunk 404

The symptom

The trap: the server is fine, and that misleads you

The one request that names it

Why a redeploy does this

Two fixes, and they are not equivalent

The general shape

`No test suite found in file` on All 71 Files: Your `vite` Override Has No Upper Bound

A security override with no upper bound

Why vite 8 produced zero suites instead of an error

The fix is one character class

Then one of them failed

The second guard was also down

What I changed afterwards

A `middleware.ts` Rewrite Silently Disables ISR in Next.js 15.5

What the headers said

Why this hides so well

The cause

Two things that did not fix it

The fix

The exclusion regex has two traps

How to check it, in the order that actually works

What I still haven't proven

The iCalendar Spec Says 75 Octets, Not 75 Characters

The line that RFC 5545 actually specifies

Why counting characters isn't the only bug

Why `grep` can't see this