Skip to main content

Spend Dashboard: Real-Time AI Cost Visibility Per Team

Keeptrusts gives you real-time AI cost visibility per team by combining quick status on /overview with detailed breakdowns on /usage, where you can filter by date, provider, and gateway, then group the explorer by team to see which teams are generating requests, tokens, and cost right now rather than waiting for an invoice or a month-end export.

Use this page when​

  • You need to understand which team is driving current AI spend.
  • You want to separate normal usage growth from a cost anomaly.
  • You need a practical route from summary metrics to request-level evidence.

Primary audience​

  • Primary: Finance-aware platform operators and Technical Engineers
  • Secondary: Technical Leaders managing budget accountability across teams

The problem​

Most cost reporting is too late to be useful. By the time a monthly bill lands, the expensive behavior has already happened. That is especially painful with AI workloads because one routing mistake, one oversized prompt pattern, or one runaway team integration can create real cost in a short window.

Organization totals are not enough on their own. If you only know that spend is up, you still do not know why. Was it one team? A single provider? A gateway-specific launch? An increase in requests, or just larger prompts? Without that breakdown, cost response becomes guesswork.

That is the operational gap the current Keeptrusts usage surfaces close. The system already has request counts, token totals, spend logs, budgets, and wallet context. The important question is how to read the pages in a way that actually changes decisions.

The solution​

The useful reading pattern is to start broad, then narrow.

Use /overview first when you need a fast posture check. That page tells you whether the bigger picture looks healthy: current period spend, queue state, gateway status, and recent runtime signals.

Then move to /usage for analysis.

That page matters because it combines several layers in one place:

  • summary cards for total cost, requests, tokens, and provider concentration
  • spend logs for request-level cost records
  • budget alerts for over-budget and near-budget states
  • workflow and cache-outcome groupings for cost patterns
  • an explorer that can group by provider, model, user, or team

The team grouping is what makes the page operationally useful for chargeback and accountability. The explorer resolves team IDs into team names when available and also keeps a No team bucket visible, which is often where attribution problems show up.

That means the page answers practical questions quickly:

  • Which team is driving the current spike?
  • Did spend rise because request volume rose, or because model/provider choice changed?
  • Is unattributed traffic increasing?
  • Is a budget warning tied to one team or broad platform use?

Implementation​

The simplest workflow is to treat /usage as a drill-down page, not as a dashboard you skim once and leave.

  1. Start on /overview and note the current period spend and any visible queue or health anomalies.
  2. Open /usage and set the time window to match the anomaly you are investigating.
  3. If you suspect one integration or incident window, add a gateway or provider filter first.
  4. Use the explorer controls to group by team.
  5. Compare cost, request count, and token count together. A team with modest request volume but very high token totals is a different problem from a team making many small requests.
  6. Review the spend-log list to see whether the expensive traffic comes from one model, one provider, or one time period.
  7. If a budget or wallet warning is already present, connect the alert back to the affected team before deciding on reallocation or policy changes.

This is a reliable pattern for a real anomaly investigation:

  1. A budget alert appears or period spend jumps unexpectedly.
  2. Open /usage for the relevant date range.
  3. Group by team and sort by cost.
  4. Identify whether one team dominates or whether the increase is distributed.
  5. If one team dominates, filter further by provider and model.
  6. Open related logs or runtime evidence to see whether the increase came from a product launch, routing change, prompt expansion, or accidental retry loop.

The page is also useful when nothing is wrong. Weekly review of grouped-by-team cost tells you whether your current wallet allocations and budget thresholds still match reality. If the same team remains at the top every week, that may justify a stable allocation change rather than repeated exception handling.

One subtle but important detail is that cost visibility is not limited to a finance audience. Engineers need it too. If a team rolls out a new prompt pattern and average cost per request doubles, the fix is often technical, not financial. You may need better routing, caching, model selection, or policy tuning. The spend page gives the operator a way to see that quickly.

Another useful practice is to pair /usage with /history?view=activity when you need to connect cost to actor or workflow shape. /usage tells you what the spend profile looks like. Activity tells you which kinds of actions or users are behind it.

Results and impact​

Teams that use the spend dashboard well stop treating AI cost as a lagging finance artifact. It becomes an operating metric.

That changes behavior in practical ways. Budget alerts are handled before wallets run dry. Attribution gaps are found while the relevant rollout is still fresh. High-cost teams can be coached or re-routed based on current evidence instead of retrospective blame.

It also makes budget conversations more credible. Instead of saying, "Engineering seems expensive this month," you can say, "Support traffic rose 40% after the staging-to-production rollout, but average tokens per request stayed flat, so the increase is volume-driven rather than a model-selection regression." That is a much more actionable discussion.

Key takeaways​

  • Use /overview for fast posture and /usage for actual cost analysis.
  • Group the usage explorer by team when you need accountability, allocation, or anomaly triage.
  • Read cost, request count, and token count together; one metric alone is not enough.
  • Treat No team rows as a real operational signal, not cosmetic noise.
  • Pair spend analysis with activity or event evidence when you need to explain why cost changed.

Next steps​