> ## Documentation Index
> Fetch the complete documentation index at: https://help.dash.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Dashboard sections

> Tour of the AI Spend Agent dashboard — Overview, Usage, Anomalies, Violations, Action Plan, and Recovery.

The AI Spend Agent dashboard is organized into sections you navigate from the left rail. Each section answers a different question: how much are you spending, where is it going, what's wrong, what to do about it, and what's been recovered.

<Note>
  Every section reflects the last 30 days of data pulled from your connected providers. To pull fresh data on demand, use [Sync now and Refresh insights](/integrations/ai-tokens/connect-providers).
</Note>

<Note>
  If the agent's top-bar status is amber and reads `· action needed`, one of your provider connections has a revoked or unusable admin key. Syncing is paused for that connection and the numbers on this page are frozen at its last successful sync until you rotate the key. See [Connection sync health](/integrations/ai-tokens/connect-providers#connection-sync-health).
</Note>

## Overview

Overview is the headline view: how much your team is spending on AI and how that's trending.

* **30-day spend** — Total cost across Anthropic and OpenAI over the last 30 days.
* **Tokens (30d)** — Total tokens consumed, split between input and output.
* **Cache-read rate** — Share of input tokens served from a prompt cache, plus the raw read vs. written token counts. High cache-read rates mean you're paying less for repeated context.
* **Models tracked** — How many distinct models the agent has seen usage from.
* **Price / 1M tokens** — Blended cost across input and output tokens in the window, expressed per million tokens. Useful as a headline unit price you can compare across periods or after switching models.
* **Cost / request** — Average cost per provider-reported request. The average is taken only over rows the provider reports a request count for, so the cost basis is the request-reporting spend rather than total spend. Anthropic's usage API is token-only, so if all your usage is Anthropic this shows `—` with `provider does not report request counts`.
* **Daily spend chart** — Per-day spend bars with a 7-day moving average line to smooth out day-to-day noise.

Above the KPIs, a **provider tab strip** ("All providers" plus one tab per connected provider that has usage) scopes every metric on the page to that provider. Only providers with usage get a tab — a connected provider that hasn't produced any spend yet won't appear.

Overview is the fastest way to spot a spend spike or a sudden drop in cache efficiency.

## Usage

Usage decomposes the same 30 days by dimension. Each section shows a spend-mix donut alongside a ranked table.

* **Spend by model** — Every model that produced cost in the window, with input, output, cache-write and cache-read tokens per model plus each model's share of total spend.
* **Spend by provider** — The same breakdown grouped by Anthropic vs. OpenAI.
* **Spend by API key** — Which keys are driving cost, useful for isolating a runaway integration.
* **Spend by team member** — Cost attributed to each team member, ranked. Click a row to open that member's drill-down page — see [Team member drill-down](#team-member-drill-down).

Use Usage when Overview surfaces a change and you need to attribute it: which model got more expensive, which provider is driving the shift, and whether cache usage moved along with it.

### Cascading filters

The filter bar above the breakdowns is **cascading**: each dropdown only shows values that are still possible given the ones above it. Pick a provider and the Model dropdown narrows to that provider's models; pick a model and API Key narrows to keys that used it; and so on down through Team Member. If an upstream change makes a downstream selection impossible (for example, switching to Anthropic while an OpenAI model is picked), the downstream dropdown resets to **All** on its own.

### Team member drill-down

From the **Spend by team member** breakdown, click a row to open a per-member view for the last 90 days. It shows:

* **Spend, Tokens, Cache-read rate, Requests** — The member's headline numbers, with team-median comparisons on cache-read rate and team-p90 comparisons on tokens per request so you can see whether they're an outlier or in line with the rest of the team.
* **Model mix** — A donut of which models the member's spend went to.
* **Recommendations** — Per-member optimization suggestions with an estimated annual saving where the agent can quantify one.
* **Findings for this member** — Every open finding attributed to that member's email, so you can see anomalies and violations tied to their usage in one place.

The member view is a drill-down of the same data, not a separate audit — findings match what appears elsewhere in the dashboard.

## Anomalies

Anomalies collect behavioral and efficiency findings the agent produced from your usage. Each row is one finding, tied to a specific rule (e.g. `spend_spike_anomaly`, `cache_efficiency_outlier`, `model_overkill`, `stale_key_active`).

Categories covered here:

* **Usage patterns** — Spend spikes, off-hours usage.
* **Governance** — Stale keys, untagged keys, workspace concentration, subscription-cheaper opportunities.
* **Cache efficiency** — Cache-write overspend, cache-read opportunities, cache-efficiency outliers.
* **Model efficiency** — Over-powered model choices, low-output request bursts, tokens-per-request outliers.

You can filter findings by **severity** (high / medium / low), **date range**, and **category**. Click any row to expand it — you'll see the human-readable explanation, the attribution (model, key, workspace, or user where available), the pricing basis the agent used, and a **Confidence** score (0–100%) for rules that produce one. Confidence is separate from severity: a low-confidence high-severity finding is worth double-checking before acting; a high-confidence low-severity finding is usually safe to treat as real.

## Violations

Violations are the disputable findings: billing and pricing discrepancies where the provider's charge doesn't match what pricing says it should have been. These findings can back a refund claim in [Recovery](/integrations/ai-tokens/recovery).

Categories covered here:

* **Billing** — Billing discrepancies (point-in-time and windowed), rate & discount summaries.
* **Pricing data** — Stale pricing entries, unknown-model observations.

Violations use the same filters and expand-for-detail interaction as Anomalies. Each finding is categorized into either Anomalies or Violations — a single finding never appears in both.

## Action Plan

The Action Plan is your prioritized to-do list. It takes every finding — anomalies and violations — and ranks them by **estimated dollar impact**, biggest first.

At the top of the page you'll see the total identified opportunity: the sum of estimated impact across every open finding. Each item shows the finding title, its severity, the human explanation, and its individual impact. Work top-down to pick up the highest-value fixes first.

<Note>
  Refund claims aren't tracked on Action Plan. Anything that can be recovered as a refund lives in [Recovery](/integrations/ai-tokens/recovery) — Action Plan focuses on the optimization work you own.
</Note>

## Recovery

Recovery is the home for refund claims filed against billing violations. See [Recovery and refund claims](/integrations/ai-tokens/recovery) for the full walkthrough.