AI agents are eager spenders. Each task a model picks up burns tokens, each tool call adds latency and sometimes cost, and when you run dozens of agents across a team the total can compound quickly. The problem is not that AI is expensive — it is that the cost is invisible until it isn't. A credit ledger paired with real-time usage monitoring changes that: you see exactly what each agent is consuming, you know when the balance is running low, and you can act before an unexpected line item lands on the invoice. This post is about the ledger and the monitoring; how to pass the resulting costs on to teams is covered in chargeback vs showback for AI agent costs.
Why a Credit Ledger Instead of Post-Hoc Billing
Most API-driven AI services charge at the end of the month. That model works fine when usage is predictable, but agent workloads are rarely predictable. A misconfigured retry loop, an unexpectedly verbose prompt, or a scheduled workflow that triggers more often than intended can all produce outsized spend that you only discover weeks later.
Your organization holds a prepaid balance, and billable tasks settle against it when their results are submitted. Insufficient credit can leave a task failed after the work has run. The credit ledger therefore does not guarantee refusal before execution. For a broader treatment of how to prevent runaway agent spend across your fleet, see the post on how to set budgets for AI agents.
Plan credit top-ups around expected task settlement and monitor the balance alongside usage. To control dispatch, use enforced budget policies separately: they reserve estimated spend before dispatch and can refuse new work. For teams that also want time-windowed limits on top of the balance, budget policies in Praesidia covers their scopes, periods and threshold actions.
The Usage Record: What Gets Tracked
Model calls that pass through Praesidia are recorded as usage. Each usage record captures the usage type (input or output tokens, for example), the quantity, the computed cost, the agent and the model configuration behind the request. Calls that do not pass through Praesidia are not recorded. This stream is the foundation of everything else in cost monitoring.
Because each record is tied to a specific agent and model configuration, you can answer questions that aggregate invoices cannot: which agent consumed the most this week, which model configuration is driving up costs, and how does today's spend compare to the same day last month. For how to set structured time-windowed limits on top of the credit balance, see budget policies in Praesidia.
The cost itself is computed per model from a token pricing table, so as you change which model an agent uses — switching to a smaller model for routine tasks, reserving a larger one for complex reasoning — the recorded cost reflects the actual rate, not a blended average.
Credit Transactions and the Org Balance
Each debit updates the current organization balance atomically and creates a transaction row recording the amount and resulting balance. Concurrent debit requests cannot both consume the same available credit.
The task-completion path checks the reported billable cost against available credits. An insufficient-credit error can occur after execution, so operators must check the task outcome and any external side effects before retrying.
The organization balance is updated as credits are applied or consumed, and transaction rows provide a history for reconciliation. Compare the transaction history with the balance and usage records; a credit transaction is not a signed audit-chain proof.
Usage Stats: Breakdowns and Projections
A raw ledger is necessary but not sufficient. What operators actually want to see is aggregated: total spend for the current period, cost broken down by agent, cost broken down by day, and a rough projection for where the month will land.
Usage stats aggregate that detail into the breakdowns that are actually useful for decision-making. The per-day breakdown lets you spot the day a cron workflow started misbehaving. The per-agent breakdown tells you which part of your fleet is the biggest spender. The month-end projection — a linear extrapolation from the daily average — gives you a rough target to hold budget conversations around.
These are not forecasts in the actuarial sense. A linear projection assumes today's usage pattern continues, which may not hold if you are ramping up a new workflow. But as a quick sanity check — is spend tracking above or below expectation — it covers the common case.
For richer visualization of usage trends across your entire AI estate, see visualizing AI usage and cost.
Topping Up Credits
Credits are purchased through the billing flow, not the cost-monitoring surface directly. This separation is deliberate: purchasing credits is a financial action that involves payment processing, while monitoring credits is an observational one. The two surfaces talk to the same balance, but through different paths, which keeps the money-handling logic isolated and auditable.
Owners and billing administrators can initiate a top-up from the credits page, which routes through payment processing before the balance is adjusted. The resulting transaction appears in the ledger like any other, making it easy to see when a top-up happened and how much it brought the balance to.
Platform administrators also have a grant path for operational credits — useful for service credits, corrections, or onboarding allocations — which goes through a separate, admin-only path and is similarly recorded in the ledger.
Tying Cost to Connections and Agents
One of the less obvious advantages of a per-event usage record is that it enables cost attribution at the connection level. When an agent connects to a model provider through a named connection, that connection identifier travels with the usage record. If your architecture includes multiple connections — different models for different purposes, or different teams routing through separate connections — the cost breakdown respects that structure.
This matters for chargebacks and capacity planning. A platform team supporting multiple internal teams can show each team what their workloads actually cost. A team evaluating whether to switch models can compare the before-and-after cost of running the same agent workloads on different providers. See tracking per-connection AI usage and cost for how this attribution works in practice.
The Operational Loop
The practical pattern that cost monitoring enables is a closed loop: you set a budget, watch usage against it, get an early signal when spend is trending high, and intervene before the balance runs out. Praesidia is designed to make each step of that loop concrete rather than aspirational.
The credit balance controls settlement of billable completed tasks. BYOK gateway usage is billed by your provider and recorded for attribution and budgets without debiting Praesidia credits; the BYOK gateway guide explains why provider charges stay with your provider account. Usage records give you per-event detail. The stats surface aggregates that detail into the breakdowns that are actually useful for decision-making. And the billing integration ensures that topping up the balance is a tracked, auditable action rather than a manual adjustment.
For teams running agent fleets at any meaningful scale, this combination — prepaid balance, atomic debits, transaction history, per-agent usage records — is the difference between understanding your AI spend and discovering it.
Common questions
Does the credit balance stop agents mid-task, or only at task boundaries? The balance check and debit happen in task completion. Work may already have run when insufficient credit prevents settlement; the ledger is not a pre-execution or mid-task kill switch. Enforced budget policies independently check estimated spend before dispatch.
Can I see cost broken down by individual user, not just by agent? The built-in usage stats surface provides breakdowns by agent and by day within the current period. For finer attribution — which team member triggered which agent run — a task a person submits through the UI or API keeps that user on the task record, and the task-creation audit entry names them, so the data is available for reporting even when the cost dashboard shows aggregates. A task an agent starts on its own has no submitting user.
What happens to the usage history when I top up credits? Usage records and credit transactions are both append-only. Topping up creates a new credit transaction (a positive adjustment) but leaves prior usage records untouched. The full history — spending down, topping up, spending again — is always visible in the ledger and usable for reconciliation or reporting across any time range.
How do credits interact with budget policies? Credits settle billable completed work. Budget policies separately limit estimated spend by entity and period before dispatch, with actual costs settled afterwards. BYOK model charges remain with your provider, even when Praesidia records them for budget enforcement. See cost control for LLM applications for a full treatment of how enforcement policies work.