Agent Loss Prevention

Evidence, not another token chart. Read-only analysis of what your agents cost and what each success costs.

Start free audit See a sample report

Works with OpenAI, Anthropic and xAI (Grok) cost and usage APIs.

FindingsSpend spike on project support-agentSynthetic example

FND-0142High

Spend spike on project support-agent

Two days at 3.4× the 14-day median, right after a deploy.

Classification: Anomalous spend
Above median: $2,779.94
Period: 15–16 Oct 2026 (UTC)
Confidence: High
Status: Experiment running

Daily spend · support-agentSpike window

Detected by scheduled audit2 days ago
Note from Priya Raman1 day ago
Retry storm after release 4.12.
Approved by a second person20 h ago
Cap retries at 2. Rollback: max_retries=5.
Experiment running on production canarynow

Six steps, from a key to a measured saving.

Connect
An organization admin key, used read-only, validated and encrypted. No SDK, no proxy.
Reconcile
Daily cost records with stable keys. Recent days stay provisional, and revisions are logged.
Detect
Six versioned detectors compare every project, workspace and model with its own history.
Explain
Each finding carries its evidence records, baseline, confidence and risks.
Monitor
Scheduled re-scans and alerts on complete days, by email, webhook or to your agent.
Verify
Approved experiments on production traffic turn a proposal into a measured saving.

Detectors in this release. Deterministic, unit-tested and versioned.

Every finding records the detector version and the snapshot it ran on, so a result can be reproduced. No detector can write a verified saving.

FindingsDetector registry

Detector	What it finds	Writes	Needs
spend_spike1.0.0	Days where spend on a project/workspace/model exceeds 2.5× its trailing 14-day median (minimum 7 days of history).	Anomalous spend	Cost data, 7+ days of history
spend_concentration1.0.0	A single project/workspace/model accounts for at least 60% of spend in the period.	Observed spend	Cost data
budget_burn1.0.0	Month-to-date spend run-rate projects above the organization’s configured monthly budget.	Observed spend	Cost data and a monthly budget
sustained_growth1.0.0	Week-over-week spend growth above 20% for three consecutive complete weeks on one dimension.	Observed spend	Cost data, 4+ weeks
outcome_data_gap1.0.0	Material spend with no outcome telemetry — an analysis gap, never presented as waste.	Observed spend	Cost data
failed_run_spend1.0.0	Estimated spend on runs whose failure was verified (customer-reported, system-verified or human-reviewed).	Potential saving	Outcome telemetry
prompt_caching1.0.0	Models with material uncached input spend and a low cached share. Sizes moving a stated share of input to the provider’s cached rate.	Observed spend	Cost data
batch_processing1.0.0	Large standard-tier workloads on providers with a batch discount. Sizes moving a stated share to asynchronous batch processing.	Observed spend	Cost data
model_routing1.0.0	A premium model carrying most spend while a much cheaper model from the same provider is already in use. Rates are measured from your own cost and token data.	Observed spend	Cost data
output_length1.0.0	Models where output tokens make up most of the cost. Sizes a stated reduction in output length.	Observed spend	Cost data
saving_guard1.0.0	A verified saving whose billing signal (cache share, routing share, output ratio or batch share) has given back half or more of its gain in the last 7 days.	Observed spend	Cost data

Not in this release: price-mix recommendations (only with verified current prices), real-time spend blocking, and automatic changes to your agents.

How we size a lever. On your own cost data, with every assumption stated.

Savings levers are detectors too: deterministic, versioned and reproducible. Each one reads a signal in your data, applies the provider facts it records and one explicit assumption, and writes a potential saving. Nothing more.

Your data, not a price list
Signals come from your cost line items: token types, service tier, observed cost per token per model.
One stated assumption
The share of eligible traffic is never claimed as known. It is an explicit, editable assumption on the lever.
Facts with a source
Each lever records the provider facts it used, with the source and the date they were checked.
Never added up
Scenarios can overlap, such as caching and batching on the same spend, so each lever is shown on its own.

Savings planLevers

Lever	Signal in your data	Provider facts	Scenario	Writes
Prompt caching	Uncached input cost per model against cached input cost, from token-type line items.	Anthropic: Cache reads 0.1× base input (0.05× on Opus and Sonnet 5.5). 5-minute writes 1.25×, 1-hour writes 2×. OpenAI: Automatic on prompts of 1,024 tokens or more. Cached input costs at most 50% of the base rate. xAI: Cached input 75–85% cheaper on Grok 4.x.	25% of uncached input moved to cache × (1 − effective cached cost), with each cached prefix reused at least four times.	Potential saving
Batch processing	Standard-tier spend per project, and the batch share where the provider reports it.	OpenAI: Batch: 50% off, 24 h window. Flex is billed at Batch rates. Anthropic: Message Batches: 50% off, stacks with caching, results within 24 h. xAI: Batch: 20% off on Grok 4.x models.	20% of the project’s spend can wait up to 24 h × the provider’s batch discount.	Potential saving
Model routing	Observed blended cost per token for each model: your cost divided by your tokens, so no price list is needed.	All providers: Per-token rates differ 10–20× between frontier and small models.	20% of premium-model tokens routed to the cheaper model × (1 − cheap rate ÷ premium rate).	Potential saving
Output length	The output share of each model’s cost. The lever applies when output is 60% or more.	Most models: Output tokens cost 4–5× input.	15% fewer output tokens (max tokens, structured output, terser formats) × output cost.	Potential saving
Retries and failed runs	Verified failed runs and retries, from the outcome telemetry you send.	Your telemetry: No provider rate is involved: the cost is what failed runs already spent.	Estimated cost of verified failed runs.	Potential saving

Provider facts checked 26 Oct 2026. A what-if control on each lever previews other assumptions without changing the stored amount. A potential saving becomes verified only through an approved experiment on production traffic.

Monitoring and governance, yes. Real-time blocking, no.

Provider billing APIs report with a delay and we’re not in your request path, so we don’t claim to stop spend as it happens. We catch it the day it shows up and govern what you change.

Monitoring: Daily re-scans, threshold and growth alerts, freshness warnings, email and signed webhooks.
Governance: Proposals with rollback plans, approval by a second person, recorded experiments, an audit trail.
Blocking: Not offered. Use provider limits or your gateway for hard caps; we’ll tell you where they’re needed.

AlertsAll rulesSynthetic example

RuleStatus14 days

Daily spend above $1,500

daily_spend > $1,500.00

Triggered 16 Oct

Monthly budget 80% reached

budget_burn ≥ 80%

Armed

Provider sync stale for 12 h

sync_staleness > 12 h

Armed

Cost per success above $0.13

cost_per_success > $0.13

Armed

Cost per successful task. The number billing data can’t give you.

Send outcome events (run id, workflow, status, how the outcome was verified, estimated cost). Audon computes cost per verified success and finds spend on failed runs. Fields that look like prompts or personal data are rejected.

Telemetry API

DevelopersPOST /v1/telemetry/events

{
  "events": [{
    "run_id": "run_8f2c",
    "workflow_id": "support-triage",
    "started_at": "2026-10-21T09:14:02Z",
    "result_status": "succeeded",
    "result_verification": "system_verified",
    "estimated_provider_cost_minor": 42,
    "currency": "USD"
  }]
}

Methodology and the words we use.

Observed spend — invoice-aligned, provider-reported cost for the selected UTC days. Sourced from the OpenAI organization Costs API and the Anthropic Cost Report API. Recent days are provisional and are re-reconciled on every sync.

Anomalous spend — observed spend with features that indicate a possible problem (e.g. a day more than 2.5× its trailing 14-day median). It is not a saving: it may be legitimate demand.

Potential saving — a modelled reduction if a proposed change works, under stated assumptions.

Validated opportunity — a scoped, feasible change with supporting evidence and a computable expected benefit, confirmed by a person.

Verified saving — a measured reduction in cost per verified successful task in the latest recorded experiment on production traffic, approved and verified by people other than those who proposed it and recorded the results, with no success-rate drop greater than 2 percentage points, no p95 latency increase greater than 20%, and at least 30 verified successes per window:

measured saving = (cost per success before − cost per success after) × successful tasks after

Cost per verified successful task = Σ attributable run costs ÷ count of verified successful runs. When the denominator is zero, or cost is missing, the value is unavailable — never 0.

Cash impact. Lower usage reduces future usage-based invoices. Under prepaid commitments it frees capacity rather than reducing near-term cash.

Monitoring vs blocking. Alerts evaluate complete UTC days of provider billing data, which can lag by hours. They are monitoring, not real-time spend blocking.

Money. Amounts are stored as exact integer micros (10⁻⁶ of the billed currency). Currencies are never summed together.

Same results. A smaller AI bill, proven.

Start free audit See a sample report

Free 30-day audit. Read access only, no card, revoke any time.