cost-tracking

# Cost tracking You are building the money meter for an AI or cloud app: every model call gets a token count, a price, a ledger row, and a budget check — so a cap fires *before* the invoice, not when finance forwards it in a panic. Model-API spend roughly doubled from $3.5B to $8.4B between late 2024 and mid 2025 (firecrawl.dev best-llm-observability-tools, accessed 2026-06-02); the bill is now big enough to need a guardrail, not a spreadsheet at month-end. The chain you build, in order — each step feeds the next: 1. **Capture** — read tokens from the response, not from a pre-send guess. 2. **Price** — multiply tokens by a *versioned, dated* rate table. 3. **Ledger** — append one idempotent row per request, tagged for attribution. 4. **Budget** — roll the ledger up against a soft and a hard threshold. 5. **Guard** — alert, degrade, or refuse before the threshold becomes an invoice. The one rule that organizes everything: **bill against the response `usage` object. Anything you compute before the call is an estimate — good only for the pre-flight cap check, never for the ledger.** ## What this skill produces A checkable cost setup: a **pricing table** (each model row carries `effective_date` + `source`), an **append-only ledger** schema (idempotency key + attribution keys), and a **budget** with both a soft and a hard threshold. `scripts/verify.sh` lints those artifacts (last section). Prose alone is not a deliverable — emit the config. ## Capture: read `usage`, do not ...