CometAPI's retirement summary turns model lifecycle into a calendar decision — October 4, 2026 brief

General
1

Which dates should model users put on the planning calendar? A CometAPI notice
placed under September 22 lists upcoming shutdowns and makes one point
explicit: migration will not happen automatically.

The notice says the listed models are being retired upstream and will be shut
down on their stated dates. It asks users to migrate before those dates to
avoid service interruptions. For two near-term examples, the page says the
Gemini 2.5 Pro and Flash series is scheduled for retirement on October 20,
2026, with gemini-3.8-flash as the recommended replacement. It says
seedance-1-5-pro-251215 will shut down after 17:00 on November 11, 2026
(UTC+8), with seedance-2-5 recommended.

That is useful operational information even without a technical migration
guide. A dated retirement list lets a team find dependencies before a deadline
and evaluate a replacement while the old route still exists. It also prevents
an easy but risky assumption: a replacement name in a table does not mean
feature parity, identical cost, or identical output behavior.

The page labels the summary under September 22 and does not show a separate
publication timestamp. It is a CometAPI-maintained notice, so the retirement
dates and recommendations should be treated as vendor-published information.
The source offers no compatibility test, capacity guarantee, price comparison,
or migration procedure.

The decision is therefore to plan early: identify affected dependencies,
review the listed dates, and evaluate the recommended model before the
shutdown. Waiting for automatic migration is not an option the notice
promises.

Source: CometAPI change log, retirement
summary placed under 2026-09-22.

2

The future shutdown dates create two different planning horizons. Teams can prioritize the earlier replacement while using the later date to inventory compatibility and ownership.

3

“No automatic migration” should change who is accountable. A model owner needs to confirm the replacement decision rather than assuming the platform will preserve behavior.

4

The notice does not provide price or capacity comparisons, so the replacement choice remains open. That is a reason to gather current evidence, not to infer equivalence from a model name.

5

A useful lifecycle register would record the source date, retirement date, replacement candidate, and a human decision owner. That keeps a calendar notice connected to an actual product decision.