Model Changelog
The model changed — hear it from the product, not from your broken outputs
Model updates land silently: the same saved prompt starts answering differently overnight, and users discover the swap through degraded outputs, not through the product. Model Changelog announces the change where the work happens — what improved, what behaves differently, scoped to what you actually do — with a before/after diff on your own pinned prompts instead of version arithmetic. HAX guidelines 14 and 18 (update cautiously, notify about changes) have named this obligation since 2019; almost nothing ships it.
Framing
The problem
Model updates land silently — the same saved prompt answers differently overnight, and users discover the swap through degraded outputs, not through the product.
The pattern
Announce the change in-product, scoped to behavior: what improved, what moved, with a before/after diff on the user's own pinned prompts and a control over when it takes effect.
Why chat breaks here
Chat has no surface for "the system under this box changed last night" — same input, different distribution, zero notice.
Risks
Changelog fatigue — if every minor bump interrupts, users dismiss all notices; scope announcements to behavioral change, not version arithmetic.
Avoid when
The user pins model versions themselves (versioned API snapshots) — the notice belongs where change is imposed, not chosen.
Use when
Users build workflows on model behavior that changes underneath them, and silent updates cost them trust or output quality.
DOPE evaluation
- Directability
- Acknowledge, snooze, or re-run your checks — the user controls when the new behavior enters their workflow where the platform allows it
- Observability
- The update is announced in-product with behavior-scoped notes, not buried in a blog post the user never sees
- Predictability
- A before/after diff on the user's own pinned prompts shows how the change lands on their work, before it surprises them
- Explainability
- Each notice names what category of behavior moved and why, instead of a bare version number
In the wild
- ChatGPT · Release notes (OpenAI) — A running in-help changelog of model and feature changes — the notice half of the pattern. Behavior-scoped diffs on your own prompts remain unshipped anywhere.
- Anthropic · Model release notes + system cards (Anthropic) — Versioned release notes plus system cards documenting behavioral characteristics per model — the most behavior-scoped public change documentation in the industry, but it lives in docs, not in-product.
- Cursor · Changelog (Cursor) — Names model swaps and behavior changes per release, surfaced to developers who treat the tool as infrastructure. In-product update notes appear on version bumps.
FAQ
When should I use the Model Changelog pattern?
Users build workflows on model behavior that changes underneath them, and silent updates cost them trust or output quality.
When should I avoid the Model Changelog pattern?
The user pins model versions themselves (versioned API snapshots) — the notice belongs where change is imposed, not chosen.
What problem does Model Changelog solve?
Model updates land silently — the same saved prompt answers differently overnight, and users discover the swap through degraded outputs, not through the product.
Why is chat the wrong fit for this?
Chat has no surface for "the system under this box changed last night" — same input, different distribution, zero notice.
Related patterns
- Often paired with: Capability Boundary — The boundary declares what the system can do; the changelog announces when that declaration moves.
- Often paired with: Model Selector — Choosing a model is only meaningful if you hear when it changes underneath you.
- Alternative to: Seed Pinning — Pin the seed to freeze the randomness you can control — the changelog covers the change you cannot pin: the model itself.