Skip to main content

Know what every app and project actually costs

Enterprise Tier

"What did the support-bot initiative cost this quarter?" is a funding question, and the user and team dimensions cannot answer it: spend is grouped by who issued the request and which organisational unit they belong to, while the question runs along the application or project the cost should be booked against. Caller-set tags supply that missing axis, so per-initiative cost stops being an estimate and becomes a report.

A tag is a label the caller sets on a request (an app, a project, or whatever cost dimension the business reports along) so that cost can be grouped beyond the fixed user and team breakdowns. This guide agrees and enforces the tag dimensions, then exports the grouped reports finance and team leads consume. It extends the reporting discipline in Bill AI spend back to the teams that incur it along the tag axis.

Persona: Platform operator working in the Admin Dashboard, in partnership with finance, business owners, and the developers who set tags at the source.

Estimated time: 30--45 minutes to agree and wire the first tag dimensions; ongoing as workloads and cost centres evolve.

Outcomes​

By the end of this guide:

  • A governed set of tag dimensions has been agreed with finance and the business owners, carried on requests, and constrained by policy where attribution must be trustworthy.
  • A consumption report has been grouped by a tag and read against the budgets the tagged workloads sit under.
  • A tag-grouped cost report has been exported for the finance process or team lead that owns that cost.

Prerequisites​

  • Administrator access to the Admin Dashboard, typically the super_admin or billing_admin role.
  • The reporting and export workflow already in use, since tag attribution extends it along a new axis. See Bill AI spend back to the teams that incur it.
  • Cooperation from the developers who own the workloads, because tags are set on the request at the source. The convention is documented for those teams in Monitor traffic and usage.

Step 1: Attribute cost with caller-set tags​

  1. Agree the tag dimensions with finance and the business owners before any are set. A tag is only useful for chargeback if everyone producing requests and everyone reading reports uses the same set of names; an ungoverned tag space produces a long tail of near-duplicate labels that no report can sum across.
  2. Establish how each tag is carried on the request, typically as request metadata the calling code attaches, alongside the credential that already identifies the user. The convention is documented for the teams that own the workloads in Monitor traffic and usage, so that the tags a report depends on are set consistently at the source.
  3. Constrain the tags by policy where the attribution has to be trustworthy. A policy can require that a tag is present before a request is served and can restrict its value to an agreed set, so that a caller can neither omit the attribution nor book spend against an app or project that is not theirs. Without this, a tag is a hint rather than a billable fact.
  4. Group a consumption report by a tag the same way a report is grouped by user or team, by app or by project, and read it against the budgets the tagged workloads sit under.

Tag-based attribution coexists with the user and team dimensions rather than replacing them. A single request carries its user, its team membership, and whatever tags the caller set, so the same spend can be reported per person, per cost centre, and per project without re-running the workload. The fixed dimensions answer "who spent this"; the tags answer "what should it be booked against", and the two are most useful read together.

Where the attribution feeds chargeback, the policy constraint is what makes it defensible. A report grouped by a tag that any caller could set to any value invites disputes about whose budget a line item belongs to; a report grouped by a tag Agent Router required and validated carries the same authority as the user dimension behind it. That a tagging or attribution policy changed, and who changed it, is recorded in the audit trail described in Audit Agent Router activity, alongside the budget changes made when setting the team ceilings.

Step 2: Export grouped cost reports for finance and team leads​

A tag dimension earns its keep the same way the user and team dimensions do, in a report finance and team leads actually consume. The chargeback export carries the tag dimensions out of Agent Router alongside the user, cost, and token totals already covered.

  1. Apply the time range, the tag grouping (by app or by project), and any user or team filter that match the chargeback period and the cost-centre structure.
  2. Use the Export function to download the grouped data, typically as CSV, with one row per tag value over the period.
  3. Hand the app- or project-grouped file to the finance process or the team lead who owns that cost, or load it into the billing system that owns the chargeback allocation.

A tag-grouped export gives a team lead a statement of their own team's spend without exposing the wider organisation's figures, and gives finance a per-project breakdown that maps onto the cost centres a user or team view cannot express. Agent Router's role still ends at producing accurate, attributable rows; the grouped file joins to the same downstream ledgers as the user- and team-based exports, along the dimension the business reports against.

What to do next​

Where to go next

Bill AI spend back to the teams that incur it

The user- and team-based reporting this guide extends along the tag axis.

Monitor traffic and usage

The developer-side view where the tags this guide depends on are set.