Skip to main content
Claude’s flat-rate plans meter usage in rolling session windows — typically 5 hours. When the window expires, a new one opens. When it expires while idle, that window is wasted. Auto-revive was the idea of keeping that timer warm so an unused window does not lapse.
Auto-revive is paused in Continuum today, on every client. There is no working toggle to enable it anywhere. This page documents the concept and the reason it is off — not a feature you can turn on right now.

​
Why it is paused

The shipped keep-alive worked the only way it could: by sending a tiny throwaway model request to restart the clock. That has two problems you do not want running in the background:
  • It spends real quota — small, but not zero — on an interaction you never see.
  • It creates visible throwaway conversations in your Claude history.
Rather than ship a feature that quietly bills against your subscription, Continuum disabled it. The plumbing stays in place so it can return the moment a non-consuming keep-alive endpoint exists — one that resets the window without a generative request. Until then, every revive path is a no-op: both the periodic tick and the manual “revive now” trigger record a disabled outcome, log a refusal, and send no network request. A regression suite asserts that no prompt body ever goes out.

​
What it would apply to

Auto-revive was built for Claude’s perpetual 5-hour rolling window, which is the case where an idle window is unambiguously wasted. Several providers have since grown rolling windows of their own, but none of them is revive-eligible either — the blocker is the mechanism, not the shape of the window. One shared support table is the single source of truth for this, and it currently answers false for every provider. The Usage-tab “Keep 5h timer ticking” card and the menu-bar line are gated on that answer, so neither renders — there is nothing to toggle anywhere in the app.
Auto-revive was always a provider-account behavior, not a session behavior. It never kept a particular agent session open; it would have kept the quota window open. With multiple accounts configured, the toggle path routed only to the primary account of each provider kind, never per secondary instance. Since the feature is paused, this is moot today.

​
Not the same as session “revive”

Do not confuse this with the session revive action (POST /sessions/:id/revive). That respawns a degraded session whose agent process died — a live, working operation reached from the session surface, and one you will actually use. It has nothing to do with the quota-window keep-alive described here.
  • Usage — the provider cards and menu-bar gauge that show your live window state.
  • Analytics — track spend over time so you can decide when to let a window simply lapse.