LLMSwaps

Which model each app runs today, and when it last changed

Fifteen days of disuse inside a six-month window

The sharpest sentence in this column is about disuse rather than dates. Once a legacy period begins, an existing customer may lose access after fifteen days of inactivity, so a window published in months can close in a fortnight for anybody whose production has paused between blocks. As of 2026-09-22.

What the lifecycle page says about access ending before the stated date. Recorded 2026-09-22.
What the page is askedWhat Amazon Bedrock publishesWhat that leaves open
Can access end before the dateYes, after 15 days of inactivityOnly once the legacy period has begun
How long is the published windowSix months or 45 days per modelSo the clause can shorten it by an order
Is inactivity definedNot defined in calls or in volumeSo a threshold cannot be planned against
Who does it affectExisting customers, inside the windowNew adoption already stops at legacy

Inclusion rule. A cell is filled from a published sentence about access ending other than on a stated date. A reader's estimate of how fast a menu could change does not fill one. Order. The clause first, then the window it shortens.

1The clause matches the shape of serial production exactly

A series alternates between heavy generation while a block is in flight and weeks of writing, review and edit. A fortnight of no calls is an ordinary gap in that rhythm rather than a sign of abandonment.

So a production that stopped calling a model in order to finish scripts can return to find the runway it was counting on already spent. Nothing else in this register can take a window away that quickly.

A fortnight of silence inside a window of monthsA series alternates between heavy generation while a block is in flight and weeks of writing and edit. Fifteen days of no calls is an ordinary gap in that rhythm rather than a sign of abandonment, and the clause does not define what activity means.How the rhythm of a series meets the clauseHeavygenerationBlock oneDaily callswhile episodesare beingmade.Writing andeditDay 1 to 15No calls. Anordinary gapin serialproduction.Access can endDay 15Inside thelegacy window,with the datestill monthsaway.Activity is not defined, so no keep-alive can be designed with confidence
Fig. 1 Nothing else in this register can take a published window away that quickly.

2Undefined is the part that cannot be engineered around

The sentence does not say what activity means: one request, a volume, a particular kind of call. Without a threshold, a team wanting to stay inside the window cannot design a keep-alive with any confidence that it qualifies.

That is worth recording as a separate finding from the fifteen days. A defined minimum would be a mild inconvenience; an undefined one is an unquantifiable risk.

3It only applies inside the window, which is the mitigation

The clause is stated for the legacy period, so a model still in the first state is not exposed to it. That makes reading the state a genuinely protective habit rather than bookkeeping.

The state reading for this entry covers how that value is obtained. It is the one entry in the register where an automated check could catch this before it bites.

  • How access can end before the date
    Once the Legacy period begins, existing customers may lose access after 15 days of inactivityAmazon Bedrock, model lifecycle / recorded 2026-09-22
  • Legacy period
    Six months or 45 days, stated on each model cardwhich is the notice given before end-of-lifeAmazon Bedrock, model lifecycle / recorded 2026-09-22

4Sources

Read from the model lifecycle page on docs.aws.amazon.com, 2026-09-22. The whole entry is on Amazon Bedrock, and the column it sits in is on Ending early. Same column, other entries: Microsoft Foundry, Gemini API.