Billing Telemetry Dashboard — Feasibility Study

Status: research. This document does NOT constitute financial or procurement advice. Vendor API details reflect publicly-available documentation as of 2026-04-30. All pricing should be verified directly with each vendor before acting on cost estimates.

Commissioned: 2026-05-01 UTC — Kristerpher Authored by: raxx-pm-bot (initial study, PR #750) Updated: 2026-04-30 UTC — raxx-research-bot per-vendor billing API deep-dive Update source: research branch research/billing-vendor-api-research

Update summary (read this first)

The 2026-05-01 commission identified two vendors that need re-verification before the partial-go recommendation in PR #750 holds up:

• Anthropic API — Kristerpher confirmed: "not feasible" — the Admin API cost-report endpoint exists but is gated to non-individual organizations (Team/Enterprise tier). Current Anthropic account is individual / self-serve, so the API path is closed for Raxx today.
• GitHub Actions — Kristerpher confirmed: "Enterprise only." GitHub's legacy /users/{user}/settings/billing/actions and the org equivalent endpoints have been superseded by the Enhanced Billing platform, which exposes budget management endpoints scoped to enterprise/organization budgets and admin/billing-manager identities. Personal Pro accounts no longer have a documented programmatic billing endpoint.

This update redoes the per-vendor research for the remaining nine vendors, recomputes spend-weighted coverage with the two confirmed gaps, and revises the recommendation + operator action items accordingly.

The decision shifts from partial-go (PR #750) to defer or scope-down (this update), because programmatic spend-coverage drops below the threshold once Anthropic and GitHub Actions are excluded.

Background

Kristerpher's request (2026-05-01 UTC): add a Billing section to console.raxx.app showing real-time monthly costs per vendor, end-of-cycle projections, color-state warnings, and email-on-breach alerts. The hard constraint is completeness — a partial dashboard that silently omits a spend category creates a false sense of security. The feature is only worthwhile if every active cost source is accounted for or explicitly acknowledged as a manually-entered line item.

The existing console epic (#146) and customer-billing console epic (#403) cover Stripe/subscription-side billing for Raxx's own customers. This study is scoped entirely to Raxx's own vendor/infrastructure costs — what Raxx pays out, not what customers pay in.

Related issue: #726 (GitHub Actions billing posture, runner strategy + cost tracking).

1. Vendor API research — verdict table

Each vendor was checked against the same 8 questions: 1. Does the vendor expose a billing or usage API? 2. What's the API endpoint (full path)? 3. What scope/auth is required? 4. What does the response include — current period spend, per-line-item, rate-limit info? 5. Cost to call the API. 6. Lag between charge and API visibility. 7. Plan-tier requirement (free / paid / enterprise). 8. Verdict: API-trackable / derivable / instrumentation-required / dashboard-only.

1.1 GitHub Actions — confirmed gap (Enterprise only)

1.2 Cloudflare — partial (subscription endpoint only, not usage)

1.3 Heroku — feasible but requires global scope (not a read-only key)

1.4 AWS Cost Explorer — feasible (best vendor coverage)

Covers Lightsail + S3 + KMS in one API call.

1.5 Postmark — derivable (counts × rate)

1.6 Anthropic API — confirmed gap (Admin API requires non-individual org)

1.7 Infisical — flat / $0 (no API needed)

1.8 Domain registrars — fixed (annual, amortizable)

1.9 Google Workspace — fixed flat (no API for direct customers)

1.10 1Password — research blocked (subscription status unknown)

1.11 Slack — fixed / $0 (Enterprise-only API, not on our tier)

1.12 AWS Lightsail bandwidth overage — addendum to §1.4

Captured under §1.4 (AWS) but called out separately because it has overage risk and lag:

• Each Lightsail bundle includes a monthly transfer allowance (e.g., $5 plan = 1 TB/mo).
• Overage is charged at $0.09/GB above included amount.
• Cost Explorer surfaces this as part of the Lightsail line item only after monthly close, not in real-time.
• Mitigation: Lightsail's CloudWatch metric NetworkOut (free to read via cloudwatch:GetMetricStatistics) tracks outbound bytes in real-time. The collector compares NetworkOut vs bundle allowance and projects overage cost without waiting for Cost Explorer.

1.13 OpenAI / Other LLM Vendors

Per project memory, OpenAI is not currently used. Confirmed not in scope.

1.14 Ubicloud (CI runners, contingency)

2. Coverage Analysis (revised)

2.1 Coverage table summary

2.2 Spend-weighted coverage calculation

Best-estimate total monthly spend (mid-estimate):

Coverage by category (spend-weighted, mid-estimate):

Combined "trackable without manual operator intervention each cycle": API-trackable ($35) + Derivable ($5) + Fixed-hardcoded ($23) = $63 of $134 = 47%.

Combined "trackable + operator-entered manual": $63 + $71 manual = $134 of $134 = 100% of spend — but only if the operator enters Anthropic + GH Actions overage figures every cycle.

2.3 Comparison to PR #750

PR #750 estimated 77% programmatic coverage assuming Anthropic + GitHub Actions were both either API-trackable or instrumentable. With both confirmed gaps:

The 47% figure assumes the operator does not enter manual values. If the operator commits to a reliable monthly manual-entry workflow for Anthropic + GH Actions overage, total coverage approaches 100% — but this is exactly the "false sense of security" risk Kristerpher flagged: a dashboard with manual-entry blanks is only as accurate as the operator's monthly diligence.

3. Recommendation (revised)

Call: Defer the full feature; ship a scoped-down "Fixed-Cost Dashboard" instead.

Rationale: programmatic coverage at 47% sits well under the 80% bar. Closing the gap requires either (a) Anthropic Team-plan upgrade + admin-key provisioning, or (b) an internal token-instrumentation card, or (c) accepting manual operator entry as a permanent mode. None of those are decided today. Building the full real-time-projection-with-alerts feature on top of a 47% base creates the exact misleading-completeness risk that sparked this commission.

Three concrete paths forward

Path A — Defer entirely until Anthropic gap closes. Wait until either Raxx upgrades Anthropic to Team tier OR the token-instrumentation card is approved + shipped. Re-run this study at that point. No console work between now and then.

Path B — Scope-down to "Fixed-Cost Dashboard" (recommended). Ship a reduced version that covers only the categories where coverage is high: - AWS (Cost Explorer API — real-time, projected) - Heroku (invoice API — real-time, projected) - Cloudflare (zone subscriptions — flat per-zone) - Plus all flat/fixed items: Infisical, domains, Google Workspace, 1Password, Slack, GitHub Actions $4 base.

This ships ~$58 of $134 = ~43% of spend with full programmatic confidence, plus another $5 derivable (Postmark + CF usage proxy) = ~$63 / 47% confident.

Explicitly excludes Anthropic + GH Actions overage. The dashboard shows a banner:

"Variable LLM and CI overage costs (estimated $60–$80/mo) are not tracked in this view. See Anthropic console + GitHub billing page for those figures."

This is honest, not misleading. Operator gets value (real visibility into the half they can track) without the risk of manual-entry-rot in the half they can't.

Path C — Full build with manual-entry blanks (NOT recommended). Build the full feature, accept that Anthropic + GH overage are operator-entered each cycle, label them clearly. Risk: operator forgets to enter monthly, dashboard silently under-reports, false confidence. Violates the completeness constraint.

Recommendation: Path B.

Path A is also defensible. Path C should be rejected unless Kristerpher explicitly accepts the manual-entry-rot risk.

4. Operator Action Items (revised)

The PR #750 operator-action list had 11 items, several of which assumed Anthropic + GH APIs were viable. Revised list:

Items intentionally omitted from this revision: - Token-instrumentation for Anthropic — explicitly out of scope per commission rules. - GitHub Enterprise Cloud upgrade — not contemplated; cost vastly exceeds the visibility benefit. - Cloudflare workaround feature requests — too long-tail to commit to.

5. Decision tree for Kristerpher

Q1: Are we comfortable shipping a dashboard that omits Anthropic + GH overage entirely
    (with a "see vendor console" banner for those two)?

    ├── Yes → Path B (Fixed-Cost Dashboard)
    │         ├── Provision keys per items 4, 5, 6 above (~1–2 hours operator time)
    │         ├── PM files implementation cards for collectors: AWS, Heroku, CF zones
    │         ├── PM files cards for fixed-line entries: domains, GWS, 1Password,
    │         │   Slack, Infisical, GH base $4
    │         └── Rough LOE estimate: ~10 dev-days (vs ~20 in PR #750)
    │
    └── No → Q2

Q2: Are we willing to upgrade Anthropic to Team tier ($30 minimum/mo for 5 seats)
    OR approve a separate token-instrumentation card?

    ├── Yes → Path A (defer full feature until that lands; revisit study)
    │
    └── No → Path A (defer) OR Path C (full build with manual blanks, accepting risk)
              Strongly recommend Path A — Path C trades one risk (no dashboard)
              for a worse risk (dashboard with hidden gaps).

6. UX Design notes (carried forward from PR #750, revised)

The UX in PR #750 §3 still applies for Path B with two changes:

1. Add a "Not in this view" footer card listing the excluded vendors (Anthropic, GH Actions overage) with vendor-console deep-links. Honest about the gap.
2. Drop the "instrumented" coverage_type from the data model (it's not used in Path B). Keep api, derived, manual, fixed. The manual type is reserved for future use if Path C is ever revisited.

Color thresholds, alerts, drill-in views all carry forward unchanged.

7. Architecture sketch (Path B)

Carried from PR #750 §4 with two simplifications:

• Drop anthropic_collector.py from Phase 2.
• Drop GitHub overage tracking; keep the flat $4/mo fixed line.
• Add cloudflare_subscription_collector.py to sum zone subscription prices.

Schema unchanged. Aggregator unchanged. Alert pipeline unchanged.

LOE estimate (revised):

Path B saves ~4 dev-days vs PR #750's full plan; the tradeoff is the Anthropic + GH overage ~$71 of mid-estimate spend remaining off-dashboard.

8. Sources and References

Primary research (this update)

• Heroku Platform API Reference — invoice endpoints — https://devcenter.heroku.com/articles/platform-api-reference (sections: Invoice, Invoice Address, Team Invoice, Enterprise Account Daily/Monthly Usage)
• Heroku OAuth scopes — https://devcenter.heroku.com/articles/oauth#scopes (confirms global scope required for /account/invoices/*)
• AWS Cost Explorer API — GetCostAndUsage reference — https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html
• AWS Cost Explorer pricing — https://aws.amazon.com/aws-cost-management/aws-cost-explorer/pricing/ ($0.01 per request, hourly granularity surcharge)
• AWS Cost Explorer user guide (data freshness) — https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html
• Cloudflare Zone Subscription Get — https://developers.cloudflare.com/api/resources/zones/subresources/subscriptions/methods/get/ (returns price USD + rate plan)
• Cloudflare billing usage docs — https://developers.cloudflare.com/billing/usage-based-billing/ (confirms no REST API for usage dashboard)
• Postmark Stats API — https://postmarkapp.com/developer/api/stats-api (counts API; no billing/invoice endpoints)
• Postmark pricing (Basic/Pro/Platform per-1000 overage rates) — https://postmarkapp.com/pricing
• Anthropic Admin API overview — https://platform.claude.com/docs/en/build-with-claude/administration-api ("The Admin API is unavailable for individual accounts")
• Anthropic Cost Report endpoint schema — https://platform.claude.com/docs/en/api/admin-api/usage-cost/get-cost-report
• Infisical pricing — https://infisical.com/pricing (Free / Pro $18 per identity / Enterprise custom)
• GitHub Billing REST endpoints — https://docs.github.com/en/rest/billing/billing (only Advanced Security on personal/org docs; legacy endpoints not listed)
• GitHub Enhanced Billing — https://docs.github.com/en/rest/billing/enhanced-billing (org admin / billing manager required, public preview)
• Slack admin.users.list — https://docs.slack.dev/reference/methods/admin.users.list (Enterprise plan only)
• Google Admin SDK Reports — https://developers.google.com/admin-sdk/reports/v1/get-start/getting-started (activity/usage only, no billing data)
• 1Password developer docs (Events API + Users API; no billing API) — https://developer.1password.com/docs/events-api/

Carried from PR #750

• CI cost analysis (Raxx-internal): docs/business/ci-cost-analysis-2026-04-25.md
• GH Actions billing posture issue: #726
• Existing customer billing console epic: #403 (out of scope for this study)
• Console operator admin epic: #146
• Original PR: #750

Appendix A — Original PR #750 study (carried for reference)

The sections below are the original full study from PR #750 (raxx-pm-bot, 2026-04-30). They are retained verbatim so reviewers can compare the original assumptions (Anthropic API trackable, GitHub Actions REST billing endpoint working) against the updated findings above. Where the two diverge, the revised sections (1–8) above are authoritative; the appendix is historical context.

A1. Vendor Inventory (original)

1.1 GitHub Actions

1.2 Cloudflare

1.3 Heroku

1.4 AWS (Lightsail + S3 + KMS)

All three AWS services share a single billing API surface — AWS Cost Explorer — so they are addressed together.

1.5 Postmark

1.6 Anthropic API

1.7 Infisical

1.8 Domain Registrars

1.9 Google Workspace

1.10 1Password

1.11 Slack

1.12 AWS Lightsail — Bandwidth Overage Addendum

Captured under §1.4 (AWS) but called out separately because it has overage risk:

• Each Lightsail bundle includes a monthly transfer allowance (e.g., $5 plan = 1 TB/mo).
• Overage is charged at $0.09/GB above the included amount.
• Cost Explorer does not surface this separately from the Lightsail line item in real-time — it appears in the month-end bill.
• Mitigation: use Lightsail's CloudWatch metric NetworkOut (available via CloudWatch API) to track outbound bytes. This is free to read. The collector can check NetworkOut vs bundle allowance and project overage cost directly without waiting for Cost Explorer.

1.13 OpenAI / Other LLM Vendors

Per project memory, OpenAI is not currently used. Confirmed not in scope. If added later, OpenAI has a usage API at GET /v1/usage (organization-level) that returns token counts by date — billing derivation is possible.

1.14 Ubicloud (CI runners, contingency)

A2. Coverage Analysis (original)

2.1 Coverage table summary

2.2 Coverage calculation

Establishing coverage requires a spend-weighted view, not a vendor-count view.

Best-estimate total monthly spend (excluding Anthropic spikes):

Coverage by API status (mid-estimate basis):

Without Anthropic: feasible + partial covers ~$57 of ~$74 non-Anthropic spend = 77% — just under the 80% threshold at mid-estimates.

With manual entry for flat-cost gap vendors (domains, Google Workspace, 1Password): flat gaps become 100% "known" even without APIs. That brings coverage to ~$76 of ~$74 non-Anthropic spend — effectively 100% of non-Anthropic spend.

The Anthropic gap is the critical open question. Anthropic is the single largest variable cost and has no confirmed billing API.

Two coverage scenarios:

Conclusion: Scenario C is not acceptable under Kristerpher's constraint. The feature goes or does not go based on whether Anthropic can be covered — either via their API (Scenario A) or internal token instrumentation (Scenario B).

A3. UX Design (original)

3.1 Navigation

New top-level console nav item: Billing — positioned after Status, before Security. Separate from the customer-billing console (#403), which is about what customers pay Raxx. This section is what Raxx pays vendors.

3.2 Main dashboard layout

• Aggregate card at top: "Total this cycle: $X.XX | Projected end-of-cycle: $Y.YY". Color state drives border color.
• Per-vendor cards below in a grid: vendor name, current-cycle spend (or derived estimate), projected end-of-cycle, % of expected monthly budget.
• Each card has a last-updated timestamp and a "data lag" caveat where applicable (e.g., "AWS: as of yesterday — 24hr lag").
• Manual entry badge: flat-cost vendors (domains, Google Workspace, 1Password) show a pencil icon indicating the amount is operator-entered, not live-pulled.
• "Unconfirmed" badge: Cloudflare, Postmark, and any other partial-coverage vendors show a warning badge indicating the amount is derived/estimated, not invoice-exact.

3.3 Color thresholds

Applied per vendor and to the aggregate card:

Budget is defined as "expected monthly cost" — either the flat plan cost (for known-flat vendors) or a rolling 3-month average (for variable vendors). Operator can override per vendor.

3.4 Per-vendor drill-in

• Trend graph: this month vs prior month (line chart, day-by-day accumulation).
• Line-item breakdown where the API provides it (e.g., GitHub: linux/macos/windows minutes separately; AWS: Lightsail vs S3 vs KMS).
• "Approaching limit" advisory: "At current rate, GitHub Actions will consume 3,200 minutes this cycle. Included: 3,000. Projected overage: ~$1.20."

3.5 Alert configuration

• Thresholds are configurable per vendor and for the aggregate.
• Email destination: defaults to ops@raxx.app; operator can add additional addresses.
• Frequency: one alert per threshold breach per billing cycle (not per poll cycle — avoid flooding).
• Alert types: approaching (70%), near-breach (90%), breached (100%).

A4. Architecture Sketch (original)

4.1 Components

┌─────────────────────────────────────────────────────────┐
│  Billing Collector (cron job, runs in console process)  │
│                                                         │
│  Per-vendor modules:                                    │
│    github_collector.py     → GitHub Billing API         │
│    heroku_collector.py     → Heroku Platform API        │
│    aws_collector.py        → AWS Cost Explorer API      │
│    cloudflare_collector.py → CF GraphQL Analytics API   │
│    postmark_collector.py   → Postmark Stats API         │
│    anthropic_collector.py  → internal token telemetry   │
│    manual_entry_store.py   → operator-entered values    │
└─────────────┬───────────────────────────────────────────┘
              │ write snapshots
              ▼
┌─────────────────────────────────────────────────────────┐
│  Postgres table: vendor_billing_snapshots               │
│  (vendor, period_start, period_end, fetched_at,         │
│   current_spend_cents, projected_spend_cents,           │
│   coverage_type, raw_payload, is_manual_entry)          │
└─────────────┬───────────────────────────────────────────┘
              │ read
              ▼
┌─────────────────────────────────────────────────────────┐
│  Aggregator (runs after each collection cycle)          │
│  - Sums vendor snapshots into period_total              │
│  - Computes projection: (spend_to_date / days_elapsed)  │
│                          × days_in_month                │
│  - Writes aggregate row to vendor_billing_snapshots     │
│    where vendor = '_aggregate'                          │
└─────────────┬───────────────────────────────────────────┘
              │ read
              ▼
┌─────────────────────────────────────────────────────────┐
│  Console UI — Blueprint: billing.py                     │
│  - GET /billing → dashboard view                        │
│  - GET /billing/<vendor> → drill-in view                │
│  - POST /billing/manual → update manual-entry values    │
│  - GET /api/billing/summary → JSON for polling/refresh  │
└─────────────────────────────────────────────────────────┘
              │ trigger
              ▼
┌─────────────────────────────────────────────────────────┐
│  Alerter (runs after aggregator)                        │
│  - Compares projected spend vs budget thresholds        │
│  - Deduplicates: one alert per vendor per breach/cycle  │
│  - Sends via Postmark (no-reply@raxx.app)               │
│  - Writes alert_sent=True to alert_state table          │
└─────────────────────────────────────────────────────────┘

4.2 Data store

Existing console uses SQLite for development. The billing snapshot table can start in SQLite (single-writer, append-only, low frequency) and migrate to Postgres when the console moves to a multi-process deployment. The vendor_billing_snapshots table is a natural append-only log with no contention risk.

Schema sketch:

CREATE TABLE vendor_billing_snapshots (
    id                    INTEGER PRIMARY KEY AUTOINCREMENT,
    vendor                TEXT NOT NULL,           -- 'github', 'heroku', 'aws', '_aggregate', etc.
    period_start          DATE NOT NULL,           -- first day of billing cycle
    period_end            DATE NOT NULL,           -- last day of billing cycle
    fetched_at            TIMESTAMP NOT NULL,
    current_spend_cents   INTEGER NOT NULL,        -- spend to date, in cents
    projected_spend_cents INTEGER,                 -- end-of-cycle projection, in cents
    coverage_type         TEXT NOT NULL,           -- 'api', 'derived', 'manual', 'instrumented'
    is_manual_entry       BOOLEAN NOT NULL DEFAULT FALSE,
    raw_payload           TEXT,                    -- JSON blob from vendor API response
    notes                 TEXT                     -- human-readable caveat if any
);

CREATE INDEX idx_vbs_vendor_period ON vendor_billing_snapshots (vendor, period_start);

CREATE TABLE billing_alert_state (
    id          INTEGER PRIMARY KEY AUTOINCREMENT,
    vendor      TEXT NOT NULL,
    threshold   TEXT NOT NULL,   -- 'approaching', 'near_breach', 'breached'
    period      DATE NOT NULL,   -- billing cycle start date
    fired_at    TIMESTAMP,
    email_sent  BOOLEAN NOT NULL DEFAULT FALSE
);

CREATE UNIQUE INDEX idx_bas_dedup ON billing_alert_state (vendor, threshold, period);

4.3 Collector scheduling

The console currently uses Flask's application context. The collector runs as a scheduled cron (APScheduler within the Flask process, or a separate GH Actions workflow job). Recommended: GH Actions nightly job (billing-collect.yml) that hits a console API endpoint to trigger collection, keeping the console stateless as a runner. AWS Cost Explorer rate guidance: maximum 4 calls/day to stay under $0.50/mo in API costs.

4.4 Anthropic instrumentation workaround

Since Anthropic has no confirmed billing API, the internal workaround is:

1. All agent calls go through a wrapper (console/app/services/agent_dispatcher.py or similar).
2. The wrapper records model, input_tokens, output_tokens, timestamp to an agent_token_log table.
3. The anthropic_collector.py reads from this table, applies the current per-token rate (stored in a config table), and produces a current_spend_cents estimate.
4. Rate is operator-configurable (update when Anthropic changes pricing).
5. This method is accurate to within pricing-rounding; it covers all dispatched agents because they all go through the same SDK.

A5. LOE Estimate (original)

Phase 1 — Discovery + auth setup (3–5 operator-days, not all dev time)

Phase 2 — Per-vendor collector implementations

Phase 3 — Aggregator + projection logic

Phase 4 — Console UI

Phase 5 — Alert pipeline

Phase 6 — GH Actions collector workflow

Total LOE summary

Buffer (integration, edge cases, unexpected API quirks): add 20% = ~20 dev-days end-to-end.

This is sizeable but front-loaded by Phase 1 decisions — if Anthropic's billing API does not exist and the token-instrumentation path is rejected, approximately 6 dev-days of work falls away (Anthropic collector + agent wrapping). That would reduce LOE to ~14 dev-days.

A6. Recommendation (original — superseded)

Call: Partial-go

The billing telemetry dashboard is feasible — but only with a bounded workaround for the two largest gaps.

Condition 1 (mandatory): Anthropic API coverage must be resolved before implementation begins. The recommended path is internal token instrumentation (Phase 2, Anthropic collector via agent_token_log). This is technically sound and gives accurate spend data. If Kristerpher accepts this approach, the Anthropic gap is closed.

Condition 2 (acceptable): Cloudflare, Postmark, Google Workspace, domains, and 1Password can be covered by derived metrics + operator manual entry. These are predictable, low-volatility costs. The dashboard must show "estimated" or "operator-entered" badges clearly on those cards so there is no false precision.

With both conditions met: coverage is ~100% (full API for GitHub/Heroku/AWS; instrumentation for Anthropic; manual/derived for flat/partial vendors). The feature satisfies Kristerpher's completeness constraint.

Without Condition 1: Anthropic is 45% of variable spend with no visibility. The feature would be misleading. Do not build.

Minimum viable vendor set (Phase 1 go)

To deliver value quickly and validate the architecture before all collectors are built:

1. GitHub Actions — highest operator anxiety (overage risk), best API, quickest to build. Ship first.
2. AWS — second-highest spend, best forecast API (GetCostForecast), covers Lightsail + S3 + KMS in one call.
3. Heroku — meaningful dyno cost, live current-period invoice via API.
4. Anthropic (token instrumentation) — must resolve the gap; do this concurrently with Phase 1.

These four cover ~70% of estimated mid-range spend programmatically and are all technically confirmed feasible. Ship these four, then add Cloudflare/Postmark/manual-entry vendors in Phase 2.

A7. Operator Action Items (original — superseded)

These are required regardless of the final go/no-go decision. The first three are needed to properly scope the decision itself.

A8. Gaps Requiring Research (original)

The following items remain unresolved as of 2026-04-30 and must be answered before implementation cards are written:

1. Anthropic billing API — Does one exist? The implementation path (token instrumentation vs API polling) changes the Anthropic collector card significantly.
2. Postmark Account API invoice endpoint — Does GET /accounts/invoices return current-period data? Determines whether Postmark is "feasible" or stays "partial".
3. Heroku current dyno tier — Needed to size the baseline spend estimate and confirm the current-period invoice format matches what is documented.
4. Ubicloud billing API — Only relevant if Ubicloud runners are activated (see #726). Confirm once Ubicloud is live.

Once Kristerpher has confirmed items 1 and 3, the PM can file the full set of implementation cards (~15 cards across Phases 2–6).