Effective AI cost management starts with attribution. When every request and every dollar is tied to the specific connection that produced it, you gain the foundation for accurate chargebacks, meaningful capacity planning, and early detection of runaway workloads. Without that granularity, you are left guessing at which integration, team, or agent is responsible for a climbing invoice. Per-connection tracking is the granular layer that turns a monthly total into an actionable breakdown. It is also the data foundation required before setting hard spend caps for AI agents — you cannot calibrate a cap you cannot measure.

Why Aggregate Billing Data Is Not Enough

Most platforms surface usage as a single monthly number: total tokens consumed, total cost billed. That figure is useful for finance but nearly useless for operations. When a cost spike appears, the question is always the same — which connection caused it? When a capacity-planning conversation comes up, the real question is which connections are growing fastest and which are idle.

Aggregate data cannot answer those questions. You need usage metered at the level of the individual connection: the specific integration, agent, or API consumer making calls. Only then can you draw a straight line from an infrastructure decision or a product change to its cost impact.

This is the core problem that per-connection usage tracking solves, and it sits at the intersection of FinOps discipline and operational observability. For a broader look at how FinOps principles apply to AI workloads, see FinOps for AI Agents: Controlling Token and Tool Costs.

The Anatomy of a Connection Usage Record

A connection represents a defined link between an agent or application and a resource — a model provider, an MCP server, a tool endpoint. Every request that flows through that connection is a billable event with measurable properties: how many tokens were exchanged, whether the call completed, whether it was blocked by a guardrail, or whether it was rate-limited.

Per-connection tracking captures all of those dimensions in a monthly aggregate per connection. The counters that matter most in practice are:

  • Request count — the volume of calls, which directly signals activity and load.
  • Token count — the consumption that drives most LLM invoices.
  • Total cost — the dollar value attributed to that connection for the period.
  • Blocked count — how many requests guardrails stopped before they reached the model.
  • Rate-limited count — how many requests hit a throttle, which can indicate a misconfigured client or a usage surge.

Each of these is recorded against a monthly period, so you see not just the current snapshot but a trend over time. A connection that consumed a modest amount last month but doubled this month is worth investigating, even if neither number individually looks alarming.

Attributing Cost to the Right Source

Attribution sounds simple in principle — record who made the call, then sum by caller — but it gets complicated quickly in practice. A platform may have dozens of connections active at once, each dispatched by different teams or products. Without a consistent, enforced attribution model, the accounting degrades into estimates and manual reconciliation.

The reliable approach is to record usage at the point of enforcement, not the point of billing. When a request passes through the connection layer — where guardrails, rate limits, and routing logic are applied — the system has all the context it needs: which connection is active, what the request cost, and whether it completed normally. Recording at that point means no call can slip through without being counted.

Praesidia takes this approach. Usage is recorded at the enforcement layer, so the aggregate always reflects exactly what was dispatched. A blocked request increments the blocked counter but not the cost counter, because the model was never called. A rate-limited request increments its own counter, letting you distinguish capacity problems from policy violations.

Chargebacks and Internal Billing

For organizations with multiple teams sharing a common AI infrastructure, per-connection usage data is the input to chargeback calculations. Rather than splitting a shared cost evenly — or absorbing everything into a single cost center — you can attribute spend to the team or product that generated it. This is the same principle behind budgets and quotas for preventing runaway agent costs: accountability requires visibility first.

This changes the conversation inside an organization. Teams become accountable for the cost of their AI usage in the same way they are accountable for compute or storage consumption. Over-broad connections, agents that retry aggressively, or integrations left running after a project ends all show up in the numbers. That visibility creates pressure to clean up waste that would otherwise be invisible.

Accurate chargebacks also support capacity planning discussions. If a team's usage is growing steadily month over month, you can model forward costs and have a budget conversation before the invoice arrives. If a connection is flat, it might be a candidate for deprecation.

Capacity Planning From Real Data

Capacity planning for AI workloads is harder than for traditional compute because the cost unit is variable — token counts fluctuate with input length and task complexity, and model pricing can change. Despite that variability, multi-month per-connection history gives you the trend data you need. For how to turn that history into outcome-oriented ROI metrics, see Measuring the ROI of AI Agents.

A chart of request counts and cost over several months reveals patterns that are invisible in a single snapshot: seasonal spikes, growth trajectories, sudden drops that might indicate a failed or inactive integration, or costs that diverge from request counts (which often signals a shift to more expensive models or longer contexts). For techniques on turning this history into dashboards your team can act on, see visualizing AI usage and cost.

That history also informs connection-level budget decisions. If you know a connection averaged a certain spend per month over the last six months, you can set a budget threshold with confidence rather than guessing. When that threshold is paired with alerting, you catch anomalies before they compound. For guidance on translating this history into hard caps, see budget policies and hard spend caps for AI agents.

Connection Usage in the Praesidia Dashboard

In Praesidia, connection usage is surfaced in the connection detail view. Opening a connection shows the current month's counters alongside a multi-month history chart that plots both request volume and accumulated cost. The data is scoped to the organization — a member can only see usage for connections within their org — and is updated as requests flow through.

The organization-level view provides a monthly rollup across all connections, useful for the aggregate picture that finance teams need. The per-connection view provides the attribution detail that operators and engineering leads need. Both draw from the same underlying metered data, so the numbers are consistent.

Access to usage data is governed by the billing view permission, which means you can extend read access to finance or product leads without granting broader administrative rights.

What Good Usage Attribution Enables

The practical value of per-connection tracking compounds over time. Early on, it answers the immediate question of where money is going. As history accumulates, it supports more sophisticated analysis: correlating cost spikes with deployment events, identifying connections that are expensive relative to the value they produce, or comparing the cost profile of similar workloads running against different models.

Teams that instrument usage at the connection level tend to catch three categories of problems that would otherwise surface only on the invoice:

Idle or orphaned connections — integrations that are technically active but generating no useful output, yet may still incur baseline costs or hold reserved capacity.

Disproportionate consumers — a single connection generating a majority of total spend, which may indicate a design issue (very long context windows, lack of caching) or a runaway loop.

Guardrail signal — a high blocked-to-request ratio on a connection suggests that the agent's outputs are regularly failing policy checks, which is worth investigating both for cost (calls were made but blocked) and for correctness (the agent may be behaving unexpectedly). For how to tune guardrail policies to reduce false positives, see Designing Guardrails: Block, Redact, or Warn?.

None of these are visible from aggregate totals. They become visible only when you can inspect the per-connection breakdown.

Common questions

How is per-connection usage different from the overall cost monitoring view?

The overall cost monitoring view gives you an organization-wide picture of spend across all agents, models, and time periods — useful for understanding total consumption and trends at the macro level. Per-connection tracking goes one level deeper, attributing every request and dollar to the specific connection that generated it. They draw on the same underlying events, but the connection view adds the attribution layer needed for chargebacks and targeted investigation. For the platform-wide observability picture that sits above connection-level data, see advanced analytics for AI operations.

Can I use connection usage data to set budgets?

Yes. Connection usage history gives you the baseline you need to set meaningful budget thresholds. Budget policies can be configured at the connection or organization level, and the historical usage data informs what a realistic threshold looks like. See how to set budgets for AI agents for details on combining usage tracking with budget enforcement.

What happens if a request is blocked by a guardrail — does it count against cost?

A blocked request is recorded in the blocked counter but not attributed to total cost, because the model was not invoked. You will see the blocked count in the connection's usage summary, which is useful for understanding how often guardrails are triggering on a given connection. High blocked counts relative to request counts often warrant a review of the agent's behavior or the guardrail configuration.