Agent metering UsageFlow
Agent metering that can stop the next call.
Agent metering tracks what each AI agent run consumes — tokens and spend — and attributes it to the customer behind it. UsageFlow adds runtime enforcement: policies that downgrade, cap, or block the next call based on that usage.
Free: 1 workflow with live policy. No credit card. Stripe sync is on paid tiers — see pricing.
What agent metering tracks
Agent metering records every model call an agent run makes — the tokens, the spend, the workflow — and ties it to one customer. That matters because an agent is a loop.
You ask it one question. It plans, searches, reads, hits a tool error, tries again, drafts, reviews and revises. Eight model calls for one answer, and every retry sends the whole conversation again.
A request counter sees eight separate requests. It doesn't know they belong to one customer's run, or that this customer has already spent most of their day's allowance. The first time you see the total is the invoice.
What a request counter sees
Eight calls, no owner, no limit.
POST /v1/messages 200 POST /v1/messages 200 POST /v1/messages 200 POST /v1/messages 200 POST /v1/messages 200 POST /v1/messages 200 POST /v1/messages 200 POST /v1/messages 200
What the ledger sees
One customer, one workflow, one running total.
identity cust_acme
workflow research-agent
calls 7 ran, 1 blocked
usage 202,000 tokens
policy route at 120,000
block at 200,000
result stopped at the cap
Metering vs. enforcement
Metering tells you what happened. UsageFlow decides what happens next. Before each call, it reads the customer's running total and applies your policy: allow, route to a cheaper model, cap the budget, or block.
| Metering only | Metering + runtime enforcement | |
|---|---|---|
| When it acts | After the run, in a report. | Before the next call runs. |
| What it can do | Show usage and alert. | Route to a cheaper model, cap, or block. |
| A runaway loop | Shows up on the invoice. | Stops at the customer's budget. |
Example: an agent run that reaches its budget
A customer has a $100 daily budget on the research-agent workflow. The policy routes to a cheaper model at $95 and blocks at $100.
Policy
Set in the Console. No redeploy.
identity cust_acme workflow research-agent at $95 route to a cheaper model at $100 block the next call
What happens
Each call is checked before it runs.
$0–95 requested model runs
$95–100 cheaper model runs
$100 next call blocked, provider
never contacted
trace requested vs executed
Meter an agent in TypeScript, Python or Go
You change the model call, not the agent. Use
@usageflow/vibe for TypeScript,
usageflow-vibe for Python, or the Go Vibe client. The rules live in the
Console.
-
Name whose budget the run spends
Replace the provider call with
usage.chatand pass the customer's identity and a workflow name. Use the same identity you use in Stripe. -
UsageFlow checks before every call
It reads the customer's running total and applies the policy: allow, route to a cheaper model, degrade, or block. Prompts still go from your server straight to the provider.
-
Handle the stop like any other result
A blocked call raises a rejection error and the provider is never contacted. Catch it and end the run with a clear message.
TypeScriptimport { usage, VibeRejectionError } from '@usageflow/vibe'; async function runAgent(customerId: string, task: string) { const messages = [{ role: 'user', content: task }]; for (let step = 0; step < 12; step++) { try { const turn = await usage.chat({ identity: customerId, // whose budget this run spends workflow: 'research-agent', // the policy that sets the cap provider: 'anthropic', model: 'claude-sonnet-5', messages, }); messages.push({ role: 'assistant', content: turn.content }); if (isDone(turn)) return turn.content; // your own stop condition } catch (err) { if (err instanceof VibeRejectionError) { return 'This run reached your usage limit.'; } throw err; } } } -
Bill what ran
Add a Stripe meter effect to the policy and each call's usage is reported to your Stripe meter. What you limit and what you invoice come from the same numbers.
Thresholds, models and who they apply to are edited in the Console and apply to the next call.
Agent metering tools compared
"Agent metering" covers four kinds of tools. They answer different questions.
| Category | Answers | Acts before the call? |
|---|---|---|
| Visibility | What did each agent run consume? | No. Reports after the run. |
| Billing | What do we invoice each customer? | No. Bills after the period. |
| Security guardrails | Which tools and data may the agent touch? | Yes, for permissions — not usage or cost. |
| Runtime usage control | What should the next call be allowed to spend? | Yes. UsageFlow routes, caps, or blocks per customer, and can report usage to Stripe. |
What changes for your team
-
Engineers
No metering code, no plan checks in the agent. One call, one error to catch.
-
Finance
Caps enforced while the run is happening, not found on next month's invoice.
-
Founders
See which customers' agents run, which get stopped, and charge for it when you're ready.
Agent metering FAQ
Straight answers for the category questions.
What is agent metering?
Agent metering tracks what each AI agent run consumes — tokens and spend — and attributes it to the customer behind it. Runtime enforcement goes one step further: policies use that usage to downgrade, cap, or block the next call.
How is UsageFlow different from agent observability tools?
Observability tools show what an agent consumed after it ran. UsageFlow evaluates a policy before each call, so it can route to a cheaper model or stop the run when a customer reaches a budget.
Do I need to redeploy to change an agent budget?
No. Policies live in the UsageFlow Console and apply from the next call.
Stop the next runaway run before it starts
Free: 1 workflow with live policy. No credit card. TypeScript, Python and Go, with OpenAI and Anthropic. Stripe sync is on paid tiers — see pricing.