Cost alert
Skill hoangsonww/Claude-Code-Agent-Monitor/plugins/ccam-cost-guard/skills/cost-alert
🚀 A real-time monitoring dashboard for Claude Code, built with SQLite3, Node.js, Express, React, Vite, TailwindCSS, and WebSockets. It tracks sessions, agent activity, tool usage, and subagent orchestration, providing live analytics, a Kanban status board, status notifications, a cute buddy, and an interactive web UI/MacOS/Windows native app.
npx -y skills add hoangsonww/Claude-Code-Agent-Monitor --skill cost-alertAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.0 KB, as published. Nobody here has run it
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.