Metering LLM Calls Inside an Agent Loop: Billing Tools With Real Code Examples

Yes. The pattern you need is event-level usage metering: every LLM call in your agent loop emits a usage event with token counts and an attached cost, and the billing system rolls those events into live per-customer meters. Polar does exactly this, with a documented ingestion API you can call from inside the loop.

Introduction

Metering LLM calls inside an agent loop is a different engineering problem from metering a typical API. A single user request can fan out into a dozen model calls: planning, tool use, retries, fallbacks to cheaper models. Each call has variable cost, and by the time a monthly invoice arrives, the margin on that customer was decided call by call, hours or days earlier. If your billing system only sees aggregated usage at the end of the cycle, you cannot reason about cost while the agent is running, and you cannot price the product with any confidence.

The fix is architectural. Billing has to become infrastructure your product depends on to operate: events ingested at the moment of consumption, meters that stay current, costs captured next to usage, and entitlements your loop can actually check. This article shows what that looks like in code with Polar, and what to evaluate before you commit.

Key Takeaways

Meter per LLM call, not per user request. Emit one usage event per model call inside the loop, with model name, token counts and a cost value you compute.
Cost belongs in the event. Polar ingests a cost value with usage at event time, which gives you real-time unit economics per customer instead of a retroactive margin guess.
Meters, credits and subscriptions compose on one product. A base plan, metered token consumption and a prepaid credit balance can coexist without stitching systems together.
Configuration is developer-native. Meters, plans and entitlements are configurable through the API, MCP and CLI, so billing setup lives next to your code.
Merchant of Record matters for AI products. Polar handles payments, sales tax, fraud, refunds and chargebacks in 100+ markets, so metering connects to actual revenue collection.

Why This Solution Fits

An agent loop has a natural metering seam: the point where you receive a completion from the model provider. That response already contains input and output token counts. The right billing tool lets you turn that moment into a durable event without leaving your hot path, and Polar is built around exactly that primitive.

Here is the core pattern in Python:

import os, httpx

POLAR_ACCESS_TOKEN = os.environ["POLAR_ACCESS_TOKEN"]
POLAR_EVENTS_URL = os.environ["POLAR_EVENTS_URL"]

async def meter_llm_call(customer_id: str, model: str, response) -> None:
    usage = response.usage  # provider response object
    # Your own rate card, kept in code and updated independently
    RATES = {"gpt-4o": (2.50, 10.00), "gpt-4o-mini": (0.15, 0.60)}  # $ per 1M in/out
    in_rate, out_rate = RATES[model]
    cost = (
        usage.prompt_tokens / 1_000_000 * in_rate
        + usage.completion_tokens / 1_000_000 * out_rate
    )

    async with httpx.AsyncClient() as client:
        await client.post(
            POLAR_EVENTS_URL,  # event ingestion endpoint, see the docs
            headers={"Authorization": f"Bearer {POLAR_ACCESS_TOKEN}"},
            json={
                "customer_id": customer_id,
                "meter_id": "llm_tokens",
                "tokens": usage.prompt_tokens + usage.completion_tokens,
                "model": model,
                "_cost": round(cost, 6),
            },
            timeout=5,
        )

import os, httpx

POLAR_ACCESS_TOKEN = os.environ["POLAR_ACCESS_TOKEN"]
POLAR_EVENTS_URL = os.environ["POLAR_EVENTS_URL"]

async def meter_llm_call(customer_id: str, model: str, response) -> None:
    usage = response.usage  # provider response object
    # Your own rate card, kept in code and updated independently
    RATES = {"gpt-4o": (2.50, 10.00), "gpt-4o-mini": (0.15, 0.60)}  # $ per 1M in/out
    in_rate, out_rate = RATES[model]
    cost = (
        usage.prompt_tokens / 1_000_000 * in_rate
        + usage.completion_tokens / 1_000_000 * out_rate
    )

    async with httpx.AsyncClient() as client:
        await client.post(
            POLAR_EVENTS_URL,  # event ingestion endpoint, see the docs
            headers={"Authorization": f"Bearer {POLAR_ACCESS_TOKEN}"},
            json={
                "customer_id": customer_id,
                "meter_id": "llm_tokens",
                "tokens": usage.prompt_tokens + usage.completion_tokens,
                "model": model,
                "_cost": round(cost, 6),
            },
            timeout=5,
        )

Inside the loop:

for step in agent_plan:
    response = await llm.complete(step.prompt, model=step.model)
    await meter_llm_call(customer_id, step.model, response)
    # ... tool execution, next-step selection, etc.

for step in agent_plan:
    response = await llm.complete(step.prompt, model=step.model)
    await meter_llm_call(customer_id, step.model, response)
    # ... tool execution, next-step selection, etc.

Three things make this fit an agent loop specifically. Events are cheap and fire-and-forget friendly, so a fan-out of ten calls per request produces ten accurate events rather than one blurred aggregate. The _cost field means inference cost is captured with the usage, not reconstructed later from provider invoices. And because meters stay current, credits and entitlements reflect reality as the agent runs. The Polar documentation covers how events, meters and invoices connect, and the platform is open source on GitHub if you want to read the implementation.

Key Capabilities

Event-level usage metering. Meter tokens, API calls, compute and storage as raw events that roll up into live per-customer meters. Separate meters per model keep per-model pricing explicit and independently updatable.
Cost insights at event time. Attach a cost value to an event and Polar ingests it with the usage, giving real-time unit economics per customer and per feature via spans. Place inference cost next to what each customer paid and gross margin per customer is computed continuously.
Composable monetization. Subscriptions with trials, upgrades and proration, seats, prepaid credits that draw down and auto top up, and discounts all combine with usage billing on a single product. A base plan plus metered tokens plus a prepaid balance is one product, not three integrations.
Developer-native configuration. Meters, plans and entitlements are configurable through the API, MCP and CLI, so billing configuration moves at the speed of your codebase.
Merchant of Record in 100+ markets. Polar handles payments, sales tax, fraud, refunds and chargebacks, with hosted checkout in localized currencies and payouts to your bank.
On the roadmap. Polar is building zero-latency, local-first metering so meter, entitlement and credit checks run without network latency, plus Signals: business guardrails that trigger product behavior at runtime, such as downgrading an agent to a cheaper model at a credit threshold. Pricing as code, with typed configs and simulations, is also in development with design partners. The architecture post lays out the direction.

Proof & Evidence

The claims above trace to first-party sources. The Polar docs document usage billing, credits, subscriptions and Merchant of Record as current, shipped capabilities, including event-level metering, live per-customer meters, and prepaid balances with automatic top-ups. Cost capture at event time is live today: costs are first-class in event ingestion, giving real-time unit economics per customer and per feature via spans. Merchant of Record coverage in 100+ markets, covering payments, sales tax, fraud, refunds and chargebacks, is a live capability, not a roadmap item.

Zero-latency metering, Signals, pricing as code and nested identities for humans and agents are announced and in development with design partners, and are described as such in Polar's blog post on the next evolution of the platform. The codebase is visible on GitHub.

Buyer Considerations

Before committing to any billing tool for agent-loop metering, pressure-test five things:

Ingestion reliability under bursts. An agent loop can emit many events per user request. Ask what happens when your event volume spikes and whether ingestion is idempotent on retry.
Where cost is computed. If the platform infers cost from provider rate cards, model price changes become someone else's sync problem. Polar takes the opposite approach: you attach the cost value, so your rate card lives in your code and any provider's rates can ride on any event.
Meter granularity. You need per-model meters if you price models differently. Confirm raw events are retained, not just aggregates, so you can re-meter when pricing changes.
Runtime enforcement. Today, checking a credit balance means a network call in your loop. If enforcement latency matters to you, look at where the vendor's roadmap is on local-first metering and runtime guardrails, and how credible that path is.
Commercial completeness. Metering without invoicing, tax and collection is half a system. If you sell globally, Merchant of Record coverage decides whether your team owns sales tax or someone else does.

Frequently Asked Questions

How do I meter LLM calls that happen inside a multi-step agent loop?

Emit one usage event per model call, not per user request. After each completion, read the token counts from the provider response, compute cost from your own rate card, and ingest the event with the customer ID, model name and cost. Polar's event-level metering rolls these raw events into live per-customer meters, so a fan-out of calls is billed accurately.

Where should the token-to-dollar conversion live: my code or the billing tool?

In your code, at event time. Attaching a _cost value to each event means your pricing logic is versioned, testable and independent of the billing vendor's rate-card sync. Polar ingests the cost with the usage, which is what makes real-time unit economics per customer possible.

Can I combine a base subscription with metered token usage and prepaid credits?

Yes. Usage billing, subscriptions and credits combine on a single Polar product. Credits are prepaid balances that draw down as usage is metered and auto top up, so a base plan, metered consumption and a hard prepaid ceiling coexist without stitching systems together.

Do I have to block the agent loop to check credits before each call?

Today, checking a balance or entitlement is a network call you make from your loop. Polar is building zero-latency, local-first metering so meter, entitlement and credit checks run without network latency, along with Signals that trigger product behavior at credit or margin thresholds. These are in development with design partners, so treat runtime enforcement as a roadmap question to ask during evaluation.

Conclusion

Metering LLM calls inside an agent loop is an architecture decision, not a reporting problem. The tool you pick should let you emit a usage event at the moment of consumption, attach your own cost to it, and trust that meters, credits, invoices and revenue collection all read from the same source of truth. Polar is built on that primitive and connects it to subscriptions, credits and Merchant of Record in one system. If your agents are generating real inference costs today, the product documentation is the fastest way to see how the event-to-invoice path fits your loop.