The model we stopped calling, except once a month

The application can be quiet and still depend on the model

The main application has moved to the replacement model and the last seven days show no old-model calls. A month-end report can still hold the retired identifier. Nothing in those seven quiet days required it to run. Before closing the migration, I would compare that silence with the triggers the business still relies on, including the ones that have not had a reason to make a call yet.

Choosing a replacement is only part of retirement work. A call record tells us something ran; an empty window says much less about what might run next month. The missing piece is the dependency itself: where the identifier lives, who owns the route and what makes it execute. Those details turn an observation of quiet traffic into a decision about a particular consumer.

Anthropic’s deprecation history records notice for Claude 3 Haiku on 19 February 2026 and retirement on 20 April 2026. That completed retirement supplies a concrete maintenance example: a consumer still naming the retired model needs an explicit migration decision, even if its call path runs infrequently. The provider’s current replacement recommendations are also not a record of which alternatives existed at every earlier date.

A useful retirement plan joins two inventories: the declared places that can invoke a model and the observed calls that actually did. Each exposes gaps in the other. A configuration entry with no recent usage may be dormant, obsolete or simply missed by the usage report. An observed call with no known owner is a different problem, and changing the main application will not necessarily solve it.

Start with the things that can make a call

For a fictional business, list the customer-support assistant, a nightly document classifier, a month-end report and a desktop worksheet. Add fallback routes, scheduled functions, worker images and environment-specific configuration. Record the actual model identifier and platform, not just a friendly name such as “small model”. A gateway may map that name to a different deployment than the application developer expects.

Search the code and deployed configuration, then say which places that search covered. An identifier can also live in a database, an administration page or a hosted automation outside the repository. The colleague maintaining a desktop worksheet may know about a route the main service team cannot see. Bring those consumers into the register rather than treating a clean repository search as an inventory of the whole organisation.

The trigger tells you what silence means

Record an owner and trigger for every known consumer. The trigger matters because it tells you when an absence of calls is meaningful. Seven quiet days may cover a nightly classifier but say little about a month-end report. A manual worksheet can remain unused for weeks and still be essential when a particular customer request arrives.

Platform belongs beside the model identifier in the register. Anthropic's documentation distinguishes its operated platforms from partner-operated services, which set their own schedules. A consumer running through a partner must use that platform's notice and date. Recording the source of the schedule makes it possible to check whether an otherwise accurate retirement notice actually applies to the deployment being migrated.

Compare declared consumers with observed usage

Here is an invented four-consumer review. The support assistant is declared and appears in usage. The nightly classifier is declared and appears too. The month-end report is declared but absent from the seven-day export. An unknown API key appears in usage without a corresponding owner. Three categories emerge: observed known work, declared but unobserved work and observed but unexplained work.

The month-end report's absence needs an explanation tied to its trigger. Inspect the schedule and configuration, run a controlled representative case or deliberately disable the report if it is no longer required. Those actions can establish its disposition. A seven-day usage export alone cannot justify marking it migrated or retired, because the report may never have been due to run during that window.

For the unknown key, investigate the calling application through the provider’s available account records and your own credential inventory. Protect secrets while doing so. The useful output is an accountable consumer and migration decision, not a spreadsheet containing complete API keys that can now invoke the service from several more places.

Check the usage export’s account, project, key, dates and platform before using it to close a dependency. A production view may miss a worksheet billed through another account. Label the finding so a colleague can inspect its reach: no old-model traffic in this account over these dates. That statement is useful on its own. Turning it into nobody uses the model would add a conclusion the observation cannot supply.

A replacement is a change in behaviour

Separate the replacement choice from the rollout date in the register. A consumer may have a tested candidate but still be running the old configuration in production. Another may have been deployed without evidence that the relevant scheduled job has executed. Recording both states prevents a meeting note saying “migration agreed” from becoming the only evidence that the dependency has actually moved. Name the environment and deployed revision alongside the decision.

Once the consumers are known, decide how each will migrate. Some may use the same replacement configuration. Others may have output constraints, latency needs or review routes that justify separate choices. Replacing the identifier everywhere is administratively tidy, but it does not establish that a classifier and a long report still do their jobs.

Preserve a representative input and expected behaviour for each consumer. The support assistant might need to retain a particular escalation boundary. The classifier must still emit labels accepted by its downstream system. The report may depend on a structured response that a parser reads. Verify the complete path, including fallback handling when a request fails or returns an unusable result.

This is distinct from proving that the new model is generally better. A retirement can force a migration even when no candidate reproduces every old behaviour. In that case, name the limitation and choose the compensating change: additional review, a smaller task scope or temporary suspension of a risky route. A forced calendar does not make an unexplained regression less real.

Exercise the fallback even when the migrated primary is healthy. An error handler can keep the retired identifier out of sight until the new request fails, which is precisely when the application needs recovery to work. Use representative inputs and retain the deployed fallback configuration as well as the intended replacement. A quiet error branch needs its own evidence; successful ordinary traffic has not asked it to do anything.

Close the dependency, not just the ticket

For each consumer, keep evidence of the deployed configuration, a representative result and the treatment of already queued work. An old message may carry a model identifier captured when it was created. Decide whether to migrate that work, reroute it under an explicit policy or hold it for review. Leaving it to fail later is a deferral, not completion.

Then look for remaining observed calls over a period that matches the known triggers. Continued traffic can reveal a missed deployment or a copied configuration. No traffic is useful corroboration once dormant paths have been accounted for.

If a consumer is being retired rather than migrated, remove its trigger and credentials where appropriate, archive the operating note and explain what replaces its business function. A disabled automation with an active schedule that retries forever is still operational clutter. So is a worksheet whose button now fails without telling the person what to do instead.

Close each consumer against its configuration, trigger and queued work, then use observed traffic to corroborate the result over a suitable window. That accounts for the monthly report and worksheet as well as the busy application. When the deadline arrives, the team can explain what replaced each dependency or why the route was retired. It no longer has to hope that the next unusual customer request is not the first occasion the old identifier is tried again.