AI FinOps: From Seeing Spend to Stopping It
Analyst advice on AI spend has settled into two steps. First, use what each model vendor already gives you to understand and govern consumption. Second, add finer controls, such as spending limits by user or by role, with a dedicated FinOps tool.
That is sound advice. But the second step hides a choice that matters more than which tool you pick: does the tool only show you what was spent, or can it stop a call before the money is gone?
Step one: vendor tools, and where they stop
Every major model vendor now has a usage console. You can see tokens by project, set a monthly limit, and get an email when you get close. Start there. It costs nothing and it teaches you where the money goes.
The limits show up quickly:
- Each console sees one vendor. OpenAI's console sees OpenAI. Anthropic's sees Anthropic. Most companies use two or three providers, plus a model they host themselves. Nobody sees the total.
- The vendor does not know your organisation. It knows projects and keys. It does not know your teams, your cost centres or your customers.
- Limits are coarse. A vendor limit is usually one number for a whole project. It cannot say "this team gets $2,000 a month, and this user gets $50 a day".
- The rules differ per vendor. Three consoles mean three ways to set a budget, three alert formats and three reports for finance to merge.
So step two is not optional for long. Once AI use spreads beyond one team, you need one place that sees every call, from every team, to every provider.
Step two: two kinds of FinOps tool
The tools usually named for step two fall into two groups.
| Observability tools | Gateways | |
|---|---|---|
| Where they sit | Beside the call (an SDK or log export), or as a pass-through proxy | On the request path: every call goes through them |
| What they do best | Tracing, evaluations, prompt management, dashboards | Pricing, budgets, routing and policy on each call |
| When they act | After the call, when the record arrives | Before the call reaches the provider |
| What a limit means | An alert that spend went over | A call that is refused, or sent to a cheaper model |
Langfuse is a good example of the first group. It is strong at tracing and evaluation, and it tells you clearly what happened. Portkey sits closer to the second group: it is a gateway with budget features (see moving from Portkey to DVARA). Helicone started as a proxy focused on observability, and in 2026 it moved to maintenance mode after being acquired (see DVARA vs Helicone).
Both groups are useful. But a limit you can only report on is a limit you find out about later. If the goal is to govern consumption, the control has to be on the path the call takes.
What "limits by user or role" needs in practice
Per-user and per-role limits sound simple. Doing them well needs four things:
- A price for every call, at the moment it ends. Input, output, cached and reasoning tokens are priced at their own rates. Otherwise the budget drifts away from the invoice.
- A check before the call is sent. The budget is checked first, so a call over the limit never reaches the provider and never costs anything.
- Limits that nest. A company cap, a team cap and a user cap at the same time, with the tightest one winning.
- Something better than "no". Sometimes the right answer at 80% of the budget is a cheaper model, not an error.
How DVARA does it
DVARA is an AI gateway. Every model call, MCP tool call and agent-to-agent call goes through it, so it can price and limit each one as it happens.
Every call has a cost. Each call is priced when it ends and stored with its workspace, API key, model, provider and tags. Cached, cache-write and reasoning tokens have their own rates. See attribute and reconcile AI spend.
Budgets block before the spend. A budget cap can be daily, weekly or monthly. At the soft limit (80% by default) DVARA sends an alert. At 100% it refuses the call with 402 BUDGET_CAP_HARD, before the provider sees it.
Limits by team. Workspaces sit inside teams and accounts. Give each team or business unit its own workspace and its own cap, and finance gets a clean split.
Limits by user. A cap can cover one API key, or one tag value: an end user, a session, a customer ID or a cost centre. For a hard per-user limit, give each user or service its own API key and cap that key. A tag cap only counts callers that send the tag, so it suits callers you trust to tag their calls.
Limits by role. Map a role to its own workspace or set of keys, and give that a cap. Analysts, developers and production services can each have their own ceiling.
A cheaper model before a refusal. Past a threshold you choose, DVARA can switch a workspace to a cheaper model, so work slows down in cost instead of stopping.
One runaway call is caught too. An optional per-call ceiling estimates the worst-case cost of a request before it is sent, and refuses the outliers with PER_CALL_COST_EXCEEDED.
Advice, not just alerts. The Cost Advisor suggests a cheaper model, or a cache, with the monthly saving it expects. It then checks whether quality held after you apply it.
Reports finance can use. Chargeback reports per workspace, month-end forecasts and alerts when a workspace spends far above its normal rate. See Cost Management.
Agents are covered too. The same end user and tags apply to MCP tool calls and agent-to-agent hops, so one customer's spend can be followed across models, tools and agents.
Every refused call is written to DVARA's signed audit log, so cost controls can be audited like any other control.
A short checklist for step two
- Does the tool see every provider in one place?
- Does a limit refuse the call, or only send an alert?
- Can limits nest across company, team, user and role?
- Can it switch to a cheaper model instead of failing?
- Can it catch one expensive call, not just total spend?
- Does it cover tool calls and agents, not only chat calls?
- Can you run it yourself, inside your own network, if your data requires it?
Where to start
Keep using vendor consoles to learn your patterns. When you are ready for step two, put the controls where every call passes. For the full picture of cost control in DVARA, read Control LLM Costs Before the Invoice.
If you are new to DVARA, start with What Is an LLM Gateway?, or book a demo to see budget caps working on your own traffic.