How the record is made

Modelmeter is a record, and records live or die on trust. This page explains exactly how entries are detected, verified, labeled, and corrected — and what we deliberately do not claim.

Sources: first-party only

Every recorded value traces to an authoritative source: a provider's own deprecation page, changelog, pricing page, migration guide, or filing — or, for market-context events, primary reporting. We never record values inferred by a model, recalled from memory, or copied from another aggregator. Operational events carry a verbatim quote from the source at capture time and, wherever possible, an archive.org snapshot — because providers edit their own changelogs.

Detection: watch, diff, classify

Provider documentation surfaces (deprecation pages, changelogs, model lists, pricing pages — 16 surfaces and growing) are fetched and diffed daily. Unchanged pages cost nothing and produce nothing. When a page changes, the change is confirmed by a second fetch (to reject unstable renders), mechanically diffed, classified, and drafted as a structured event with its quote. Historical depth was built the same way from archived pages, hand-verified.

The verification lifecycle

• unverified — drafted by the pipeline, published fast, honestly labeled. Consume with that caveat; the API lets you filter it out (/events?status=verified).
• verified — a human confirmed the headline, dates, and sources against the cited page. 100% of operational (breaking / action-required) events are verified.
• corrected — superseded. Corrections are never silent: a correction event points at what it replaces, and the original stays in the record for the audit trail.

Severity is a strict taxonomy: breaking (something you use is removed or renamed), action_required (the terms of continued use change — price, rate limits, context), informational (market context: releases, funding, partnerships). The dashboard's default feed shows operational events; industry news is a toggle away and never presented as verified operational fact.

What "silent model swap" means here

Only ever a documented behavior: a provider's own page stating that a retired model ID redirects to a different model (for example, xAI's migration guide: retired Grok slugs "automatically redirect to grok-4.3… priced differently"). We record what providers publish and diff what they edit. Claims about undocumented behavioral drift — "the model feels different" — are out of scope by policy: we do not run behavioral fingerprinting, and we will not publish a swap claim without a source you can click.

Platform schedules are independent facts

Amazon Bedrock, Azure AI Foundry, and Vertex AI set their own retirement schedules, which differ from the model maker's. The record keeps them platform-scoped (amazon/…, microsoft/…) because a Bedrock deployment needs Bedrock's date — the same model can have three different sunset dates depending on where you run it.

Honest uncertainty

When a provider publishes no announcement date, the event says so explicitly in its summary and uses the best documented bound (earliest archive capture, or the effective date) rather than an invented one. Missing values stay null. Every pricing entry carries last_verified and its source URL — judge freshness from those, not from vibes.

Machine-audited, in public

Every change to the dataset must pass a public integrity audit in CI: cross-dataset reference resolution, timeline sanity, source rules (aggregator links are banned), duplicate guards, price-anomaly detection, and text-integrity checks. If the audit fails, the change cannot merge. You can run it yourself: npm run check.

Consume it

/check · /deprecations · /events · RSS · OpenAPI · llms.txt · MCP at modelmeter.xyz/mcp (registry: xyz.modelmeter/modelmeter) · GitHub Action that fails CI before your model does.

Found an error? Open an issue — corrections are part of the record, not an embarrassment to it.