---

name: cost-alert description: > Review the configured cost alert rules and the alerts currently fired on the Agent Monitor dashboard, then explain exactly what tripped and why. Uses /api/alerts (fired feed) and /api/alerts/rules (definitions). Use when checking spend alerts or asking why a cost alarm went off.

Cost Alert

Audit the spend guardrails: which rules exist, which have fired, and what tripped them.

Input

The user provides: $ARGUMENTS

This may be empty (review everything), "unacked" (only unacknowledged alerts), or a rule name to focus on.

Data Sources

| Endpoint | Returns | |----------|---------| | GET /api/alerts/rules | { rules: [{ id, name, rule_type, config, enabled, cooldown_seconds }] } — the guardrail definitions | | GET /api/alerts | { alerts: [{ id, rule_id, rule_name, rule_type, session_id, agent_id, message, details, triggered_at, acked }], total, unacked, limit, offset } — the fired-alert feed, newest first. ?unacked=true filters to unacknowledged |

What the rule types mean

| rule_type | config | Fires when | |-------------|----------|------------| | token_threshold | { total_tokens } | A session's cumulative tokens (input + output + cache_read + cache_write) cross the ceiling — the spend-relevant guardrail | | event_pattern | { event_type?, tool_name?, summary_contains?, count?, window_minutes? } | Matching events reach count within the window | | inactivity | { minutes } | An active session goes quiet for minutes | | status_duration | { status, minutes } | An agent is stuck in working/waiting for minutes |

For cost work, focus on token_threshold. Translate its token ceiling to dollars using the blended rate from /api/pricing/cost (total_cost / total_tokens) so the user sees the alarm in money terms.

Report Sections

1. Configured guardrails

Table from /api/alerts/rules: name, type, the human-readable threshold (e.g. token_threshold → 12,500,000 tokens ≈ $50.0000), enabled state, cooldown. Flag rules that are disabled or have no spend-relevant guardrail at all.

2. Fired alerts

Table from /api/alerts: rule name, triggered_at, scope (session/agent id), acked, and the message. Lead with the unacked count. Honor "unacked" input by querying ?unacked=true.

3. What tripped — per alert

For each fired alert, parse details and explain in plain terms: e.g. "session X crossed 12,500,000 tokens (threshold 12,500,000) ≈ $50.12 at current rates — your token_threshold budget rule fired." Tie the observed value back to the rule's config.

4. Next steps

Suggest acknowledging stale alerts (POST /api/alerts/:id/ack or /api/alerts/ack-all), tightening or loosening a threshold, or arming a missing budget rule (point to the budget-set skill).

Output

Markdown tables. Currency as USD to 4 decimal places; token counts with thousands separators. Make the link between each fired alert and the rule that produced it explicit — never report a raw alert without saying which rule tripped and why.