A months-old Grok update showed up today as “newly added.” Its entries carry no date.
The tool-updates page decides what is new not by date but by “have we run this title before?” Grok and Perplexity, though, give their entries no date at all, only a month heading. So on September 3, Grok items from January and March went up as “newly added”: old news dressed as the latest because we were seeing it for the first time.
This is not a news summary. It is a record of something that happened while building this site.
Every morning we gather tool release notes and pin them next to that day's briefing. We scan what ChatGPT, Claude, Grok and the rest have shipped. On September 3, Grok's video generation feature showed up on that list as “newly added.” Grok opened video generation back in January of that year.
With no date, we sort by “is this new to us?”
We pull release notes from ten places, and the formats have nothing in common, so we cannot select by date. Half of them carry no per-item date. Grok and Perplexity are worse still: their entries carry no date at all, only a month heading like “## September.”
So we do not ask “did this ship today?” We ask “have we run this before?” It is the same approach that shows up in another note here: to avoid running the same entry twice, we identify it by title.
The trouble is that being new to us is not the same as being recent. If a month-old section's entry passes the filter late for any reason, it goes up as the latest simply because we are seeing it for the first time.
A January item, newest in September
Two items actually went up on September 3. Both were Grok, and neither was from this year.
| Headline | Month on the badge | When it really shipped |
|---|---|---|
| Grok Adds Video Generation and a Revamped Image Generator | January | January 2026 |
| Grok 4.20 and Grok 4.20 Multi-Agent Go Live | March | March 2026 |
The version badge showed only the year-less English month, “January,” so even when it shipped was ambiguous. A reader seeing “January” has no way to tell whether it means this January or some other.
Reading the month as a date
The fix is plain. We read the month label (September, December 2025) into a year-month and store it as the item's date. A month with no year is taken as this year, unless that month is still ahead of the current month, in which case it belongs to last year. That keeps an early-year month from looking like the future at year's end.
September -> 2026-09 (no year, so this year)
December 2025 -> 2025-12 (year is spelled out, so use it)
January -> 2026-01 (no year, so this year)Once an item has a date, anything older than two months from the current month drops out of the candidate pool. The January and March items no longer even enter it. This month plus the two before it get through.
The old items already published got backfilled
For English month versions already stored in past sources, we backfilled the date. Only the ones that read as a month and had an empty date field are touched, so a second regeneration changes nothing. The two Grok items that had gone out in error were removed from the September 3 source.
What I am taking from it
This repo has a sibling note: the same five updates going out two days in a row. That one was the same entry seen as different, so it duplicated. This one is an old entry with no date resurfacing as the newest. Opposite directions, one root: what you use to decide identity.
As long as “new” means only “new to us,” a dateless source will keep sending the old back as the new. So where there is no date, we make one, even from a month heading. We did not invent information that was not there; we turned “September” into something we can compare against.