What happens to a request after a model is withdrawn
Three entries publish what a request meets once a model has gone. Two hosting platforms return an error: the request fails, and moving to another model is the customer's job. One application refuses a click on a retired tier before anything is held, and falls saved choices back to a tier that is still offered. From 4 source pages, read 2026-09-22 to 2026-10-13; no maker pays to be listed.
| Entry | What is published | Detail |
|---|---|---|
| Amazon Bedrock | Requests to a model past its end-of-life date fail | Migration will not happen automatically |
| Microsoft Foundry | All inference requests return 410 Gone | Retirement dates are not extendable |
| SceneMixer | A click on a retired tier is refused before anything is held | Saved choices fall back; video to the episode's last-used tier |
Inclusion rule. Entries whose pages state what a request receives after a model is withdrawn. An entry that publishes an end date without saying what a late request meets is not given a row. Order. Alphabetical by entry.
1An error is right for a developer, a fallback for a production
A platform that serves named model versions to developers has good reason to fail loudly. A pinned version that quietly became another would be worse than an outage, and an error code is the honest signal that a deployment needs editing. One platform states the code; another states that requests fail and that migration will not happen automatically.
An application selling tiers to a production team faces a different trade. Its customers pick a tier once and forget it, and an episode half generated when a tier goes is the case to plan for. One application publishes its rule: text and image work falls back to the default tier, and video to the tier the episode last used if that is still listed.
2A fallback is only honest if the price follows it
Falling back silently could mean paying one tier's price for another tier's output. The same guide closes that gap: the price on the generate button is computed from the tier that will actually run, after any fallback, and nothing is charged by the fallback itself.
A click made on a page left open while a tier was retired is refused with a message and nothing is held, which is the application's version of an error code.
3Gone and unavailable are handled differently
A tier that is only temporarily unavailable is hidden from the list rather than offered and then refused, so the choice a user can make is always one that will run. A tier withdrawn for good disappears from the list and triggers the fallback. Keeping the two cases apart is what stops a short outage from rewriting a project's saved choices.
- What happens at end-of-lifeAfter the end-of-life date the model is removed from all AWS Regions and requests made to it fail
- Whether the platform moves you acrossMigration will not happen automatically
- What the endpoint does after the retirement dateAll inference requests return 410 Gone
- Whether a date can be pushed back on requestRetirement dates are not extendable
- A request on a retired tierA segment submitted on a retired tier is refused with a message before anything is held, and the selector no longer lists that tier
- Work in progress when a tier goesWhen a tier is withdrawn, text and image work falls back to the default tier and video to the tier the episode last used if it is still listed, otherwise the default; the price shown is the tier that will run
4Sources
Dates come from the company that makes the model or the platform that serves it; menus come from the app, and both are linked on the calendar. Read 2026-10-13. What counts as a date is on sourcing. Nearby: Finished work, How much notice, Your stored work.