Each open session self-reports every ~10 seconds. Ticking figures are extrapolated from that session's measured pace; they re-anchor to truth on each refresh.

Reading the numbers

• The allowance cards come from the account's own usage endpoint — the same source /usage reads, over the local login. One card per window the account actually has: the 5-hour block, the all-model week, any per-model week, and the model-scoped tanks (Fable among them). Windows the account has not opened yet are absent rather than drawn empty, so a fresh account shows fewer cards until it earns them. The card order is the glance order: whichever window the API flags as binding comes first, then fullest.
• Runway, the line above the cards, answers the only question with one answer: which tank empties first at the current pace, and when. No allowance empties before its own reset means the pace is survivable in every window at once. It also names the binding limit, the next reset, and what happens at the cap.
• % used is how much of an allowance is spent — not a countdown. The big figure is the planning number: at the current pace, when that allowance is exhausted, with the rough wall-clock moment beneath. Won't run out / won't cap means that window's own reset arrives first. When rate-limited, usable again in X is the cooldown.
• At the cap says whether a full tank stops the work or spills into usage credits. With extra usage off, a cap is a hard stop — which is what makes the runway line a schedule and not a warning.
• Reading cached … on the runway line means the usage endpoint did not answer this refresh and the page is replaying its last good response. The figures are real but frozen at that moment; they are never quietly extrapolated past it.
• Everything on this page is per-account. Watchtower fingerprints the logged-in account, and a /login to a different one rolls the weekly window, the sample history and the week's spend rather than carrying the old account's numbers forward. The week tile then counts from the switch and says so.
• Pace now vs avg shows pressure: when "now" is well above average, every ETA on this page shortens — usually because a heavy session is running alongside the others.
• Spend today / spend this week combine every session on this account — workers, closed sessions and the watchtower's own refresh loop included. Today resets at local midnight; the week resets with the weekly limit. Between refreshes the figure ticks forward at the open sessions' measured pace (the … marks extrapolation).
• Model usage (per session) draws total consumption as bars — every model that ran under that session, including the subagents it dispatched, whose transcripts live beside the session's own — with Fable's share as a line across them. Both series are cost-weighted tokens on one scale (output counts 5×, cache reads a tenth), so the space between the line and the top of each bar is the workers' share. Gridlines mark real clock hours.
• Burn attribution splits the account burn the same way: by which models actually ran in the last 45 minutes, not by the model a session window was opened with. A Fable foreman driving Opus implementers therefore shows mostly worker burn. The money split remains an estimate, but each side now names the allowance it is actually drawing down — and where a model has its own weekly window, the mix chips carry that tank's level too. 40% of the burn reads differently when that model's week is nearly gone.
• Model usage · every session is the same chart aggregated across the whole fleet on a shared clock. It replaced a weekly-allowance trend line, which could only climb and so read flat: it showed the limit filling up, never the work causing it. Bursts, idle gaps and the foreman-to-worker balance are all visible here; the allowance figures themselves live in the hero cards above.
• Runway vs the work in flight is the line under the runway figure, and it is the only one that is a decision rather than a reading: does the task list in flight land before the tank it draws from runs dry. It is measured against running task lists, never the rung ladder — a summit days out would drown every runway in a permanent red.
• Every task carries its own estimate. Completed rows show when they finished and how long they took; the ones in flight are due about one average task after they started; pending rows queue behind them. The average is that list's own — a list of five phases is not a list of five chores, so no cross-session pace is ever borrowed. Several tasks in flight at once are treated as overlapping, not as a queue.
• Allowance drift plots the foreman tank against the account week, both as % of their own allowance, so a flat band is 1:1 — both tanks emptying together, nothing stranded at the reset. A band that opens says one wall arrives while the other allowance is still half full, and which way it opens says what to do: foreman ahead, push work down to the workers; account week ahead, more of it can run at the top. The projection line dates where each lands at its own reset if today's pace holds.
• Next up is the between-windows view: every dated estimate the page already carries — task dues, list landings, tanks emptying and resetting, the rung topping out — re-sorted onto one clock, soonest first. Context-compaction ETAs stay on each session's own card; they are session detail, not fleet coordination. Nothing on it is a new estimate; it is the same independent figures ordered by when they land, so one glance says which window needs attention next and whether an allowance event beats the work in flight. Events more than 48h out stay off it, and the soonest one is repeated on the runway banner.
• Estimates are installer-style on purpose: rough, always visible, wrong in honest ways, refined by each refresh. A task-list ETA lengthening mid-op is data — it shows the impact of what else you're running. They are also deliberately many and deliberately independent: no figure here is derived from another, so when several move together that agreement is real evidence, and when one diverges that is where to look.
• No tool can show true "% complete" for open-ended agent work — task lists, resource runway, and the gated rung ladder are the honest progress measures.
• Lines of code counts every tracked text file at HEAD, grouped by pile, with sprites and engine sidecars counted as files but never as lines. The 24-hour figure beside it is git's own add/delete count over that window. It replaced a tile that summed each open session's edit counter — a number that fell whenever a terminal closed, because it described the windows rather than the work. Per-session edit counts still live on each session card, where they belong.
• Code churn is stated apart from everything else, because one vendored asset manifest can move 150,000 lines in an afternoon and would otherwise read as a heroic coding session. "Code alone" counts game code, tests, native, scripts and tooling; docs, evidence captures, generated data and assets are shown but kept out of that figure.
• Commit trailers are not model attribution. The by-trailer chart shows what the trailer string says, and D-043 rules on exactly this: the trailer records the harness's configured string, not the model that ran the session. A trailer naming Sonnet is strong evidence — nothing writes it by accident — while the majority string proves nothing. HANDOFF-META: model= is the attribution record.
• The suite curve and the rulings count are free by-products. Every gate capture under docs/evidence/ states its own test and assert totals, so that folder was already a time series nobody had to keep; docs/DECISIONS.md is parsed the same way for the register count and the three newest rulings.
• The rung panel (Build tab) is read straight off the repo, not off a model: docs/GOALS.md names each rung's gate legs, every capture under docs/evidence/ records which legs came back green, and HANDOFF-META names the open rung. Nothing here costs a token to keep current, and the squares only move when a gate runs.
• Two dates, never averaged. "Whole operation" dates the ladder by flat commit pace — every remaining rung one average interval long. "Size-weighted" dates it by gate legs, at hours-per-leg measured on rungs that actually closed (close-to-close, so the planning time before the first commit is counted). When the two disagree, that gap is the information. A rung past its sized budget is shown overrunning rather than given an invented finish time, and no date is projected past a rung whose row names no legs.
• Everything below the dashed rule is judgment — a foreman's filed estimate, not a measurement. It carries who filed it and when, greys out when stale, and is scored against the rung's real close date once that lands, so the track record ("runs late by 12h typically") is visible beside the next estimate. No entries filed = no overlay; the measured facts above stand alone.

Phone ready

• This page — one URL: https://watchtower.alienwitchgames.com; bookmark it on the phone's home screen.
• Remote Control — /rc in a session, scan the QR with the Claude app: live streaming + steering, push notifications when a session needs input or finishes a long turn (both toggles enabled).
• Happy — npm i -g happy, then happy claude: full E2E-encrypted mirroring on iOS/Android. Third-party relay — a deliberate trust decision.
• ntfy.sh / Telegram hooks — pushes from Stop/PermissionRequest hooks; claude-ntfy-hook supports Windows.

Windows desktop widgets one command

Terminal & history one command

• ccstatusline — richest off-the-shelf status line: npx -y ccstatusline@latest. Would replace the custom line; the custom line's runs-out ETA is what it lacks.
• claude-monitor — full-screen TUI with multi-session burn and depletion forecasts: uv tool install claude-monitor.
• claude agents — built-in fleet view of background sessions (working / needs input / done / failed).
• Grafana build — OpenTelemetry export + dashboard 25255 for token/cost history across days; phone-viewable via the Grafana app. No cap data in OTel — complements this page.

Patterns for multi-day operations