Additions are not improvements

Half of a changelog is a model being added

135 of our 285 entries are model-list changes. Of the entries we record as improvements, most are a model arriving on a plan that already had models.

That is real news for someone choosing between two plans this week. For a subscriber with a working setup it is a line on a page, because a roster only changes your month if you change what you run on it.

The economics explain the volume. A provider that resells model access can add a name to a table the week a model ships, with no infrastructure of its own. Removals take the same effort and produce complaints, so they are written carefully, dated late, or left to be discovered. We log additions one by one because each is checkable; a policy rewrite is a single entry no matter how many clauses it touches.

The volume makes the feed feel busy. It also hides the entries that are not about breadth, in the same way a busy street hides one closed door.

Additions are the easy thing to publish

Adding a model costs a provider a line in a table. The other direction costs a customer a workflow, which is why it tends to arrive with less fanfare and more ambiguity.

We see the asymmetry in the record. The improvements cluster in additions, and most entries that made a plan worse were a subtraction: something left a roster, a cap came down, a plan was withdrawn, a policy gained a prohibition.

Some of those subtractions are not the provider's decision. When a lab retires a model, every plan that served it drops the name in the same week, and the provider has nothing to announce except the loss.

Policy entries are the exception on that side. A prohibition has to be published to be enforceable, so the one subtraction providers announce loudly is the one written by their lawyers.

So the two halves of a changelog are not equally informative. One describes what the plan could do if you switched. The other describes what it stopped doing while you were not looking.

Your usage is the missing column

No changelog knows which models you route work to, so it cannot tell you which entries matter. That filter has to come from you, and writing it down takes five minutes.

The same page can be good news and bad news at once. A plan adds a flagship you will never select and drops the cheap model your agent runs all day. Read without your own list, the entry reads as an improvement. Most readers can name their two main models and forget the third, which is usually the one an agent has been using unattended for a month.

That reader wanted the table gone. We kept it, because the per-model rates are the only part of the page that lets you compare plans on equal footing. What the table cannot do is tell you which row you will actually spend the month on.

A reader who knows which models they use can answer that in a minute.

A quiet changelog is not a stable product

Providers publish unevenly. One keeps a release-notes page, another posts from a social account, another edits a table without a word. Our record inherits that silence, so a provider with few entries is not more stable than one with many. A provider that never publishes anything leaves us with nothing to read, and we would rather say so than score the silence.

That is the honest limit of reading changelogs. They measure announcements, and stability is what happens between them. The only reliable test is the one you run against your own usage.

It is also why we do not score providers by how often they change. A high count can mean a company shipping, or a company documenting what it ships. Our ledger cannot tell those apart, and neither can a reader counting entries.

Filter the feed by what you use

Three questions cover almost everything, and none of them need the whole feed:

• List the models you actually run. Scan new entries for those names and let the rest pass.
• Compare the cap figure and the refill window with what you saved last quarter. Those two numbers are the plan.
• When a policy entry appears, read it once for a new prohibition, then stop reading policy entries.

Check the providers named here

We do not rank plans here. Open the records and read the verified figures yourself.