Recovering after the model changes
A swap changes how prompts are interpreted, how references are weighted, and often the default look. Rewriting prompts first is the instinct and the slowest route; establishing what actually moved comes first. As of 2026-09-12.
| Step | Why first |
|---|---|
| 1. Confirm a swap happened | The change may be a preset, not a model |
| 2. Re-run a fixed test set | Shows what moved, and by how much |
| 3. Rebuild references | Reference weighting often changed |
| 4. Adjust prompts | Tuning before step 3 has to be redone |
| 5. Re-measure cost | The attempt ratio moves in either direction |
Inclusion rule. Steps in the order that avoids repeating work. Order. Recovery order.
1Confirm a swap happened
Output looking different is weak evidence on its own. Check whether the product announced a change, whether a version identifier moved, and whether colleagues on the same account see it too. Sometimes the change is a filter or a preset rather than a model.
Starting the recovery before confirming what moved is how teams spend a week rewriting prompts to fix a resolution default.
2Re-run a fixed test set, not new prompts
Keep four or five prompts that have produced known output, with their references, as a standing test. Running those after any suspected change shows what moved and by how much, in a way that new prompts cannot.
A test set is cheap to keep and almost never kept. Its value is entirely in being unchanged, so resist improving the prompts in it.
3Separate a look change from an instruction change
Two different things break after a swap: the default aesthetic shifts, or the model follows instructions differently. The first is fixed by adjusting style wording; the second by restructuring how the prompt is written.
Telling them apart is what the test set is for. A model that produces the right content with a different grade has a different problem from one that ignores a structural instruction.
4Re-establish the references before the prompts
Where references are used, their weighting is frequently what changed. Regenerating the reference images themselves under the new model, then testing against those, often recovers more than any prompt edit.
This is also the order that avoids compounding: prompts tuned against references that are themselves about to be replaced have to be tuned twice.
5Do not mix versions inside one deliverable
An episode or a campaign generated half under each version will read as inconsistent regardless of how good both halves are. Finish the current unit on what you have, then move the whole next unit.
Where a retirement forces the move mid-unit, regenerating the earlier shots under the new version is usually cheaper than living with the seam, and it should be decided rather than discovered.
6Re-measure the cost
A new version changes the attempt ratio in either direction, and the rate per second may have changed with it. A budget built on the old ratio is a guess until it has been re-measured on real work.
Ten shots is usually enough to know whether the number moved materially. It is a cheap measurement compared with discovering the answer at the end of a production.
7Write down what the new baseline is
Once the look is recovered, record the settings, the reference set and the phrasing that produced it, dated. This becomes the thing the next swap is measured against, and the test set is refreshed from it.
Without that record every swap starts from nothing, and the cost of each one is the same as the first.
8Check whether the old version is still reachable
A swap in the default is not always a retirement. Some products keep the previous model selectable for a period, which turns an emergency into a scheduled migration and lets a unit in progress finish on what it started with.
This is worth checking before any recovery work, because it changes the deadline from today to whenever the older option goes away.
9Tell whoever is downstream
Editors, clients and reviewers notice a change in look and read it as a mistake unless told otherwise. A one-line note saying the model changed on a date, and that earlier material was produced under the previous one, prevents a round of corrections that cannot be made.
It also sets expectations for the first deliveries after the swap, which are the ones most likely to need another pass.
10What this site can and cannot tell you
The calendar records which product named which model, and when that changed according to published notices. It does not evaluate the models and it does not say whether a swap improved anything.
What it is for is answering the first question in the list above — did something actually change — with a dated entry rather than an impression.
11Where 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.
- Sourcing — how entries here are dated, and what counts as an announcement
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: Surviving a retirement, Deprecation words.