Deprecations
Models are improved and replaced over time. This page explains how a model leaves the catalog, what that means for code that still asks for it, and how to move to a replacement without surprises. It also records every model that has been retired.
Lifecycle terms
| Status | What it means for you |
|---|---|
| Active | Fully available and recommended. |
| Deprecated | Still answers, but a retirement date and a replacement have been announced. Plan your move. |
| Retired | Removed from the catalog. Requests that name it are answered by the default model instead. |
Current status
| Model | Status | Retirement date | Recommended replacement |
|---|---|---|---|
Amara S1.2 | Active | ||
Amara Quick | Active | ||
Amara Deep | Active | ||
Syntic Code | Active | ||
Syntic Code Fast | Active |
Retirement history
No model available through the Syntic API has been retired yet. Retirements will be listed here, newest first, with the date, the retired name and its replacement.
What happens to a retired name
Today the API does not reject an unknown model name. A request that keeps sending a retired name therefore keeps working, but it is answered by the default model, Amara S1.2, and nothing in the response flags the switch: there is no error and no x-syntic-model-downgraded header, because the name is simply no longer in the catalog.
That has two consequences:
- Your feature does not break on retirement day, which is helpful.
- Its behavior and its cost per request may change without notice to you, which is not. A task tuned for one model can give noticeably different answers on another, and the default model is priced differently from most others (see Pricing).
Not live yet — on develop: a retired or unknown name is rejected with 404 model_not_found instead of falling back. Once that ships, a retired name stops working on retirement day, so move to the replacement before then.
The safe course is to finish moving before the retirement date.
Moving to a replacement
Find every place the old name is used
Search your code, configuration, environment variables and any stored prompts or job definitions for the model name. If you followed the advice to keep model names in configuration, there should be one place per service.
Re-run your evaluation on the replacement
Use the same test inputs and scoring you used when you chose the model (see Choosing a model). Pay most attention to tasks with strict output formats, such as labels or JSON, where small behavior changes show up first.
Adjust prompts if needed
Differences are usually fixed with clearer instructions or an extra example rather than structural changes. Keep the old prompt version so you can compare.
Check cost
Multiply your typical token counts by the replacement’s rates. A move from one model to another can change the per-request price even if token counts stay the same.
Switch gradually
Send a share of traffic to the replacement first, compare results and error rates, then move the rest.
Find out which models you use
To check whether anything in your organization still uses a model:
- From your own logs. Log the model name you send and the
x-syntic-request-idof every request. This is the most reliable record because it ties each request to the code that made it. - From the Console. The Usage page shows your organization’s consumption; see Usage & cost.
Staying ahead of changes
- Keep model names in configuration, never scattered through code.
- Read Release notes; new models and deprecations are announced there.
- Re-run your evaluation set whenever you change models, not only at retirement.
- Alert on the
x-syntic-model-downgradedheader. It does not fire for retired names, but it does catch plan changes that remove access to a model.
Parameters can be deprecated too. Any change to request fields or response shapes on POST /v1/chat/completions will be announced in Release notes.
Related pages
- Models overview: the current catalog.
- Choosing a model: how to compare models on your own data.
- Release notes: announcements, newest first.