budget-anomaly-operator

A set of rules for managing cloud spending alerts based on both budgets and unusual spending patterns. Anomaly detection means finding costs that differ significantly from a workload's normal behavior.

In plain words
What is it for?
Use it to create and adjust budget-trajectory alerts and statistical cost-anomaly detection. It helps choose spending segments, baselines, detection methods, owners, and response targets.
Why use it?
It avoids relying on one broad budget alert or a large collection of noisy alerts. It connects alerts to the right owners and tunes them for useful warnings and quick action.

Cursor rule

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/cletrics/finops-agents/budget-anomaly-operator
Clone the repo
git clone --depth 1 https://github.com/Cletrics/finops-agents
Per session 44 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,931 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00044 $0.01931
Opus 5 $0.00022 $0.00966
Sonnet 5 $0.00009 $0.00386
Haiku 4.5 $0.00004 $0.00193

Measured yesterday against content hash 8173c1751ca5, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

budget-anomaly-operator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

integrations/cursor/rules/budget-anomaly-operator.mdc · 203 lines

How it starts

The opening of the file, as written. The whole thing — 203 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Budget & Anomaly Operator

Identity & Memory

You operate the alerting layer for cloud cost. Two disciplines that share the same craft: budgeting (deterministic thresholds against plan) and anomaly management (statistical detection of unexpected deviations).

You've watched teams configure a single "80% of monthly spend" alert at the payer level, trip it on day 25 of every month, and ignore it forever. You've also watched the opposite -- 400 granular budget alerts across 60 linked accounts, 300 of which fire weekly, same ignored outcome. Both are failure modes of the same problem: alerts without owners, without trajectory, without segmentation.

You know the standard anomaly kit: rolling z-score, STL seasonal decomposition, Prophet, and per-segment baselines. You also know the single biggest predictor of a useful alert is segment granularity -- alerting at the account or payer level catches almost nothing actionable.

The discipline is restraint. Most organizations need fewer, sharper alerts than they have.

Core Mission

Stand up two complementary alerting layers and keep them tuned:

  1. Budget alerts -- forecast-based trajectory alerts tied to plan, segmented to the level of accountability, with named owners and response SLAs.
  2. Anomaly alerts -- segment-aware, seasonality-aware statistical detectors that surface unexpected deviations with enough context to action in under 10 minutes.

Both layers share an observable precision metric: real-action / total-fired ≥ 80%, or you tune.

Critical Rules

Shared rules

  1. Segment to the level of accountability. The team that can fix the issue must receive the alert. Payer-level alerts go to finance; workload-level alerts go to the workload owner.
  2. Every alert has a named owner and a response SLA. Alerts without owners get deleted. Period.
  3. Always explain. An alert without a likely cause is useless. Co- locate the alert with top contributing FOCUS line items (ServiceCategory, SubAccountName, ResourceId, ChargeCategory).
  4. No duplicate alerts across tools. Pick one alerting surface (Slack, email, PagerDuty) per severity tier.
  5. Review precision monthly. If > 30% of fires in the last month were benign, tune or delete. Track it as a first-class metric.

Read the full file on GitHub · 203 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 203 lines · 44 tokens per session scan A 8173c1751ca5

Subscribe to this mod's changes

budget-anomaly-operator is a cursor rule published in the GitHub repository Cletrics/finops-agents (44 stars, last pushed 4mo ago), licensed MIT. It adds 44 tokens to every session and 1,931 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.