Llama 3's Knowledge Cutoff Date, Model by Model

Meta publishes a training-data cutoff in the model card of every Llama release. They are not all the same, they are not all what the prompt template says, and one release has two different cutoffs for its two sizes.

The documented cutoffs

Each figure below is the one stated in the model card for that release, maintained by Meta in the meta-llama/llama-models repository. The release dates are Meta’s own announcement dates.

release        sizes                    announced    documented cutoff
-------------  -----------------------  -----------  ------------------
Llama 3        8B                       Apr 2024     March 2023
Llama 3        70B                      Apr 2024     December 2023
Llama 3.1      8B, 70B, 405B            Jul 2024     December 2023
Llama 3.2      1B, 3B, 11B, 90B         Sep 2024     December 2023
Llama 3.3      70B                      Dec 2024     December 2023
Llama 4        Scout, Maverick          Apr 2025     August 2024

The gap between the two right-hand columns is itself informative. Every row shows several months between the end of the training data and the public release — time spent on the remaining training stages, on evaluation and on safety work. That gap is structural rather than incidental, which is why no model is ever current at launch, and why a model released this year can be a year and a half behind on facts. It is also why “use the newest model” is not the same advice as “use the model with the most recent knowledge”.

Why Llama 3’s two sizes differ

The April 2024 release is the only one in the table with two answers, and the reason is that the two models were not trained on the same corpus snapshot. The 8B card gives March 2023 and the 70B card gives December 2023. Nine months of world events therefore exist for one member of a family and not the other, which is a trap for anyone who benchmarked on the 70B and then deployed the 8B to save money: the smaller model is not merely less capable on recent topics, it is missing them.

Llama 3.1 unified the family on December 2023, and every release since has quoted a single date for all its sizes. If you are still on the original Llama 3, the split is the strongest single argument for moving to 3.1 — which is a drop-in change of weights with the same prompt format and a much larger context window.

The date line in the prompt is not the cutoff

Llama 3.1’s documented prompt format includes a header line in the system message:

Cutting Knowledge Date: December 2023
Today Date: 11 August 2026

People read that line out of a chat template and report it as the model’s cutoff. It is not evidence of anything. It is a string the template writes into the prompt, and in the templates shipped with several releases it is a literal — it says December 2023 because somebody typed December 2023, not because the runtime inspected the weights. A fine-tune of Llama 3.1 trained on 2025 data will still emit that line, and a Llama 3.2 checkpoint carries it forward from its parent template.

The line does have a real function, and it is worth keeping: it tells the model that it has a boundary and roughly where, which is what makes it say “I may not have information after…” instead of confabulating, and what makes it reach for search when the built-in tools are enabled. Keeping Today Date accurate is the more useful half — a model told the wrong date does arithmetic about elapsed time wrong.

A cutoff is a boundary, not a wall

The mechanism is worth being precise about, because it explains two opposite complaints. Training data was collected up to a date; the model’s weights encode what was frequent in that corpus. Nothing enforces the boundary at inference time.

So on one side, coverage thins out well before the stated date. Events from the last few months before the cutoff are under-represented, because the internet had not finished writing about them when the crawl stopped. A model with a December 2023 cutoff is noticeably weaker on November 2023 than on 2021.

And on the other side, the model will happily answer about events after the cutoff — by producing the most probable continuation, which is a confident invention. There is no internal “I have not seen this” signal to consult. That is why retrieval exists, and why a question whose answer changes over time should never be served from weights alone regardless of how recent the cutoff is.

Why asking the model does not work

The obvious experiment — ask the model when its training data ends — is the least reliable method available, for three separate reasons, and it is worth understanding why before you trust an answer it gives you.

• It is reading the prompt, not introspecting. If the system message contains a Cutting Knowledge Date line, the model is repeating that line back to you. The experiment measures your template.
• Without that line, it is guessing from training data. A model has no representation of its own training window. What it has is text about model cutoffs written by other people, which is why models frequently state a date belonging to an earlier model entirely.
• Fine-tuning overwrites the answer without changing the knowledge. A derivative trained on a few thousand conversations can learn to claim any cutoff its trainer wrote into the data.

Probing by fact is better but still imprecise. Ask about events at known dates and the boundary shows up as a gradient rather than a line — solid on things from a year before the cutoff, hazy in the final few months, confidently wrong after it. That gradient is real information about the model, and it is exactly why the stated date is a description of the crawl rather than a guarantee of coverage.

The reliable method remains the boring one: read the model card for the exact repository you are loading, and for a fine-tune, read the parent model’s card and then ask the fine-tune’s author what they trained on. With open weights that provenance chain is at least visible, which is more than a hosted endpoint usually offers.

Handling it in an application

• Put today’s date in the system prompt, computed. Not typed. A hardcoded date is wrong from the day after you write it.
• State the boundary explicitly. Telling the model its own cutoff in the system message is what gives it the option of declining rather than guessing.
• Route time-sensitive questions to retrieval. The cutoff bounds what the weights know; it says nothing about what you can put in the context.
• Re-check the cutoff when you change the model. This is the one that gets missed, because a model swap is usually evaluated on capability rather than on recency.
• Write the cutoff into your own configuration. Not because the model needs it twice, but because the value is then a thing your code knows: a document-freshness check, a “consult retrieval for anything after this date” rule and a log line all become possible once the date is a constant rather than a fact somebody remembers.