LLMSwaps

Which model each app runs today, and when it last changed

Watching a page that has no changelog

Most entries in this register publish nothing dated, so a model leaving a menu is the whole event and no page records it. Two readings of the same page, each with the day it was read, are the only evidence such a change happened. That makes the reading the work. As of 2026-09-12.

What to capture on each reading, and why. Recorded 2026-09-12.
CaptureWhat it lets you say later
The model names listedThat a name was there, and then was not
The version strings, where givenWhether a rename or a version change happened
The rate, credit conversion or tierWhether a repricing was mistaken for a retirement
The day you read itRoughly when the change happened
A copy of the page, not a summaryThat your own note was not the thing that changed

Inclusion rule. What a reading has to contain to be usable as evidence of an unannounced change. Order. From the fact being tracked to the metadata that makes it checkable.

1A summary is not a reading

Writing down that a page listed four models is enough to notice a count change and not enough to say which name went. Keeping the names, the versions and the numbers is what makes the comparison meaningful.

Keeping the page itself is better still, because it removes the possibility that your own shorthand was the thing that changed between readings.

A summary is not a readingNoting that a page listed four models is enough to notice a count change and not enough to say which name went. Keeping the names, the versions and the numbers is what makes the comparison mean anything.ReadCapture names,versions, rates andthe day you readthem.A month laterRead againThe same page, thesame fields, the samelevel of detail.CompareA dated intervalA change somewherebetween two days. Donot narrow itfurther.Monthly narrows any change to a month, which is enough to decide about a blockOn pages selling credits, record the conversion too: a repricing and a retirement lookalike.
Fig. 1 Keeping the page itself removes the possibility that your own shorthand was the thing that changed.

2Record the price alongside the model

On pages that sell credits, a change to what a credit buys and a change to which models exist look similar. Recording only the names makes a repricing look like a retirement and the reverse.

Both matter and they matter to different people. A budget cares about the first; a season cares about the second.

3Monthly is usually enough

The purpose is to date a change to within a useful window, not to catch it on the day. A monthly reading narrows any change to a month, which is enough to decide whether a block of episodes straddles it.

More frequent reading buys precision nobody uses. Less frequent reading leaves a gap large enough that a season sits inside it.

4The reading date is not the change date

Two readings with different values show a change somewhere in between, and narrowing it further would be guessing. Say what was read and when, and leave the interval as an interval.

That is exactly the discipline this register applies to its own rows, which is why the data file carries a reading date on every line.

5Where each vendor's own wording lives

None of the above is a date. Announced end dates, and the apps still carrying the models they apply to, are kept on the calendar with the announcement each one came from.

  • Reading date — why every row in this register carries one
  • Sourcing — what counts as a published statement here, and what does not

Guidance rather than a dated entry. No line here is a vendor statement, and none should be read as an announcement. The sourced material is on the calendar. Related: Before committing a season, Pinning a version.