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.

  1. Name whose budget the run spends

    Replace the provider call with usage.chat and pass the customer's identity and a workflow name. Use the same identity you use in Stripe.

  2. 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.

  3. 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.

    TypeScript
    import { 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;
        }
      }
    }
  4. 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.

Change the cap without a deploy

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

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.