Cohere's Deprecation Timeline for Legacy Command Models

Cohere maintains a single deprecations page as the authority for which models and endpoints are on their way out. This page does not copy its dates, deliberately — a copied date is wrong the moment it changes, and the mechanism for finding out is more useful than a snapshot of the answer.

Where the notices live

The primary source is Cohere’s deprecations documentation, which lists deprecated and retired models and endpoints with their dates and recommended replacements. Cohere also announces changes through its changelog and by email to accounts that have called an affected model, which is the notification most teams actually act on.

A notice is more than a date, and reading only the date is how a migration goes wrong. The useful parts are the recommended replacement — which is a statement about intended continuity, not necessarily about behavioural equivalence — and the scope, since a notice can retire a model on one endpoint while leaving it available on another. A model that stops being offered for chat but remains available for embedding is one deprecation notice that affects two of your services differently, and a blanket search-and-replace on the model name will break the one that was fine.

What the stages mean

The distinction that matters operationally is between a model being deprecated and a model being retired, and they are separated by months of warning rather than being one event.

• Deprecated — still serving, still billable, still returning normal responses. It is flagged in the documentation and in the API, and no new work should target it. Nothing breaks today. This is the entire window in which a migration is cheap.
• Retired — the model no longer serves. Requests naming it fail. If your model name is a hardcoded string in a deployed service, this is an outage, and it is an outage of a kind your monitoring may not classify usefully because the API is up and healthy.

The one thing to internalise is that a deprecated model does not degrade gracefully into a newer one. There is no automatic substitution. The request simply stops working on the retirement date, at whatever hour that happens in your timezone.

Detecting it from the API

Cohere’s models endpoint reports deprecation per model, which means the check does not depend on anyone reading an email:

curl -s "https://api.cohere.com/v1/models?page_size=100" \
  -H "Authorization: Bearer $CO_API_KEY" \
| jq '.models[] | select(.is_deprecated == true) | .name'

Run that on a schedule against the models your application actually names, and a deprecation becomes a ticket months ahead instead of a page at 03:00. The same response carries context_length and endpoints, so one weekly job covers deprecation, limit changes, and a model losing support for an endpoint you use.

The check is only as good as the list of names you feed it, which is an argument for the model name existing in exactly one place in your codebase. If it is scattered across six services, the monitoring cannot be complete because nobody knows what to monitor.

What has already gone

Two categories are worth knowing about historically, because they explain code you may inherit rather than code you would write.

The first is the pre-Command-R generation: the original command, command-light, and the -nightly variants of both. These predate the tool-use and grounded-generation features entirely, so migrating from them is not a model swap — the request shape they were written against does not carry citations or tools.

The second is whole endpoints. Cohere’s older generative surface, /v1/generate, along with several task-specific endpoints from the same era, has been superseded by Chat. Code calling those is a rewrite rather than a rename, because Chat’s request and response shapes are different in kind. The deprecations page tracks endpoints alongside models for exactly this reason.

What breaks on the retirement date

A retired model name is a client error, not a server error, and that distinction decides whether your existing resilience helps you at all. The request is rejected on the way in with a 4xx status and a message naming the model.

Everything built for transient failure is therefore useless here, and some of it actively hurts. Retries do not help: the second attempt fails identically, and an exponential-backoff wrapper turns one fast failure into a slow one while multiplying request volume. A circuit breaker opens and stays open. Health checks that call a different model report green throughout. Meanwhile the provider’s status page shows no incident, because there is not one — the API is behaving exactly as documented.

The failure signature to recognise: a sudden 100% error rate on one code path, 4xx rather than 5xx, no latency change, no provider incident, and a start time suspiciously close to midnight in some timezone. If your alerting groups 4xx as “client error, probably our bug” and pages nobody, this can run for hours.

Two defences are worth having in place before you need them. First, alert on error rate by model name rather than in aggregate, so a single retired model is visible against otherwise healthy traffic. Second, have a configured fallback model that the code can be switched to without a deploy — the same mechanism you would want for a provider outage covers this case, with the difference that here the switch is permanent and the migration follows at your convenience rather than under pressure.

A migration that is not a fire drill

1. Name a dated snapshot everywhere, not an alias. command-r-plus moves under you; command-r-plus-08-2024 does not. Aliases avoid the outage by silently changing the model, which trades a loud failure for a quiet behaviour change — see pinning a dated Cohere model version for the trade-off in full.
2. Keep the name in one place. Configuration, not literals. Migration should be one edit and a deploy.
3. Poll is_deprecated weekly for every model you name, and route the result somewhere a human reads.
4. Re-run your evaluation set against the successor when a notice appears. A newer Command snapshot is not a drop-in for prompts tuned against an older one, and the differences show up in output format and verbosity long before they show up in quality.
5. Migrate on your schedule, not on the retirement date. The point of the warning window is to spend it.