Imagine your international marketing team commissions a recurring service from a China-based content partner. Each month, an AI workflow turns approved product material into localized campaign scripts. Then its underlying model becomes unavailable. The prompts and project records still exist, but the next batch cannot run.
For a retainer, archiving the work is only part of the purchase. ONCE recommends explicitly assigning responsibility for dependency changes, replacement acceptance and a usable delivery route when the original path stops working.
A dated signal with a defined scope
Anthropic's September 30, 2026 release note announced deprecation of Claude Sonnet 4.5, with retirement on the Claude API scheduled for November 30. Its model deprecations documentation, checked October 31, still lists that plan. Deprecated means it remains functional; requests to a retired model fail.
The documentation distinguishes Anthropic-operated platforms from partner-operated routes, including Amazon Bedrock, whose schedules can differ. Ask the supplier which platform it actually uses before applying a date.
This establishes a migration requirement for a particular service, not an industry-wide retirement timetable. Its commercial lesson is broader: keeping the files does not preserve an external dependency indefinitely.
Handover records do not guarantee the next production run
Prompts, selected outputs, source materials and project records help another team understand the work. A recurring service must also explain what will execute the next task.
A replacement returning text is not sufficient acceptance. Possible checks include missing product conditions, changed model names in translation, or output fields that a downstream publishing system cannot read. These are evaluation scenarios, not incidents observed in an ONCE customer project.
Here a language model may support writing, research organization or task planning. This announcement does not establish a shutdown of video-generation tools, and a vendor-recommended replacement is not automatically the best performer on a brand's own tasks.
The ONCE dependency, replacement and continuity framework
Make each dependency identifiable
Ask the supplier to record the actual platform, model identifier, invocation route, relevant configuration, input version, output purpose and owner. This record should not contain account secrets or publish confidential product material. If an upstream service conceals its model choice, agree who is responsible for change notification, compatibility maintenance and incident explanation.
Map a label such as “script generation” to a concrete step: which approved product pack enters, who reviews the result, and which system receives it. A change may affect one supporting step rather than the entire monthly service.
Accept a replacement on brand tasks
Use permitted historical tasks with complete inputs and approved requirements. Include routine work and difficult cases. Specify product identifiers, necessary conditions, prohibited claims and required structure before reviewing new results.
Where feasible, run both paths and assess each against those requirements. Keep content acceptance separate from workflow compatibility: facts, voice and localization on one side; fields, files and downstream handoffs on the other. After acceptance, start with an agreed limited switch and observe it. This article reports no executed migration experiment or vendor certification.
Plan for continuity beyond the old endpoint
Before retirement, restoring the earlier configuration may remain a temporary option. After retirement, rolling back configuration cannot make the retired model available again. A fallback needs to be a checked route that is still available, or a defined manual process using approved templates and a revised delivery plan.
Record which tasks can continue, which need additional review and which must pause. Failure of the primary route is not permission to send confidential inputs to an unapproved alternative service.
Price maintenance as visible work
Separate regular content production, dependency maintenance and migration checks, and redesign outside the agreed scope. Define notification ownership, review cadence, included work and how larger changes will be estimated. There is no universal rate or sensible assumption that every future upgrade is free.
A vendor's notice period is also not the same as the supplier's migration work allowance. Impact review, testing and client approval need time. Set the internal cutover date by working backward from the applicable retirement, rather than waiting to change a model name on the final day.
Request one continuity demonstration
Choose a low-risk content task. Ask the supplier to demonstrate how it identifies a dependency change, evaluates a replacement and continues when the original path is simulated as unavailable. Use approved materials and an agreed environment; disrupting live production is unnecessary.
The deliverable is an actionable record of the current dependency, accepted alternative, approval conditions, owner and next review. Link it to the content asset by task identifier. ONCE's AI content guidance can support that supplier brief.
For long-term managed services, the enduring assets are approved product facts, acceptance rules, task examples and migration records. Models can change while the brand's requirements and the partner's delivery responsibilities remain explicit.
