Findings and the Action Plan

Every insight the AI Spend Agent produces is a finding. Each finding has a detection rule, an estimated dollar impact, a severity, and — where available — the attribution that pins it to a model, key, workspace, or user. This page explains how the agent generates findings, how they split between Anomalies and Violations, and how the Action Plan ranks them.

​

How findings are produced

1. Sync — The agent pulls usage and cost from your connected providers on a schedule, and on demand when you click Sync now.
2. Audit — When you click Refresh insights (or on the agent’s own audit cadence), the agent runs every detection rule against your current usage. This produces the finding set and the reconciliation summary for Recovery.
3. Attribute — Where the provider exposes it, each finding is tagged with the model, key, workspace, or user that caused it, plus the pricing basis used to compute the discrepancy or opportunity.

The Refresh insights button in the top bar of the agent holds an Auditing… state while the job runs and refreshes the dashboard the moment it finishes. See Connect providers.

​

Anomalies vs. Violations

Every finding lands in exactly one of two views, based on its category: The split matters for what you can do with each:

• Anomalies are optimization work — changes you make in your own stack (routing to a cheaper model, adding caching, revoking a stale key). They can’t be recovered as refunds.
• Violations are disputable — the provider charged you something that pricing says they shouldn’t have. Billing-discrepancy violations back the refund claims you file in Recovery.

Both views share the same explorer: a single table sorted by estimated dollar impact, biggest first, with date-range tabs above it (All time, 90 days, 30 days, 7 days). The date range is the only filter — there are no severity or category facets and no summary cards. Each row carries its severity badge and shows its rule’s category under the rule name. Click any row to expand the full explanation, attribution, pricing basis, confidence, and the period the figure was measured over.

​

One dollar basis per figure

Findings estimate dollars over different periods — a one-day spike, a 90-day window, or full history after a re-audit — so raw figures can’t be compared or summed. The explorer normalizes what each row shows in its $ impact column:

• A finding measured over multiple days shows a 30-day rate (≈$X/mo). This mirrors the audit report and the Overview Anomalies card, so a finding shows the same figure everywhere.
• A single-day event shows $X on the day.
• A finding with no stamped measurement period shows its raw figure.

The expanded row states the actual measurement period and the raw dollar total (Measured over: N days ($X total)), so the normalized rate is always traceable back to what was measured.

​

Recommended actions inline

Rules with a recommended action render it directly on the finding’s row (Recommended: <action>), so the anomaly and its fix read as one story. Where the finding carries a dollar figure and a measured period, the action is valued as worth ~$X/yr by annualizing that finding’s own figure over its own measured period.

​

Confirm-with-invoice badge

Billing-discrepancy findings whose underlying cost is estimated carry a confirm with invoice badge in the findings explorer and on the Action Plan. Estimated cost comes from providers whose usage API reports cost per project rather than per model. OpenAI reconciliations are treated as estimated across the board; Anthropic discrepancies aren’t. When you see the badge, treat the impact as a real signal to check against your provider invoice, not as a confirmed claim. See Confirmed vs. Potential recoverable for how the split feeds Recovery.

​

Advisory findings and the ”—” impact

Some findings are advisory: they surface real governance or context signals but have no direct recoverable dollar figure attached. The findings explorer and Action Plan render their Est. impact as — rather than $0 so you don’t read the zero as a bug. Advisory findings today include:

• cache_opportunity_absolute — The per-model, unattributed cache-hit gap. The attributed per-user cache_efficiency_outlier finding covers the same tokens, so the aggregate view is advisory to avoid double-counting savings.
• subscription_likely, pricing_stale, rate_discount_summary, billing_discrepancy_window, and pre-bill anomaly signals like spend_spike_anomaly and low_output_request_burst.

​

The Action Plan

The Action Plan is a single ranked list of every open finding — anomalies and violations combined — sorted by estimated dollar impact, highest first.

• The header shows the total identified opportunity: the sum of estimated impact across every finding in the list.
• Each row shows the finding’s title, severity, human-readable explanation, and its individual estimated impact.
• Work top-down. The highest-impact items are the ones worth doing first, regardless of category.

​

Severity

Every finding carries a severity: high, medium, or low. The detection rule sets severity based on how confident the agent is in the finding and how material the impact is likely to be. Severity is separate from dollar impact. A low severity finding can still be worth acting on if it recurs across many keys or workspaces, and a high severity finding isn’t always the biggest single line item.

​

Anomaly narratives

The anomaly detectors phrase their findings to match how confident the underlying math is:

• spend_spike_anomaly — When the 28-day baseline is nearly flat, dividing by a tiny standard deviation produces a very large sigma that isn’t meaningful. Instead of showing a number like “300sigma”, the explanation reads “far above a near-flat baseline”. Detection and severity still use the real deviation; only the reported sigma figure is suppressed.
• model_overkill — Estimated impact is a monthly savings rate, normalized to 30 days regardless of how long the audit window is. A 90-day backfill no longer reports roughly 3× the true monthly figure.
• stale_key_active — Impact is the ongoing (last-quarter) spend on the declining key, not the full-window total. Most of the whole-window total is history that’s already been spent, not budget at risk going forward. The explanation only invokes the “keys nobody owns” security angle when the key actually has no attributed owner.

​

When findings change

The agent re-derives findings on every audit. That means:

• A finding that no longer applies after your next audit disappears from the list.
• Estimated dollar impact can move up or down as the underlying usage window shifts.
• Opening a refund claim against a billing-discrepancy violation flips that finding’s claim-opened marker so you can’t double-file. The finding itself keeps showing until it’s fully resolved.