> ## Documentation Index
> Fetch the complete documentation index at: https://continuum-three-olive.vercel.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Auto-revive

> Why the rolling-window keep-alive is paused, and what it would have done.

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.

<Warning>
  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.
</Warning>

## 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.

| Provider             | Window shape                                   | Revive-eligible           |
| -------------------- | ---------------------------------------------- | ------------------------- |
| Claude               | Rolling 5h + weekly                            | Conceptually yes (paused) |
| Codex                | Rolling 5h + weekly                            | No                        |
| Z.ai Coding          | Rolling 5h + weekly, from Z.ai's own quota API | No                        |
| OpenCode Go          | Rolling 5h, weekly, and monthly                | No                        |
| Grok                 | A single weekly window                         | No                        |
| Cursor               | Monthly billing period                         | No                        |
| Gemini / Antigravity | Weekly bucket, no perpetual 5h window          | No                        |

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.

<Note>
  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.
</Note>

## 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.

## Related

* [Usage](/docs/surfaces/usage) — the provider cards and menu-bar gauge that show your live window state.
* [Analytics](/docs/features/analytics) — track spend over time so you can decide when to let a window simply lapse.
