Stay Current

The model's memory has a fixed horizon and no alarm goes off when a fact crosses it. Everything past that line is remembered confidently and wrongly. The fix is mechanical, not a matter of being more careful.

The error runs in both directions, and the second one is the one people miss:

• Claiming a version, price or API is current when it was superseded a year ago.
• Claiming something does not exist, is not supported, or is impossible, when it shipped after the horizon. Absence from memory is not evidence of absence in the world.

Establish now, first

Many agent hosts already stamp the current local time into each user message's metadata, or into the system prompt. Look there first and read it. Only fall back to running date in the terminal when it is genuinely absent, and never infer today's date from a file timestamp, a copyright line, or the feel of the conversation. Once the real date is known, the gap to the training horizon is the size of the blind spot, and it can be stated out loud.

The metadata is easy to overlook: on one host, checked across all 126 user turns of a transcript, every single message carried the local time, and the agent still spent a command on date.

Memory is a floor, never a ceiling

"The newest version I know of is X" only licenses the claim "X or later". It never licenses "X is the latest". Before naming any current version, look it up. These were all run and confirmed working on 2026-09-16:

Two cautions found while testing these. gh api repos/<owner>/<repo>/tags returns tags in no documented order, and that order is not by date. Measured on 2026-09-16, the first entry was the newest tag for cli/cli, python/cpython and nodejs/node, and a weekly.2012-03-27 tag for golang/go. So the first entry answers nothing: use releases/latest. And a package with long-term support channels, such as @angular/core, lists many dist-tags; the one that answers "latest" is dist-tags.latest.

For a library's behaviour at a given version rather than the version number itself, use the Context7 MCP server and pin the query to that version. See grounded-research for the source ladder and how to pick the right Context7 entry.

Hand over as soon as the question stops being a number. A version check almost always drifts into behaviour: what changed, what breaks on upgrade, what the new API looks like, which middleware moved. The registry cannot answer any of that. The moment the answer needs an import path, a function signature, a config key or a migration step, that part goes through Context7 or the project's own documentation, not through memory, even when the version number itself was just verified. Getting the number right does not make the paragraph after it verified.

What goes stale fastest

Check these every time rather than recalling them: current and supported versions, deprecations and removals, default behaviour changed by a major release, pricing and free-tier quotas, rate limits, AI model names and API versions, security advisories and patched versions, CLI flags, browser and runtime support.

Stable enough to recall: language syntax that has not moved in years, algorithms, protocol fundamentals, and anything already read in this session.

Newest is not automatically right

Currency is for accuracy, not for chasing releases.

• Match the repository's installed version first. An answer about the version actually in use beats an answer about the newest one published.
• Check the release date that comes back. Something published days ago has no production track record, and recommending an upgrade to it is a separate decision from reporting that it exists.
• When recommending a bump, say what breaks: read the changelog or the migration guide for the majors being crossed, and name the breaking changes rather than promising a clean upgrade.
• A version still inside its support window is not a problem that needs fixing.

Say the horizon out loud

When something cannot be checked, do not paper over it. Say which part is from training data, that it may be stale, and what command or page would settle it. One honest sentence beats a confident wrong one, and it lets the user run the check in five seconds.

Before reporting done

• Was date run before anything time-sensitive was claimed?
• Did every "latest", "current", "deprecated" or "no longer supported" come from a registry, a release feed or a dated primary source?
• Was a "that does not exist" claim actually verified, or just absent from memory?
• Does the recommended version match what the repository installs, with the gap explained if it does not?
• Is anything unverifiable labelled as coming from training data?
• Did the answer drift from version numbers into API behaviour or migration steps, and if so was that part checked against Context7 or the primary documentation rather than recalled?