I have now sat in enough of these conversations to notice that finance asks the same six questions, roughly in the same order, and that engineering teams are usually caught out by the same two of them.
None of the six are hostile. That is worth saying, because engineers often read them as an attack on the project. They are not. They are the standard questions anyone asks about a line item they are responsible for, and the reason they feel like an attack is that the honest answer is frequently "I do not know", which is uncomfortable to say out loud about something you built.
Here they are, with what makes each one awkward.
"What is this costing us?"
The easy one, and the only one a provider dashboard answers directly. Total spend, per month, per provider. Fine.
The trap is that answering only this question is what gets projects cut. A total is a pure cost with no benefit attached to it, and a line item that reads as pure cost is the easiest thing in a budget to remove. If this is the only number you bring, you have brought the argument for cancellation and nothing else.
"What is driving the increase?"
This is the first one that usually goes badly, and it goes badly for a structural reason rather than a negligent one.
Provider billing is organised by API key. Your business is organised by customer, feature, and agent. If three agents share one key, the provider can tell you that the key spent more this month and nothing else. The context that would let you split it, which customer this run was for, which feature triggered it, which agent handled it, existed in your application at the moment of the call and was discarded when the request left your infrastructure.
You cannot reconstruct it afterwards from provider data, which is why teams end up grepping application logs for two days to answer a question that ought to take a minute. The fix is to attach the dimensions at call time and keep them. We went through the mechanics in how to track OpenAI costs by agent, customer, and feature.
"Which customers are unprofitable?"
The second hard one, and the one with the most money in it.
Inference cost per customer is almost never evenly distributed. A common shape is that the top 5% of customers by usage account for something between a third and half of inference spend, and on flat-rate pricing some of them are being served at a loss. Nobody notices while the aggregate margin looks acceptable.
Finance asks this question because it is the one with an obvious action attached. You can move a customer to a different plan, add a usage component, cap something, or in rare cases decline to renew. But every one of those actions requires naming the customer, and you can only name the customer if cost carries a customer identifier from the start.
When teams cannot answer this, the usual outcome is a blunt across-the-board response: a cheaper model everywhere, or a hard cap that penalises the healthy customers alongside the expensive ones.
"What do we get for it?"
The question that decides the project, and the one engineers are least prepared for, because the honest engineering answer is a story and finance wants a ratio.
Cost per successful run is the number that works here. Take spend, divide by the runs that actually did their job, and you have something that reads as unit economics because it is unit economics. It has a denominator, which means it can improve, and improvement is the thing a budget owner wants to see.
Getting to it means defining "successful", which is where most teams stall. It does not have to be sophisticated. A cheap deterministic check on output shape catches a surprising amount, and a sampled quality score covers the judgment calls that a rule cannot make. The full argument is in AI agent unit economics, and it is the single most useful metric to have ready before you walk in.
"Is it under control?"
Less about the number and more about whether anyone is watching it. What finance is really asking is whether a bad week can happen without someone noticing, because a cost that can quadruple silently is a risk item as well as an expense.
The answer that lands is not a promise to be careful. It is naming the specific alerts: a per-agent daily spend baseline with an anomaly threshold, a cap on retries, and a hard ceiling per run. Three concrete controls beat any amount of reassurance, and they turn an open-ended liability into a bounded one.
"What happens if we cut it by 30%?"
Sometimes framed as a hypothetical and sometimes not.
The wrong answer is that quality would suffer, because it is unfalsifiable and everyone in the room knows it. The right answer separates spend into buckets and gives a real consequence for each: this portion is cacheable and cutting it costs nothing, this portion is retries and should be cut regardless, this portion is a genuine capability where a cheaper model measurably degrades output, and here is the measurement.
That last part is why quality scoring pays for itself in a budget review even though it looks like an engineering nicety. Without it, "quality would suffer" is an opinion. With it, it is a chart with a number on it, and the conversation moves from whether to cut to where. Seven ways to cut AI agent costs without touching quality covers the parts that are genuinely free.
The pattern
Five of the six questions need cost broken down by a dimension your provider does not know about. That is the whole problem in one sentence, and it is why this is an instrumentation question rather than a reporting one. By the time the question is asked, the data either exists or it does not, and no amount of analysis creates attribution that was never captured.
The teams that come out of budget season intact are rarely the ones spending least. They are the ones who can answer in the room. AgentPing attaches customer, feature, and agent to every run so those six answers are queries rather than projects, and you can wire it into one agent for free before someone asks you the second question.