What belongs in the index
A record must describe a concrete, developer-facing change to a supported AI platform. Examples include a model shutdown, API sunset, rejected request parameter, changed default, or migration behavior likely to affect production code.
Each published record should identify the provider and API surface, the exact model IDs, endpoints, SDK symbols, or parameters affected, an observable symptom, and a practical next action. General product announcements and speculative roadmap coverage are excluded.
Evidence standard
Core facts must be supported by a primary provider source such as an official deprecation notice, API reference, release note, or migration guide. Secondary reporting can help surface a change, but it is not sufficient evidence for a record.
Official sources are linked on every change page. Provider documentation remains authoritative if it conflicts with this index. AI tools may assist with drafting or formatting, but their output is never treated as a source.
What is automated
Scheduled Cloudflare jobs poll a fixed allowlist of official documentation across 12 model providers, cloud platforms, and inference platforms. Conditional requests and content hashes prevent unchanged pages from being processed again. Separate jobs extract candidate changes, verify evidence, recheck upcoming deadlines, publish a cached registry snapshot, and report source-health failures.
Dedicated lifecycle ledgers are monitored directly. For release-note-only platforms, an entry must explicitly describe a deprecation, retirement, breaking behavior, or required migration before it can become a candidate. Workers AI can turn a changed platform page into structured candidate fields, but it cannot choose a source URL or publish a claim by itself. Automatic publication requires the platform date, affected identifiers, replacement identifiers, and quoted evidence to appear in the captured official source. Candidates that fail those deterministic checks remain unpublished.
How dates are recorded
The registry keeps separate fields for release, announcement, effective, and shutdown dates. A shutdown date means the provider has named a date when access is expected to end. An effective date means the documented behavior applies from that date.
Dates are stored as calendar dates exactly as published. A time or timezone is not inferred when the provider does not supply one, so teams should complete migrations before the displayed day rather than treating it as a precise cutoff instant.
How the compatibility checker works
The checker searches the bundled Change Radar registry for model IDs, endpoints, request fields, SDK symbols, symptoms, and curated search phrases. Matching happens in your browser; text pasted into the checker is not uploaded or stored by the application.
A match is a pointer to a relevant record, not a scan of your repository and not proof that an integration is safe. No match only means the current registry did not recognize the text.
Migration guidance
Fixes favor the smallest source-backed action: replace the exact identifier, remove the rejected field, or move to the provider’s documented successor API. Before-and-after snippets illustrate the relevant request-shape change; they are not a substitute for testing against your SDK version, account configuration, and workload.
Treat the provider source as the contract and the Change Radar record as a fast, structured map to it.
Verification and updates
Every record carries a visible “verified” date. The audited fallback registry was last checked on July 26, 2026; automated records carry their own source-check date. A verification date means the linked official documentation passed the evidence checks on that day. It does not mean the provider cannot change the schedule later.
If two later source observations no longer contain the saved evidence, the record remains available for history but changes to “source recheck required.” Its status-change date is exposed to search engines and feed readers separately from the last successful verification date.
Machine-readable versions of the same records are available as a JSON Feed and RSS feed.
Current limitations
- The index is intentionally selective and is not a complete list of every platform, model, region, account tier, or SDK.
- Change Radar does not continuously call provider APIs to test availability, error codes, or account-specific behavior.
- Providers can revise deadlines and migration advice after a record has been verified.
- Migration examples are illustrative. Validate them in staging and consult the linked provider documentation before production changes.