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

• wk % used is how much of the weekly allowance is spent — not a countdown. Runs out in … is the planning number: at the current pace, when the allowance is exhausted, with the rough wall-clock moment in brackets. Won't run out means the weekly reset arrives first.
• The 5-hour block works the same: caps in ~X or won't cap; when rate-limited, usable again in X is the cooldown.
• The fable weekly tank is not the foreman's own thinking — it is the only weekly allowance this account has. Two facts, both read off the endpoint rather than assumed. Structural: of every weekly meter the API can report — seven_day, seven_day_opus, seven_day_sonnet, seven_day_cowork — all are null here; the single surviving entry is weekly_scoped named for Fable. There is nowhere else for a week's spend to land, so an Opus implementer's tokens land there too. Measured: over a 1h45m stretch in which Fable emitted zero tokens, the tank still climbed 4 points at 2.07%/h — its normal rate — while 5.8M cost-weighted tokens of other models ran beneath it. So a foreman that spends a long-horizon task idle, waiting on implementers, still empties this tank at close to full speed: the 39 subagents are the spend, and the card names their share of the drain for exactly that reason. Read it as "how long this operation can keep running", never as "how hard the foreman is thinking".
• 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. Anthropic's limits are one account-wide pool, so the money split remains an estimate.
• 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.
• 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.
• Every ETA here is conditioned on how long the thing has already been running, and each one says which of three readings it is giving. Inside the sample: a typical run takes x, you are y in, so x−y remains. Past the typical run: the estimate is rebuilt from only those past runs that lasted longer than this one already has, because something already late is evidence of a long run, not of an imminent finish — which is why a figure can jump outwards as a rung drags. Longer than anything ever measured: no date at all, and the box says so. The alternative is a floor, and a floor is not an estimate — this page shipped one for a while, max(now + 1h, …), and the step ETA read a constant 59 minutes for as long as it was wrong.
• Medians, not means, and never a blend. One 5.7-day pause in ten rungs drags the mean rung from 13h to 31h, so the arithmetic runs on medians. Where two independent measures exist — pace now against pace average, rung pace against gate-leg sizing — both are printed side by side and neither is averaged into the other: two rough numbers that agree tell you something, one number blended out of both tells you nothing, and the gap between them is itself the information.
• 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; open it from the claude.ai artifact gallery on the phone.
• 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