Multica shared-runtime quota: one Claude account backs the whole crew

Applies to: the crew runtime bf3c31e7-4a7e-452d-98c7-d0e88beda4dd (Claude (Joshuas-MacBook-Pro-2.local)) and every autopilot assigned to one of its agents.

The constraint

All 12 crew agents — Orion, Codi, Roy, Dave, Vicki, Maggie, Dori, Desi, Riley, Penny, Sage, Tess — resolve to the same runtime_id:

$ multica agent list --output json | jq -r '.[] | [.name, .runtime_id] | @tsv'
Orion   bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Codi    bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Roy     bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Dave    bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Vicki   bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Maggie  bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Dori    bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Desi    bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Riley   bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Penny   bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Sage    bf3c31e7-4a7e-452d-98c7-d0e88beda4dd
Tess    bf3c31e7-4a7e-452d-98c7-d0e88beda4dd

(re-run confirmed 2026-09-02; see also multica-github-auth.md's independent confirmation of the same single-runtime fact for the GitHub token pool).

That one runtime is one Claude Code CLI login — one Anthropic account — and it carries two independent caps, not one:

• A 5-hour rolling session window (You've hit your session limit · resets <time>).
• A weekly cap (You've hit your weekly limit), separate from the rolling window and not fixed by rescheduling — staggering autopilot fire times moves consumption around inside a week, it does not reduce the total.

Both are real and both have fired. Dave — gc maintenance watchdog hit the session-limit cap on 2026-09-02 (OBJ-3280, a recurrence of OBJ-3279), and Orion's diagnosis on OBJ-3280 found the weekly cap had separately already been hit on three distinct days in the preceding month (2026-08-04, 08-05, 08-25). There is no migration off this constraint available today — see "Open gap" below.

Rule: evaluate cadence changes against total fleet load, not one autopilot

Adding or tightening any autopilot's cadence must be checked against what else fires in the same window, not just that autopilot's own schedule. A cadence that looks reasonable in isolation — hourly, every 2 hours, whatever — says nothing about whether it collides with everything else already drawing on the same shared quota. Maggie — Issue health sweep firing 30 * * * * with no time-of-day or weekday guard was, on its own, an unremarkable hourly sweep; stacked against four other Chicago-morning autopilots it became the single largest consumer in the fleet and a direct contributor to a watchdog going dark.

Before shipping a new or tightened autopilot cadence, check what already fires in its window. multica autopilot list --output json returns {autopilots: [...], total} with each entry's title and status, but not its cron — pull that per-autopilot:

multica autopilot list --output json | jq -r '.autopilots[] | select(.status == "active") | [.id, .title] | @tsv'
multica autopilot get <autopilot-id> --output json | jq -r '.triggers[] | [.cron_expression, .timezone, .enabled] | @tsv'

Quota windows and the danger zone

Reset times observed in session-limit failure messages place window boundaries at 04:00 / 09:00 / 14:00 / 19:00 America/Chicago, with exhaustion landing 2.5–4.5 hours into a window. Schedule anything alerting-critical (watchdog-class autopilots especially) in the first ~2 hours after a boundary, not in the middle or tail of one.

This is a provisional, empirically-inferred pattern, not a documented Anthropic API contract — it is inferred from a handful of observed reset timestamps. If window boundaries turn out to be anchored to first-use-after- idle rather than fixed wall-clock times, this pattern will drift. Re-check it against fresh failure timestamps before leaning on it for anything new.

Exhaustion is fleet-correlated, not per-autopilot

When a session or weekly cap is hit, every autopilot scheduled at that moment fails — not just the one that happens to get the blame. One 2026-09-02 exhaustion event took out six runs across four unrelated autopilots at once (Maggie — Blocked review, Dave — Staging health check ×2, Dave — gc maintenance watchdog, Maggie — Issue health sweep ×2, Maggie — Backlog sweep) — diagnosed on OBJ-3280.

When you see a quota failure, diagnose the account's total load in that window, not just the one autopilot that happened to fire at the exhaustion point. Treating a quota failure as a bug in the specific autopilot that surfaced it — as the first occurrence of this pattern did, before it was traced back through OBJ-3279 and OBJ-3280 — sends the investigation down the wrong path twice.

No per-autopilot token attribution

There is no way to see which autopilot or agent consumed how much of the shared quota. multica runtime usage <runtime-id> --days N reports per-runtime/per-model/per-day totals only:

$ multica runtime usage bf3c31e7-4a7e-452d-98c7-d0e88beda4dd --days 7 --output json
# → rows keyed on {date, model, provider, runtime_id}; no autopilot_id, no agent_id

Fire count (from multica autopilot list) is the only available proxy for consumption, and it is an imprecise one — a long-running autopilot burns far more of the shared quota than a short one, and this report can't tell them apart. Don't go looking for a per-autopilot breakdown; it doesn't exist yet. If you need to reason about which autopilot is expensive, use fire count as a rough signal and corroborate with wall-clock run duration from multica autopilot runs <id>, not runtime usage alone.

For reference, output-token totals on this runtime over the week leading up to this doc (summed across models, multica runtime usage bf3c31e7-4a7e-452d-98c7-d0e88beda4dd --days 7, re-verified 2026-09-02): roughly 1.7M → 0.9M → 3.7M → 4.8M → 4.8M → 12.4M → 10.3M tokens/day across 2026-08-27 through 2026-09-02 — a steep, non-linear climb. Re-run the same query before treating these as current; they are a snapshot, not a baseline.

Open gap

Nothing today isolates the alerting layer (watchdog-class autopilots) from the same shared quota — so it's exposed to the exact failure mode it exists to catch. Whether a second, separately-licensed runtime (there is at least one other online but idle Claude runtime in this workspace, Claude (ai-server)) can absorb that work depends on whether it's a distinct Anthropic login or the same account on a second device — subscription session and weekly limits are per-account, not per-device, so moving work to a same-account runtime buys nothing. That question is unresolved as of this writing (OBJ-3280) and needs a human answer before a runtime split can be scoped.

Confirmed occurrence: the meta-watchdog went dark too (OBJ-3927, 2026-09-16/17)

The gap above stopped being theoretical. The workspace's weekly cap fully exhausted for ~22 hours (2026-09-16T13:30:26Z → 2026-09-17T13:23:18Z, "You've hit your weekly limit · resets 8am (America/Chicago)"), and it took out Dave — Autopilot run failure sweep (a43b4c1d-1fd4-404c-86e8-fec51ce3dbf9) — the autopilot documented in §2f of the autopilots guide as this workspace's own fleet-wide failure watchdog — along with two of the five watchdog-class autopilots it exists to police (Dave — gc maintenance watchdog, Dave — Crono liveness check) and one non-watchdog autopilot (Maggie — Issue health sweep, 3 consecutive failures). The sweep's own Step 0 self-check ("this is a partial mitigation, not a guarantee — it runs on the same quota it monitors") predicted exactly this outcome, and it materialized on the very next full weekly-quota exhaustion: 4 consecutive failed runs of the sweep itself (2026-09-16T17:47:26Z → 2026-09-17T11:47:26Z), only recovering at 17:47:26Z — the run that finally filed the finding. Net effect: roughly 28 hours elapsed between the first correlated failure (2026-09-16T13:30:26Z) and the finding reaching a human's queue (2026-09-17T17:52:41Z).

Dave's diagnosis (issue OBJ-3927) ruled out a code fix — there is no multica autopilot create/update priority or quota-carve-out flag to implement one against — and left two open tracks:

• Platform escalation (needs the workspace owner): either raise the shared weekly quota to match current fleet volume (34 active autopilots plus interactive/Codi usage), or add a reserved/priority allocation so a fleet-wide exhaustion can't starve the five single-point alerting paths simultaneously with the thing they're watching.
• Decouple the paging step from the shared quota. The sweep's detection logic — read multica autopilot runs, diff statuses, classify — doesn't need model reasoning; only the classification-and-filing step benefits from an LLM. A non-agent trigger (webhook/cron hitting a script) for at least the paging step would cost zero quota and couldn't be starved by the event it's built to catch. No such mechanism exists in this workspace today.

Same-day mitigation available now without a platform change: stagger the heaviest non-critical schedules (Maggie — Issue health sweep alone fires 12×/day) via multica autopilot trigger-update, per the cadence rule above — this lowers peak shared-pool draw but does not fix the underlying single-point-of-failure.

Related

• OBJ-3279 — the originating incident: Dave — gc maintenance watchdog first failed on session-limit exhaustion.
• OBJ-3280 — the identical recurrence that triggered the diagnosis this page is built on (Dave's root-cause comment, Orion's fleet-wide task package).
• OBJ-3927 — the confirmed occurrence above: a full weekly-quota exhaustion took out Dave — Autopilot run failure sweep itself alongside the watchdogs it monitors, materializing the "Open gap" this doc had flagged since 2026-09-02.
• Multica Autopilot Run-Status Gotcha — a related but distinct trap on the same autopilot: status/failure_reason on multica autopilot runs isn't reliable fault ground truth on its own (stale issue blocked rows, last_run_status hiding fail-then-succeed). That gotcha is about misreading a run's recorded state; this one is about the run never happening at all because the reader itself was starved.
• multica-github-auth.md — the same "all 12 agents share one runtime" fact, but for a different shared resource: the GitHub REST API's 5,000-requests/hour pool, not the Claude account's session/weekly quota. Don't conflate the two — fixing one doesn't touch the other.
• ../guides/multica-autopilots.md — see its "Concurrency & runtime footguns" section for a different constraint on the same runtime: Maggie's single execution slot (max_concurrent_tasks: 1), which head-of-line-blocks on scheduling collisions independent of quota exhaustion.
• multica-runtime-identity-gotcha.md — same runtime, a different failure class entirely (a second machine silently claiming the runtime record via a copied daemon.id).

---

Last updated: 2026-09-17 (OBJ-3927: confirmed occurrence — the meta-watchdog itself went dark during a full weekly-quota exhaustion)