dimhold.by
← Writing

Claude 5.5 says its knowledge ends in June 2026. It got no package release from March 2026 right

Every time a coding model tells me which version of a library to install, I trust one date without thinking about it: its knowledge cutoff. For the Claude 5.5 models the vendor states June 2026 and the models repeat it when asked. I wanted to see what that month means in practice, so I asked 7 Claude models about package releases whose dates I could check. The 5.5 generation here is Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1, all stated as June 2026.

A clock that nobody wrote from memory

Package registries are a good clock. npm and PyPI record when each version was published, to the second. I took 100 popular packages, half from each registry. From every package I kept the first stable release of each minor line. From those I drew 12 releases per month from January 2023 to October 2026, 552 in total.

For each release the model had to say whether it knows that this version came out and if so, in which month. “I do not know” was allowed. An answer counts as correct when the month is at most 1 off from the registry.

A model that says yes to everything would look very knowledgeable on such a test. So I mixed in 200 versions that do not exist, the next major and the next minor after the latest release of each package. The 4 models of the 5.5 generation claimed to know at most 3 of them in 400 answers each.

Before the first call I wrote down the rule for the measured cutoff. I also wrote down what I expected: a gap of at least 2 months from the stated date. I expected the models to name an earlier date for themselves too.

Where the curve goes down

share of 24 answers correct, by month the release came out 0% 50% 100% 2024-07 2025-01 2025-07 2026-01 2026-07 stated cutoff Opus 5.5 Sonnet 5.5, Haiku 5.5, Fable 5.1
12 releases per month, 2 repeats, so 24 answers per point. Correct means the model knows the release and names the month within 1.

Up to the middle of 2025 the 5.5 models get almost every release right. Then the curve goes down. For Opus 5.5 it is 22 of 24 in January 2025, 17 in June, 11 in August, 3 in December and 0 from February 2026 on.

My rule takes the last month where the 3 month rolling share is still at least half of the 2024 level. For the 4 models that month falls between September and December 2025, which is 6 to 9 months before June 2026. From March 2026 none of them gets a single release right.

The fall is gradual. For Opus 5.5 the way from 90% of its 2024 level down to 10% takes 9 months, for Sonnet 5.5 it takes 4. The older Opus 5 is stated a month earlier than Opus 5.5 and measures at October 2025, a month later. The newer model does not know further on this battery.

What the model says about itself

Then I asked the models directly, in 6 different wordings. Inside Claude Code the 5.5 models answered June 2026 in 63 of 70 answers.

Claude Code is how I ran all the calls and it adds its own system prompt. Haiku 5.5 quoted that prompt back to me. Next to the model name there is a line “Assistant knowledge cutoff is June 2026.”

3 dates per model, month axis 2025-01 2025-07 2026-01 2026-06 Opus 5.5 18 of 18 Sonnet 5.5 18 of 19 Haiku 5.5 12 of 13 Fable 5.1 15 of 20 measured said in Claude Code told the line may be wrong
Filled dot: measured cutoff. Square: June 2026, with how many self reports inside Claude Code named it. Rings: answers under the leading wording, larger for more answers.

The answers match that line. That the line causes them I cannot say. I captured the context for 1 model of 7 and never ran a condition without the line. A model that knows its own name may also know its official date.

I added one more wording during the run. It said the line was inserted by the client software and may be wrong. Under it every answer of the 5.5 models fell between January and September 2025, before each model’s own curve. That wording is leading, so I read it as a hint and not as a measurement.

I was not first

Before the run I searched for prior work and found Dated Data from 2024. It showed on open models that the effective cutoff differs from the stated one. My search did not really reach arXiv, because the API throttled me after 5 requests.

At review 2 days later I found what I had missed. LLMLagBench (2025) put the vendor date, the model’s own date and a measured date side by side for 35 models. HindsightBench (2026) found black box effective cutoffs up to 8 months before the vendor date, for 5 of the 7 models where one is published. So the gap is known and my registration claimed more novelty than was left.

What this run adds is narrow. Neither study covers the Claude 5.5 models. Mine uses package releases dated by the registry, has the control of versions that do not exist and asks for the self report the way Claude Code delivers it. LLMLagBench saw older Claude models name a date earlier than the vendor’s. Inside Claude Code the 5.5 models name the vendor date.

There are limits. This is popular packages and not knowledge in general. Questions went in batches of 20 through a subscription, so I did not control the sampling settings.

For a package version from February 2026 on, the model’s silence tells me nothing about whether the version exists. Asking the model about its cutoff inside Claude Code gives me the vendor’s date back.

The full write up with all tables is on the paper page. The battery, the harness and the journal of every call are in the repository.