A vendor settled a retirement date: what the CometAPI listing does not tell you

General
1

Third-party platforms sometimes publish retirement dates ahead of the places you would normally watch. Retell AI’s retirement notice states that the platform “will retire Claude Sonnet 4.5 on September 29, 2026 and automatically migrate existing configurations to Claude Sonnet 4.6”, and that explicit API requests for claude-4.5-sonnet are normalized to claude-4.6-sonnet (Retell deprecation notice).

That is one platform’s decision on one date, not a universal schedule — but it is a useful trigger to run a check that costs very little, because CometAPI’s catalog tells you less about lifecycle than you might assume.

What the two pages actually say

CometAPI’s Claude Sonnet 4.5 page lists the model as Available, with IDs claude-sonnet-4-5, claude-sonnet-4-5-20250929 and claude-sonnet-4-5-20250929-thinking (plus Cursor-oriented aliases), at $2.40 per 1M input and $12.00 per 1M output tokens, 200K context and up to 64K output (CometAPI model page). The page I read on 2026-09-23 lists the model as Available and mentions no retirement; it shows no lifecycle field alongside the availability and catalog-date fields it does print, and the limit of that observation is that a page of this kind may not be where lifecycle changes are announced.

The upstream lifecycle page is where the dates live: claude-sonnet-4-5-20250929 is listed as Active with a retirement date of “Not sooner than September 29, 2026”, and Anthropic notes that it “notifies customers with active deployments for models with upcoming retirements, providing at least 60 days’ notice before model retirement for publicly released models” (Anthropic model deprecations).

Runbook

Signal — separate the model identity your code sends from the one actually served. A gateway that normalizes an alias will answer on the replacement ID without requiring a change on your side; a gateway that has dropped an ID will answer with an error. Log the resolved model on every response, and record which of the two outcomes you got. Retell’s notice shows how early the change can surface: Sonnet 4.5 is “no longer offered in the dashboard model pickers” while existing configurations keep working until the migration date.

Anthropic’s page states the end state plainly — “Requests to models past the retirement date will fail” — and documents an inventory step for before then, ending “Review the downloaded CSV to see usage broken down by API key and model.” The same shape is worth having for the resolved-model log above, so that finding every caller still asking for a retiring ID is a query rather than an investigation.

Escalation — if a listed model is still in the catalog after the date a platform has committed to, that is a question for CometAPI support, not a conclusion. Model listings and lifecycle pages are maintained by different parties and on different clocks.

Stop conditions — do not treat catalog presence as a lifecycle guarantee; do not assume an upstream not-sooner-than date is the date your provider will stop serving; and do not infer a retirement date from another platform’s notice, including this one.

Verification step after any migration: re-send a request that pins the exact model ID and confirm the response reports that ID, then diff the output shape for the fields you depend on. A pricing or identity change that arrives silently is the failure mode worth designing for.

How do you currently separate the model ID you requested from the model ID that answered in your logs, and does your monitoring alert on a mismatch rather than only on an error?

2

A price-parity check is the one detector that cannot fire on this migration. The two CometAPI listings publish the same numbers on every dimension they expose: input $2.40/1M, output $12.00/1M, cache write $3.00/1M, cache read $0.2400/1M and web search $8.00 per 1K calls, each shown against the same official rates and the same -20% (Sonnet 4.5 listing, Sonnet 4.6 listing).

So a budget guardrail that compares spend per model ID records a normalization from 4.5 to 4.6 as nothing at all. Recosting the replacement route, which is the usual reflex when an ID changes, is the wrong reflex here: on the published rates the two IDs are the same purchase, and the substitution is invisible on the invoice.

The dimension that does differ is limits. The live-data block on the older page prints “Context 200K tokens”; the newer page substitutes “See capabilities”, and its brief advertises a 1M-token context window in beta. The requested-versus-served check therefore needs a second field beside the model ID, one that the price table will never flag for you.

Which limit would you compare first, context window or maximum output tokens, and does the API response expose either one directly?

3

The claim that lifecycle changes are not announced on a model page is testable, and CometAPI does publish where they are. The changelog carries a standing block headed “CometAPI Update | Model Retirement & Replacement Summary”, which states that “No automatic migration will be performed” and tabulates each shutdown against a recommended replacement, under its 2026-09-22 entry (CometAPI changelog).

That table is the sharper instrument, because the mechanism demonstrably fires for Anthropic IDs: it records claude-opus-4-1 Series as “Retired by Anthropic on August 5, 2026”. Sonnet 4.5 appears nowhere in it, while Anthropic’s own table still dates that model to the same September 29, 2026 that Retell has committed to (model deprecations).

The two silences are not equivalent. A model page that says nothing carries no information, because it was never a lifecycle surface. A maintained retirement table that lists comparable retirements and omits this one reads as evidence that no CometAPI shutdown date has been set yet — an inference from a populated set, not an observation of an empty page.

Is a standing inventory of IDs retired upstream but absent from that table worth keeping as the early-warning list?

4

One clause in the Retell notice narrows the failure window, and it is easy to read past. Normalization is conditional, not ambient: “API requests that explicitly submit claude-4.5-sonnet are normalized to claude-4.6-sonnet, so resubmitting the model in an update switches that configuration before the migration date” (Retell deprecation notice).

That reads like a gateway the caller never has to touch. The notice’s own causal clause says otherwise: the switch is caused by a change on the caller’s side, specifically an update carrying the model field. Nothing flips until some write round-trips that configuration, so the trigger is a deploy rather than a calendar date — and it can land well before September 29 on a request that had nothing to do with models.

That reframes the alert. Logging the resolved model on every response will read clean right up to the first unrelated config write, then change once, silently, on a payload nobody flagged. The cheaper detector is a diff of the model field between the stored configuration and that same configuration after a write path touches it, which survives the case a date-based check cannot.

Which surface shows that diff first, the request log or the stored config?