ccmax-monitor v1.35.2

Live Sessions

Active Claude Code sessions reporting heartbeats to el02. The heartbeat daemon sends “alive” pulses every 5s; sessions are pruned after 15s of silence.

How rotation works

Accounts are listed in the order they will be used. The system always picks the account whose weekly quota resets soonest and uses it as much as possible before that reset happens — because any unused capacity is lost when the weekly window resets.

7d — How much of the 7-day weekly quota has been used. This is the main capacity measure and drives the rotation priority. The system burns this as close to 100% as possible. Once it reaches 100%, the account is exhausted and moves to the bottom of the list until its weekly reset. Velocity prediction can also rotate early when 7d usage is accelerating fast enough to hit 100% within the next 10 minutes (event: velocity_preemptive_switch window=7d).

5h — How much of the 5-hour rolling rate limit has been used. This is a short-term speed limit. If it hits 80%, the system temporarily switches to the next account until the rate limit cools off, then switches back. Velocity prediction triggers a switch earlier (within ~5 minutes of projected breach) if usage is accelerating (event: velocity_preemptive_switch window=5h).

Mid-turn deferral (HEART-12) — When a tool call is running mid-turn, the switcher defers the credential swap until the call finishes, no matter why the rotation was triggered (breach, velocity, perishable, or exhaustion). This prevents the in-flight request from hitting the old account's stale cached token and getting a 429. The switcher retries on its next 30s tick, so the swap happens within seconds of the turn ending (event: switcher_switch_deferred).

Reset — Time remaining until the oldest usage in that window drops off. When the 7d reset happens, the percentage drops and the account becomes available again.

Token — A short fingerprint of the OAuth token stored in the vault. Shows the fingerprint in green when healthy, yellow “expiring” when the token expires within 1 hour (the switcher will auto-refresh it), “refreshing...” when expired but auto-recoverable, grey “expired (7d exhausted)” when the account is at 100% 7-day usage (token refresh is deferred until the account becomes usable again), and red “needs /login” only when the token is truly dead with no way to auto-recover.

Refreshed — When the token in this vault slot was last freshened. There are three independent paths that can refresh a token, and the dashboard tags which one was responsible:

• refreshed — the el02 switcher called Anthropic's OAuth refresh endpoint autonomously. Non-active accounts are refreshed every 15 minutes unconditionally (HEART-06). The active account is refreshed by the safe-period block when no client is using it (no turn in flight, no session alive, idle for >10 min) or via the prompt-boundary refresh (POST /api/prompt-refresh) when exactly one session is at a prompt boundary (HEART-07).
• pushed — the token was placed into the vault by a Claude Code client via POST /api/push-credential, not by the switcher. This happens after a manual /login: the auth_success hook on your Mac sends the new token back to el02 so the whole fleet sees the freshened credential. (pushed) is shown in blue on the dashboard so you can tell at a glance which path delivered the most recent token. The vault treats a push the same as a refresh — both update access_token, expires_at, and the freshness timer.
• HEART-11.3 emergency override — if the active token is < 30 min from expiry AND no turn is in flight AND the heartbeat is > 2 min stale (evidence the session-alive signal is unreliable), the switcher overrides the normal gate and refreshes anyway (event: switcher_emergency_override). This is a last-resort safety net — in normal operation it never fires.

Live Sessions panel — shows every Claude Code window currently sending heartbeats to el02. The heartbeat daemon (heartbeat-daemon.sh) sends an “alive” pulse every 5s for the entire lifetime of a session. The dashboard prunes a session 60s after its last pulse, and a background asyncio task re-checks for stale sessions every 5s regardless of incoming traffic (HEART-11.2) so the count is correct even when every client dies at once. The switcher reads active_session_count from this panel's state to decide if it's safe to refresh the active token.

▶️ marks the account currently being used by all connected Claude Code sessions. The account directly below it is next in line if the active account gets rate-limited or exhausted.

Network & Security

Loading network info...

All traffic to this dashboard is encrypted via HTTPS through Tailscale Funnel (primary) and Cloudflare Tunnel (legacy). Access is restricted to authorized GitHub accounts and service tokens via Cloudflare Access. No ports are exposed on the server.

API

Interactive API documentation (Swagger UI) is available at: /docs

Uptime Monitoring

External health checks via Uptime Kuma — alerts to @ccmax_mon_bot on Telegram.

Monitor	What it checks	Status	24h Uptime
Loading monitors...

Codebase

Deployed source on el02 — generated by scc at service startup.

Language	Files	Code	Comments	Blanks
JSONL	2	13,041	0	0
Python	35	6,823	1188	631
Shell	4	243	64	55
Markdown	3	166	0	63
TOML	3	98	4	14
YAML	1	7	0	0
Total	48	20,378	1256	763

v1.35.2 · scc

Setup & Docs

Setup instructions and full documentation are in the GitHub repository (private — collaborator access required):

github.com/terrylica/ccmax-monitor

To request collaborator access:

• terrylica on GitHub
• @EonLabsOperations on Telegram
• +1 604 300 8878 (Telegram)