Define a spend budget for Claude Code and, optionally, create a cost alert rule that fires when usage crosses the limit, via POST /api/alerts/rules on the Agent Monitor dashboard. Reads current spend from /api/pricing/cost to size the budget sensibly and explains every rule field before writing. Use when setting a spend limit or wiring up a budget guardrail.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Help the user define a spend budget and turn it into a live cost guardrail on the Agent Monitor dashboard.
The user provides: $ARGUMENTS
This is the budget to set — e.g. "$50/month", "$10/week", or "200000 tokens".
If a period is omitted, treat it as a monthly budget and say so. If no number is
given, read current spend first and propose a target.
| Endpoint | Returns |
|---|---|
GET /api/pricing/cost | { total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] } — current spend, used to size the budget and compute the blended $/token rate |
GET /api/alerts/rules | { rules: [{ id, name, rule_type, config, enabled, cooldown_seconds }] } — existing rules, so you don't create a duplicate guardrail |
POST /api/alerts/rules | Create a rule. Body: { name, rule_type, config, enabled?, cooldown_seconds? }. Returns { rule } |
The dashboard's alerting engine fires on tokens, not dollars. The spend-relevant
rule type is token_threshold, whose config is { total_tokens } — it fires when
a session's cumulative tokens (input + output + cache_read + cache_write) cross the
threshold. To turn a dollar budget into a token ceiling:
blended_rate_per_token = total_cost / total_tokens # from /api/pricing/cost
token_ceiling = budget_dollars / blended_rate_per_token
Compute total_tokens by summing the four token columns across the cost breakdown.
| Field | Meaning |
|---|---|
name | Human label shown in the alert feed (e.g. "Monthly $50 budget"). Required, non-empty. |
rule_type | "token_threshold" for a spend guardrail. (Other types: event_pattern, inactivity, status_duration — not spend-related.) |
config.total_tokens | Positive integer token ceiling. A session crossing it fires the alert. Derive from the dollar budget as above. |
enabled | true to arm immediately (default), false to stage it. |
cooldown_seconds | Minimum seconds between re-fires for the same scope. Default 300. Raise it (e.g. 3600) so a single overspending session doesn't spam the feed. |
From /api/pricing/cost: total_cost, total tokens, and the blended $/Mtok rate. State how much of the proposed budget is already consumed.
Restate the parsed budget (amount + period). If converting dollars → tokens, show the blended rate and the token_ceiling arithmetic.
List any token_threshold rules from /api/alerts/rules so the user sees what is already in place; warn before creating a near-duplicate.
Show the exact JSON body you would POST, with each field annotated. Then give the ready-to-run command (only run it on explicit confirmation):
curl -s -X POST http://localhost:4820/api/alerts/rules \
-H 'Content-Type: application/json' \
-d '{"name":"Monthly $50 budget","rule_type":"token_threshold","config":{"total_tokens":12500000},"cooldown_seconds":3600}'
On success, echo the returned rule (id, name, config). Remind the user that the rule is per-session token usage — to track a whole-period dollar budget, pair it with /ccam-cost-guard:forecast and the spend-forecast skill.
Markdown with the snapshot, the conversion math, and the annotated rule body. Currency as USD to 4 decimal places; token counts with thousands separators. Only POST after the user confirms — never create a rule silently.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Inspect fired CCAM alerts and manage alert rules for token thresholds, event patterns, inactivity, and status duration. Use when acknowledging alerts, creating or editing a rule, checking cooldowns, or connecting alert rules to webhook targets.
日本語の概要は準備中です。原文の説明を表示しています。
Identify anomalous sessions using Agent Monitor data — cost outliers from the pricing engine, token anomalies (cache miss spikes, compaction baseline surges), unusual event type ratios (PreToolUse/PostToolUse gaps, APIError clusters), behavioral deviations from workflow intelligence (complexity score outliers, error propagation anomalies), and sessions with abnormal metadata (extreme turn_count, high thinking_blocks, zero turn_duration).
日本語の概要は準備中です。原文の説明を表示しています。
Produce a detailed report on APIError events from Agent Monitor data — counts over time, which sessions and models are affected, and the likely root cause (rate limits, overload/529, or context-window pressure) inferred from each event's summary and data payload. Use when API errors spike or when you need to explain why requests are failing.
日本語の概要は準備中です。原文の説明を表示しています。
Benchmark one session (or a small recent set) against the rolling average using Agent Monitor data — cost, total tokens, tool count, and workflow complexity score — and report where each metric lands as a percentile of the population. Tells you whether a session was normal, cheap, or an outlier. Use when judging whether a session was typical or out of band.
日本語の概要は準備中です。原文の説明を表示しています。
Analyze prompt-cache effectiveness for Claude Code usage from the Agent Monitor dashboard — cache hit rate (total_cache_read / (total_cache_read + total_input)), cache_write vs cache_read reuse, cache-read vs cache-write spend, and the sessions with the poorest reuse. Pulls token totals from /api/analytics, per-session detail from /api/sessions, and dollar splits from /api/pricing/cost. Use when diagnosing cache spend or deciding whether prompt caching is paying off.
日本語の概要は準備中です。原文の説明を表示しています。
Report concurrency and parallelism for a session — how many agents ran in parallel, concurrency-lane utilization, peak parallel width, and serialization bottlenecks (sequential chains that could have run as parallel lanes) — using the Agent Monitor workflow intelligence API. Use when checking whether a multi-agent session used parallelism efficiently.
日本語の概要は準備中です。原文の説明を表示しています。