AI agent spend reporting: per-run cost visibility for autonomous systems

Why vendor dashboards aren't enough for agent spend reporting

Stripe's Dashboard, Twilio's Monitor, and Resend's email log all provide transaction-level records. But they share three gaps that make them inadequate as the sole reporting source for AI agent operations:

The minimum audit log schema for agent spend reporting

Effective spend reporting starts with the right columns in the audit log. The minimum schema that enables all four reporting layers:

CREATE TABLE audit_log (
    id            TEXT PRIMARY KEY,
    agent_run_id  TEXT NOT NULL,  -- workflow run ID, task ID, or session ID
    agent_name    TEXT NOT NULL,  -- "billing-agent", "notification-agent"
    vendor        TEXT NOT NULL,  -- "stripe", "twilio", "resend"
    endpoint      TEXT NOT NULL,  -- "POST /v1/payment_intents"
    cost_usd      REAL,           -- parsed from vendor response
    vendor_txn_id TEXT,           -- Stripe PaymentIntent.id, Twilio SID, Resend message ID
    policy_verdict TEXT,          -- "allowed", "cap_hit", "endpoint_blocked"
    called_at     TEXT NOT NULL,  -- ISO 8601 timestamp
    vault_key_id  TEXT            -- which vault key authorized this call
);

The cost_usd column is the critical one that vendor dashboards don't provide in a per-call, agent-tagged format. It's parsed from vendor response data: Stripe's amount field (in cents, divided by 100), Twilio's price field on the status callback, Resend's fixed per-email rate from the account tier. A proxy that forwards calls to these vendors can parse this data at call time and write it to the audit log before returning the response to the agent.

Four query patterns for agent spend reporting

1. Per-run cost summary

-- Cost breakdown for a single agent run
SELECT
    vendor,
    endpoint,
    COUNT(*) AS call_count,
    SUM(cost_usd) AS total_cost_usd,
    MIN(called_at) AS first_call,
    MAX(called_at) AS last_call
FROM audit_log
WHERE agent_run_id = 'temporal/billing-workflow/run_abc123'
GROUP BY vendor, endpoint
ORDER BY total_cost_usd DESC;

This answers the incident-response question "what did run X actually do and how much did it cost?" in under a second, without pulling logs from Stripe and cross-referencing timestamps.

2. Per-agent aggregate (fleet view)

-- Per-agent spend for the last 7 days
SELECT
    agent_name,
    vendor,
    COUNT(*) AS total_calls,
    SUM(cost_usd) AS total_spend_usd,
    AVG(cost_usd) AS avg_cost_per_call,
    MAX(cost_usd) AS max_single_call_usd
FROM audit_log
WHERE called_at >= datetime('now', '-7 days')
GROUP BY agent_name, vendor
ORDER BY total_spend_usd DESC;

This identifies which agents are the highest spenders, which vendors are being used most, and whether any agent's average cost per call is anomalously high (a signal of calls with larger-than-expected amounts).

3. Per-vendor daily trend

-- Daily spend per vendor for the last 30 days
SELECT
    date(called_at) AS day,
    vendor,
    COUNT(*) AS calls,
    SUM(cost_usd) AS spend_usd
FROM audit_log
WHERE called_at >= datetime('now', '-30 days')
GROUP BY date(called_at), vendor
ORDER BY day DESC, spend_usd DESC;

This is the time-series view that shows whether Stripe spend is accelerating (daily total growing), whether a new agent deployment increased costs, and whether spend is flat or seasonal. This data is available in the vendor's billing portal, but not filterable by agent or tagged with run context.

4. Projected monthly spend

-- 30-day spend projection based on 7-day rolling average per agent
SELECT
    agent_name,
    vendor,
    SUM(cost_usd) / 7.0 AS avg_daily_spend_usd,
    SUM(cost_usd) / 7.0 * 30 AS projected_monthly_spend_usd
FROM audit_log
WHERE called_at >= datetime('now', '-7 days')
GROUP BY agent_name, vendor
ORDER BY projected_monthly_spend_usd DESC;

Run this weekly to give engineering and finance a forward-looking view. If the projection exceeds budget, you can reduce per-run caps or adjust run frequency before the month ends.

Alerting triggers for agent spend anomalies

Spend reporting should drive automated alerts, not just dashboards engineers check manually. Three alert patterns that catch real incidents:

How Keybrake provides the data source

Keybrake is a proxy that sits between your agents and their vendor APIs. Every call that passes through the proxy is written to an audit log with agent_run_id (from the agent_run_label you set on the vault key), vendor, endpoint, cost_usd_parsed (extracted from the vendor response), and policy_verdict. This is the audit log that drives all four query patterns above.

The proxy provides what vendor dashboards can't: per-call, per-agent attribution available immediately after the call, not hours later in a billing report. The GET /audit endpoint queries the audit log with filters by agent_run_id, agent_name, vendor, and time range — the same queries above can be run via the API without maintaining your own database.

Get early access

Related questions

Further reading

• AI agent audit trail — the foundational data model for tracking what agents did, with the minimum four-column schema and the three implementation paths.
• AI agent cost management — the three-axis decomposition of agent costs (LLM tokens, vendor API spend, infrastructure) and why they require different controls.
• AI agent Stripe spend cap — why Stripe's native billing alerts are post-charge (not pre-charge) and the distinction between a cap and an alert for spend reporting.
• AI agent multi-tenant isolation — when serving multiple customers, per-tenant spend reporting requires per-tenant vault keys so audit queries can filter by tenant without cross-contamination.