Admin
Verifying access…

You're signed in, but you're not on the admin allowlist.

Where the money went · last 30 days

Live Cloud Billing rollup fromfirebase_costs/{day}.by_service_gross — gross(list price before credits), the COGS line. Net-after-credits shows in the footer: a promotional credit can offset ~100% of net, which used to render Vertex AI as $0.00 here (#133). Counters fall back to the previous synced data when the daily billingSync cron hasn't refreshed yet — staleness shows in the footer.

Daily spend by service
Service30d7d7d share
Loading…
—

Included allowances · last 30 days

Gross is pre-credit, which is not pre-allowance. GCP applies an included quota before pricing, so free usage arrives as a row with real usage units and cost = 0 — no credit line, no cost_at_list value, nothing the bill can see. So the table above is list price of usage above the included tier, and this panel is what the tier absorbed (#2017). It is not cash and is never folded into COGS; it is the size of a subsidy that ends the moment a quota is crossed, which reads as a cost spike with no usage change behind it. Watch the headroom column, not the dollars.

The table below is GCP only. A vendor that bills nothing until a threshold emits no usage row for a billing fold to read, so those allowances are metered separately — see Vendor allowances below, which counts our own sends. Still uncovered: Firebase Auth (50k MAU), and three GCP SKUs whose allowance is real but whose rate won't solve against our own billing rows (Artifact Registry storage, Cloud Scheduler jobs, Secret Manager version storage) — a guessed rate would invent dollars. Tracked in docs/BUSINESS_SYSTEMS.md → Free-tier capacity (#2031).

Absorbed by SKU
SKUUsageBilledAbsorbed
Loading…
Headroom — closest to its cliff first
SKUUsed / quota%Runway
Loading…
Vendor allowances — metered from our own sends, not from a bill

Resend bills nothing until its free tier is gone, so no cost ledger can see it coming. Sends are counted in email_counters/{day}, whichsendEmail increments at the one point every transactional message passes through. The daily cap is the one to watch: our mail comes from batch crons, and a single recap run may attempt up to 500 sends against a 100/day allowance.

VendorUsed / cap%Over the cap
Loading…

Cost to serve a clip · last 30 days

Bar height is that day's clip-attributed spend ÷ clips analyzed, stacked by pipeline stage. Hatched segments are not a per-clip measurement: storage and computeare allocated — the day's real GCP bill spread flat across clips — and a stage can also show partly allocated when some of its spend arrived with no clip_id (today:movement_breakdown, because /explain doesn't send one yet). Both render hatched so an estimate can never read as a measurement (#133); the legend and tooltips say which is which. Marginal is list rate; invoiced is what actually billed — expect a large gap on tts, which is $0.00 invoiced today because a free tier absorbs it.

Daily $/clip stacked by stage
Stage30d $/clip7d $/clip7d share
Loading…
—

Per-clip cost distribution

Each clip bucketed by its first 24 hours of cost — a fixed window from that clip's own first analyze, not lifetime-to-date, so the spread is real variance between clips (long clips, Pro escalations, heavy narration) rather than an artifact of clip age. Clips younger than 24h are excluded because they have not finished accruing. The top bucket is open-ended — the expensive tail is the point of this chart. Always first-24h list cost, regardless of the marginal/invoiced toggle above: this chart answers how much clips vary from each other, not who absorbed the bill. Covers metered stages only — allocated infrastructure (storage, compute) is the day's GCP bill spread flat across clips, never a per-clip event, so it never enters this distribution even though it's counted in the stacked-bar total above. Expect this chart's numbers to run lower than that total.

Top spenders

Top clips →

Sums analyze.ok cost per uid inside the chosen window. Answers "which single user drove the spike" when the per-service breakdown above only tells you it was Vertex. Rows link into the user detail page.

UserCostCallsCost / call
Loading…

GitHub spend · last 30 days

Live rollup from github_costs/{day}, populated by the daily githubBillingSync cron. Counters fall back to the previous synced data when the cron hasn't refreshed yet — staleness shows in the footer.

Daily spend stacked by product
Product30d7d7d share
Loading…
—

Anthropic spend · last 30 days

Billed actuals from the Anthropic org Cost Report, synced daily by theanthropicBillingSync cron intoanthropic_costs/{day}. The org total spans four Workspaces — only plai-prod is product COGS; staging is dev and the two plai-ops-* workspaces are the Claude Code ops fleet (historically ~5× the product's own spend). Days synced before the 2026-07-31 workspace split have no per-workspace rows.

Agent is the odd one out: the other three come from billed actuals, but the Cost Report only resolves to a Workspace, soplai-ops-agents is ~20 workflows in one bar. The Agent view is per-run telemetry from agent_runs, priced from token counts — an estimate, and the only way to see which agent is the spend. Expect it to track the plai-ops-agents band without matching it exactly.

Daily spend stacked by model
Model30d7d7d share
Loading…
—

Agent fleet · roster & run economics

Every AI workflow in the fleet (agent-*,routine-*, docs-sync), whether its cron is on, and what it actually did: status/schedule/model come from the workflow files at this dashboard's build (2026-09-14 — runtime kill-switch variables like ROUTINES_KILL_SWITCH are invisible here); runs, per-run cost (estimated from token counts), and the 30-day trend come from live agent_runs telemetry. Where a run reported its models= line, the Model cell also shows which exact model id the declared alias (e.g. sonnet) resolved to. An agent with a schedule but no recent runs is the drift to look for.Cadence context: the fleet was deliberately cut on 2026-08-21 (PR #1874 — ops-digest to Mon/Wed/Fri,routine-* crons paused, usage-report cron off,release-train on Haiku), so a step down in theplai-ops-agents band after that date is policy, not an outage.

AgentStatusScheduleModelRuns 30dAvg $/runWork $/runAvg turnsctx/turn30d totalTrend
Loading…
—