LLMSwaps

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

Inactivity clause: losing access by not using it

An inactivity clause allows access to end after a period of disuse rather than on a date. One platform in this register states that once a legacy period begins, an existing customer may lose access after fifteen days of inactivity, which can close a window measured in months in a fortnight. As of 2026-09-22.

Why this clause matches the rhythm of serial production. Recorded 2026-09-22.
The rhythm of a seriesWhat the clause does to it
Heavy generation while a block is in flightNothing; the model is being called daily
Weeks of writing, review and editThe window can close during them
A pause between seasonsAccess may be gone on return
A model kept as a fallback, rarely calledThe fallback is the first thing lost

Inclusion rule. Read from the lifecycle page of the one platform in this register that publishes such a clause. Activity is not defined there. Order. From continuous use to no use at all.

1Undefined is worse than short

The clause does not say what counts as activity: one request, a volume, a particular kind of call. Without a threshold a team cannot design a keep-alive with any confidence that it qualifies.

A defined minimum would be a mild inconvenience. An undefined one converts a published window into a risk nobody can quantify, which is a separate problem from the fifteen days.

2The clause targets exactly the wrong pattern

A production alternates between bursts of generation and weeks of other work. A fortnight of no calls is an ordinary gap in that rhythm rather than a sign that anybody has abandoned anything.

So the arrangement penalises intermittent use, which is what creative work looks like, and rewards continuous use, which is what software workloads look like.

A clause that penalises the rhythm of a seriesA production alternates between bursts of generation and weeks of other work. A fortnight of no calls is an ordinary gap in that rhythm rather than a sign that anybody has abandoned anything.A software workloadA series in productionCalls the modelContinuouslyIn bursts, per episode blockA fortnight of silenceWould be unusualIs a writing weekExposure to the clauseLowHigh, and unpredictableCan design a keep-aliveProbablyActivity is not definedThe clause applies only inside the legacy window, so reading the state is protective
Fig. 1 The arrangement rewards continuous use, which is what software workloads look like, not creative ones.

3It applies only inside the window

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 lifecycle state a genuinely protective habit rather than bookkeeping.

On that platform the state is readable through the interface, so the check can be automated. It is the one entry here where this risk could be caught before it bites.

A definition rather than a dated entry: no line above is a vendor statement. Where this word turns up in a real notice, the wording and the date are on the reading on that clause. Nearby terms: Active deployment, Export window, House model.