Spend

Cost broken down by agent, by customer, by feature.

How costs get attributed

Every llm_call event carries token counts, provider, and exact model string. AgentPing resolves these against a server-side rate card and writes the resulting cost onto the event. The SDK never sends cost_usd on llm_call events.

Default per-million rates ship for every Anthropic and OpenAI model AgentPing knows about; override any row per team from the rate card settings. Cache reads are priced separately from fresh input. Cache creation is billed as regular input.

If an llm_call references a model that isn't on your rate card, its cost lands as 0 and the model appears in the dashboard's unpriced-models list. Adding the row prices future events; historical events stay until you backfill.

Tagging runs for attribution

Per-customer and per-feature rollups depend on tagging at start.

with agentping.run("support-triage", customer_id="acme-corp", feature="ticket-routing") as run:
    ...

const run = agentping.run("support-triage", {
    customerId: "acme-corp",
    feature: "ticket-routing",
});

run := agentping.Run("support-triage",
    agentping.WithCustomerID("acme-corp"),
    agentping.WithFeature("ticket-routing"),
)

The dashboard rolls cost up monthly by agent, customer, and feature. The headline metric is cost per successful run: total cost over runs that finished status=success and passed quality thresholds. A creeping number means a longer prompt, a more expensive model, or more retries per task.

Spend alerts

Per-agent z-score over the last 14 days. When today's spend goes more than 2.5σ above the rolling baseline (configurable per team), Spend fires through the agent's alert route. Catches stuck retry loops before the monthly invoice does.

Cost on heartbeats

Non-SDK heartbeats (n8n, GitHub Actions, /v1/ping) can pass cost_usd directly as a query parameter or JSON field. AgentPing trusts the number; there's no token data to compute from.