---
name: cost-report
description: Use when the organization wants to see or tune spend - "what are we spending on", "cost report", "which tasks escalated", "can anything run cheaper", or on a periodic review. Aggregates escalation records and tier usage from the changelog, flags drift, proposes demotion candidates. Triggers on /cost-report.
---

# Cost Report — aggregate, flag, propose

The spend policy's audit surface. It reads only in-repo records — the changelog and the escalation entries in it. **Never** query a billing API or parse session logs; a question only those could answer (raw token counts, per-session spend) is out of scope — say so rather than estimate.

## Procedure

1. **Collect** every entry in `docs/history/changelog/` carrying `Class: escalation` since the last report, plus the tier usage the other entries record. Match on the keyword only — the `escalate` skill owns the entry's shape.
2. **Aggregate by routing row**: per task type, count escalations up, demotions passed, and one-off vs. standing promotions.
3. **Flag drift**:
   - Repeated upward escalations on a row ⇒ the tier is under-provisioned; propose moving the row up.
   - Demotion experiments that keep passing on a row ⇒ over-provisioned; propose moving it down.
   - A frontier dispatch with no matching row or escalation entry ⇒ a routing-guardrail violation. Surface it; never fold it into the row's normal usage.
4. **Report in chat**: a table — row · tier · escalations · demotions · proposal — then the proposed routing-table edits. Append each standing proposal to `docs/history/backlog.md`.

## Rules

- **Propose, never apply.** The routing table is `CLAUDE.md` policy and moves only by its own reviewed edit.
- **Evidence or silence** — every proposal cites its entries by filename.
- **Measure the policy, never the people.** Escalation counts tune the table; never frame them as individual performance data.