llm-knowledge-cutoff-dates: A Markdown Table of When Each Model Stops Learning

The question this repository answers, and who is asking it

Knowledge cut-off dates are the boundary past which a language model has no training data. The repository exists to collect those boundaries in one place for GPT, Claude, Gemini, Llama, Qwen, DeepSeek, Microsoft, xAI, and Xiaomi models, plus a section for models whose vendor is not identified. The README frames the project as a curated summary and states that the dates come from official technical reports, API documentation, GitHub issues, and other public resources. That framing tells you the intended audience: someone who needs a specific date and is willing to click through to confirm it. The list is not aimed at benchmark researchers or at anyone building a training pipeline. It is aimed at the engineer or writer who has to answer whether a given model could know about an event, a library release, or a specification change. The table-of-contents structure, split by vendor, matches that lookup behaviour. You scan for the vendor, scan for the model, read the date. Nothing about the repository suggests it wants to be consumed any other way.

How the data is organised: vendor tables, dated variants, and Web Archive links

The README is a set of Markdown tables, one per vendor, with four columns: Model Name, Company, Cut-off, and Source. Model names include variant identifiers where the vendor distinguishes them, for example GPT-4 (1106-preview), GPT-4-turbo (2024-04-09), and GPT-4o (2024-08-06). That granularity matters because the same base model can have different cut-offs depending on the snapshot. In the OpenAI table, GPT-4o (2024-05-13) and GPT-4o (2024-08-06) both list 2023.10, while GPT-4.1 lists 2024.06.01 and o3 lists 2024.06.01. The dates appear in two formats: some are month-level (2023.10), some are day-level (2023.09.30). The README does not explain that inconsistency, and it is worth noting because a month-level value cannot be compared precisely against an event that happened mid-month. The News section records that in 2026.03 all source URLs were replaced with Web Archive links to prevent link rot. That is a deliberate archival choice, and it means a source link resolves to a snapshot rather than to a live vendor page. The trade-off is real: the snapshot cannot drift, but it also cannot reflect a vendor correcting its own documentation after the snapshot was taken.

Reading the table without installing anything

There is no package, no CLI, and no build step described in the material. You consume the repository by opening the README on the default branch, main, and reading the table. If you want a local copy, the standard Git operations apply: git clone the repository, then open README.md in an editor or render it. Because the content is Markdown, any table-aware renderer will display it, and any text search over the file will find a model name. The practical workflow is: search for the model string, read the Cut-off column, then follow the Source link to the archived page and confirm the date is stated there. There are no config keys, no environment variables, and no API surface to describe, because the repository does not expose one. If the material had included a data file, a schema, or a generator script, that would change the adoption story considerably. It does not. Treat the README as the artefact and the Git history as the changelog.

Where the list is thin: source quality and unverifiable rows

The README states that contributions should be backed by trustworthy and verifiable sources, and the News entries repeat that request. The table itself does not always meet that bar. GPT-1, GPT-2, and GPT-3 all point to a single archived article on computercity.com rather than to a vendor technical report. That is a secondary source standing in for a primary one, and it is the oldest part of the table, which is also the part least likely to be corrected by a vendor. Several OpenAI rows share one archived Microsoft Azure documentation URL, which means a single page is the evidence for GPT-3.5, GPT-4, several GPT-4 previews, GPT-4o variants, and the o1 preview models. If that page changes or is misread, many rows move together. The README also carries an asterisk on GPT-3.5 and GPT-4 without explaining what the asterisk denotes. That is a documentation gap inside the repository itself, and it is the kind of thing you should resolve before quoting those two rows. The Unknown Models section exists, which is honest, but it also means the list is not exhaustive and does not claim to be.

What this repository is not: a machine-readable dataset

The most common wrong-tool case is treating this as a data source for code. There is no JSON, CSV, or YAML file in the supplied material, no schema, and no versioning scheme for the dates themselves. A script that scrapes the README would be parsing Markdown tables whose column formats and date formats are not uniform, and whose content changes when a contributor edits the file. For a runtime check, that is fragile. The alternative approach is to read the cut-off from the vendor's own model documentation at the point of use, which is what the archived links point back to anyway. The difference in approach is direct versus indirect: this repository gives you a human-curated index with provenance links, while a direct vendor lookup gives you a single authoritative page with no aggregation layer in between. The repository wins on breadth, because one page covers many vendors. The vendor page wins on freshness and on being the thing the repository is citing. If your use case is a one-off question, the repository is faster. If your use case is a scheduled job, the repository is the wrong shape.

Maintenance, licence, and what the repository does not tell you

The material does not state a licence. It also does not state the primary language, and no releases were retrieved. Those three omissions shape adoption. Without a licence, you cannot assume the table may be redistributed inside a commercial product, and the safe reading is that the default copyright position applies until the repository states otherwise. This is not legal advice; it is a statement that the licence field is empty in the supplied material and should be confirmed on the repository page before reuse. Maintenance looks light but real: the News section shows updates in 2025.6, 2025.12, and 2026.03, and the last push is dated 2026-05-04. The 2026.03 change was a bulk rewrite of source URLs, which is the kind of edit that can silently break individual rows if a snapshot was chosen poorly. Upgrading means pulling the latest README, and the cost of that is low. The cost of trusting a stale clone is higher, because a model released after your clone will simply be absent, and an absent row looks the same as a model with no published cut-off. Neither the README nor the News entries describe a review process for accepting corrections, so the accuracy of any single row rests on the contributor who added it and the source they cited.

Who should adopt this, who should not, and the first thing to check

Adopt it if you need a quick, human-readable index across vendors and you are willing to click the source link before relying on a date. It is a reasonable starting point for documentation writers, support engineers answering questions about model recency, and anyone comparing cut-offs across families such as Qwen, DeepSeek, and Llama in one view. Do not adopt it as an automated dependency, and do not adopt it if you need a licence you can rely on, because none is stated in the material. The first thing to verify is the specific row you care about: open its Source link, confirm the archived page actually states that cut-off, and check whether the date is month-level or day-level. The second thing to verify is the repository's licence on its own page, since the supplied material does not record one. If both checks pass for your use case, the table does what it claims.

Editorial conclusion

Use this repository when a human needs to look up one model's stated cut-off and follow the link to the original documentation, and skip it if you need a versioned data file for an automated pipeline. Do not adopt it without first checking the licence, which the supplied material does not state, and without verifying that the specific row you need points to a primary source rather than a secondary article.

Official sources

1. HaoooWang/llm-knowledge-cutoff-dates on GitHub
2. Issues
3. README