Model deprecation policy
This page sets out the commitments Syntic proposes to make when a model is replaced. The current status of each model is on Deprecations.
Stages
| Stage | What happens | Minimum duration |
|---|---|---|
| Active | Fully supported and recommended. | Until deprecation is announced. |
| Deprecated | Still answers normally. A retirement date and a replacement are published. Responses carry a syntic-deprecation header naming both. | Proposed — not offered: 6 months for generally available models, 30 days for preview models. |
| Retired | Removed from the catalog. Requests naming it return 404 model_not_found. | Permanent. |
How you are told
- An email to every organization owner whose organization used the model in the previous 90 days.
- A banner in the Console’s usage pages, listing the keys and workspaces still sending the name.
- A line in Release notes.
- The
syntic-deprecationresponse header on every request that names the model, so you can alert on it in your own logs. - A
lifecyclefield inGET /v1/models:active,deprecatedorretired, withretires_atset once deprecated.
Replacement promise
Proposed — not offered. Every deprecated model names a replacement that is available on the same or a lower plan level, at a price no higher per token for at least the first 6 months after the announcement, or the announcement says plainly why not.
Aliases
A family alias such as Amara (when introduced) always points at the current recommended model of that family and moves without notice to a newer one. Use exact names in production when you need stable behaviour; use aliases for prototypes.
Exceptions
Syntic may shorten a timeline only if continuing to serve a model would create a security or legal problem. In that case owners are told immediately, with the reason.
Checking your exposure
Usage by model shows which models your organization calls and how much. Filter for any model with lifecycle: deprecated.