Real-Time AI Spend Dashboards for Engineering and Finance Teams
Uniting engineering and finance on AI spending through shared real-time visibility.
AngelList's controller, Greg Cooley, found out his company was losing a significant sum of money every month on AI spend, and once the team had real visibility into where it was going, the fix took a single day. That gap, weeks of silent loss followed by a one-day fix, is the whole story of AI spend governance right now. Engineering teams are the ones generating the spend. Finance teams are the ones accountable for it. Until recently, those two teams worked from entirely different information sources, with nothing connecting them.
The AngelList case wasn't a technical failure. The failure was informational: the data needed to catch the problem existed somewhere in the system, but it wasn't visible to the person who could have acted on it in time. That distinction matters, because it points to the actual fix. The shared data layer lets engineering and finance see the same spend, at the same time, each in the form their job requires.
This is now a standard condition across organizations building with AI. The share of FinOps practitioners responsible for AI spend grew from less than a third in 2024 to nearly all of them by 2026. That's a shift from a niche technical concern to a mainstream financial discipline in under two years. Token spend behaves differently from the software costs finance teams are used to managing: it scales with usage, not seats, so it can grow quickly and silently across many teams at once. The rest of this piece lays out why that difference is structural, what each team actually needs to see, and how a single data layer can serve both without forcing either one to translate for the other.
What makes AI spend structurally harder to govern than cloud or SaaS spend
Token-based pricing is consumption-based in a way that seat-based SaaS, and even cloud compute, simply isn't. A SaaS contract has a seat count. Cloud infrastructure has instance hours and storage measured in gigabytes, units that are imperfect but at least mappable to a business activity. A token count has no such built-in handle. Unless attribution metadata gets captured at the moment the request is made, there's no way to connect that token count back to a project, a team, or a cost center.
This is why existing SaaS management tools, built for a world of seats and subscriptions, hit a wall with AI spend. Platforms like Zylo can track seat-based and hybrid pricing in one place without much trouble, but the consumption-based portion of AI spend is the part they weren't built for. Zylo's response was to build a dedicated AI Cost Management module that monitors consumption-based spend in real time and allocates those costs across business units, precisely because the existing SaaS system of record had no way to do it. The fact that a SaaS management vendor had to build a separate module for this is itself evidence that AI spend doesn't fit inside the old playbook.
The multi-provider reality makes it worse. Organizations running AI workloads typically touch OpenAI, Anthropic, AWS Bedrock, and Google Vertex AI in some combination, and each of those providers has its own pricing model, its own rate limits, and its own invoice format. No single provider dashboard can give a complete picture of spend when the spend itself is scattered across billing systems that don't talk to each other.
The industry has started to recognize that token cost governance is its own problem. The Linux Foundation launched the Tokenomics Foundation at FinOps X on 9 June 2026, a signal that token cost governance now warrants its own standards rather than being treated as an extension of existing cloud FinOps practice. Cloud FinOps took years to mature into a recognized discipline with its own vocabulary and tooling. Token cost governance is being treated as deserving the same seriousness, built from scratch rather than bolted onto what already exists.
The same organizational gap from the opening section produces this: the teams driving AI adoption, usually engineering, are not the teams managing the spend that adoption produces. Without a shared attribution layer connecting the two, neither side can answer a simple question, which team spent what, on which model, for which project, without manually reconstructing the answer after the fact. Concentrate AI, a model router that tracks spend by team, project, API key, model, and provider in real time across a single unified API, is one approach built specifically around that visibility gap.
The two fundamentally different questions a spend dashboard must answer
Engineering and finance are asking two categorically different questions, so a single generic layout built to serve both ends up serving neither well.
Engineering's question is operational: which model, on which request, is costing more than it should, and is that cost the result of a routing decision, a prompt design choice, or a plain spike in usage? Answering that requires granularity. Engineers need to see token counts broken out by input and output, model version, provider, latency, and the specific virtual key or team that generated the call. They need to see it in time to act, rerouting a request, capping a consumer, adjusting a rate limit, without filing a ticket and waiting for someone else to approve the change.
Finance's question is accountability: is AI spend tracking against plan, which team or product is responsible for overruns, and what's the cost per unit of business output. That question needs aggregation, not granularity. Finance needs spend rolled up by team, by project, by model family, by time period, attributed clearly enough to assign to a cost center. CloudZero's allocation engine, for example, breaks AI costs down by type of service, SDLC stage, model development stage, and model, then connects those dimensions to custom unit cost metrics like cost per project, cost per model, or cost per user. That's a business-unit view built for a business-unit question, and it has almost nothing in common with what an engineer needs to see to debug a cost spike.
This is where the AngelList case becomes instructive again. The loss went undetected for months because nobody was looking at the data through the lens that would have made it meaningful, even though the data existed somewhere in the system. That's the gap a shared data layer closes, turning data that already exists into a form each team can act on without needing the other to interpret it first, which is what let the fix happen in a single day once visibility existed.
When these two questions get collapsed into a single dashboard, the predictable failure happens on both sides. Engineers ignore the budget columns they have no way to act on. Finance ignores the token-level rows they can't read. Neither side catches a developing problem before it appears as a surprise on next month's invoice, which is the failure mode AngelList lived through.
The Engineering View of a Real-Time Spend Dashboard
An engineering dashboard earns its keep only when it closes the loop between spotting a cost signal and acting on it directly at the infrastructure layer, with no ticket and no finance sign-off required.
Request-level attribution is the floor, not the ceiling. Every log entry needs to capture model version, provider, the consumer identity (virtual key or team), input token count, output token count, latency, and the outcome of any policy enforcement applied to that request. This matches the span-level audit granularity production gateways are built to produce: prompt, response, tool calls, latency, token counts, and model version, tied to a user ID. Without that level of detail, engineers debugging a cost spike are left staring at an aggregate number with no causal chain back to the request that caused it.
Real-time rate limiting and budget caps need to be enforceable per consumer, whether that's a virtual key, a team, or a customer, directly at the infrastructure layer rather than bolted on after the fact at the application level. Limits and caps set at the gateway apply to every request regardless of which application or agent is making the call, making it the natural chokepoint for enforcement. Virtual keys function as the governance unit in production systems, each one enforcing its own provider access permissions, rate limits, and spend budgets in a hierarchy.
Model attribution by cost is what makes routing decisions visible instead of invisible. The clearest illustration of why this matters comes from a direct benchmark contrast: across real coding tasks in 2026, Claude Sonnet 4.6 delivered full quality at a cost per run that ran orders of magnitude higher than Gemini 2.5 Flash, which hit near-equivalent quality at a fraction of the price. Without model-level cost attribution sitting in the dashboard, that kind of routing opportunity simply doesn't exist for an engineering team, because nobody can see it. This isn't a hypothetical. RouteLLM, developed by researchers at UC Berkeley, Anyscale, and Canva and published at ICLR 2025, demonstrated on standard benchmarks that routing simple queries to smaller models can cut overall LLM spend substantially while preserving most of a frontier model's response quality.
Fallback and failover visibility belongs in the same view, because a failover event changes the cost profile of traffic in real time, not just its reliability profile. Provider outages are a documented production reality: a multi-provider outage on September 3, 2026, hit OpenAI, Anthropic, and xAI within the same window, while Google's Gemini saw user-reported issues without a confirmed outage, and no shared root cause, such as a shared cloud region or network path, was ever officially confirmed between the affected providers. When traffic reroutes to a fallback provider mid-incident, spend can shift materially because different providers price per token differently. Engineers need to see which provider actually served which requests during that window, in real time, not reconstruct it later from a confusing invoice.
Finally, the engineering view should export into the tools engineering already lives in. Prometheus metrics and OpenTelemetry traces let a team fold AI spend signals directly into existing on-call tooling instead of standing up a separate monitoring surface just for this one category of cost.
The Finance View of a Real-Time Spend Dashboard
A finance dashboard for AI spend earns its usefulness only when it maps token costs to business units, tracks spend against budget in real time, and produces the attribution evidence a chargeback or a quarterly review actually requires. A raw token log gives finance none of that.
Attribution by cost center is the starting requirement. Spend has to be breakable by team, by product, by project, and by model. CloudZero's approach allocates AI spend to the teams, products, and customers generating it, breaking costs down by type of service, SDLC stage, model development stage, and model, and connecting those dimensions to unit cost metrics such as cost per project, cost per model, or cost per user. Without that attribution layer, finance has no way to answer the question a chargeback depends on: did engineering or did marketing generate this particular OpenAI bill.
Budget tracking needs to happen against plan in close to real time, not through end-of-month reconciliation after the invoice lands. 1Password's AI Spend and Consumption Management tool, introduced 14 July 2026, pulls consumption data from Anthropic, OpenAI, and Cursor daily through their admin APIs and consolidates it into a single dashboard. A daily cadence is still not real-time, but it shows the direction the market is actively moving. The practical bar finance needs cleared is spend visibility at the same frequency decisions get made, with alerts firing before a budget threshold is crossed rather than after.
Forecasting exposure on variable pricing is a need unique to finance that the engineering view does not address. Seat-based software has a predictable monthly cost. Token-based AI spend can grow non-linearly with usage. Finance needs a forward-looking signal rather than a trailing record of actuals. Zylo's AI Cost Management module forecasts that exposure and allocates AI costs across business units, addressing the specific risk that a rising usage curve turns into a surprising invoice with no warning.
Multi-provider consolidation into one view matters for the same reason it matters on the engineering side, just for a different purpose. Finance cannot reconcile separate invoices from OpenAI, Anthropic, AWS Bedrock, and Google Vertex AI without a layer that pulls them together. Finout, for instance, connects to OpenAI, Anthropic, AWS Bedrock, AWS SageMaker, GCP Vertex AI, and Cursor without requiring code or agents, and displays token and inference costs alongside AWS, GCP, Azure, and OCI spend, giving finance one pane for cloud and AI costs together.
What finance does not need is prompt-level detail. Giving finance access to raw prompts and responses adds compliance exposure without adding any budget visibility finance actually uses. The right design keeps the data finance needs separate from the data it has no use for, and that separation is what makes the infrastructure layer underneath both views possible.
How the infrastructure layer connects both views without duplicating data or violating compliance
Both teams can get what they need from the same underlying system because a gateway captures request metadata, cost, model, consumer identity, latency, as a stream distinct from prompt and response content, and those two streams can be routed to different audiences under different permissions.
The gateway sits at the one point in the system where token counts, model attribution, provider identity, and consumer identity are all known at the same moment, with no extra instrumentation required at the application level. A correctly built audit log captures a session identifier, a timestamp, the identity of the requesting service or agent, token counts for input and output, latency, the outcome of any policy enforcement, and anomaly flags. That's the metadata stream, and it's what powers both the engineering view and the finance view described above, just aggregated differently for each.
Prompt and response content runs as a separate stream entirely, subject to PII redaction before it's stored or transmitted anywhere. That separation is what resolves the tension raised at the end of the finance section. Finance gets full visibility into cost, attribution, and budget exposure without ever touching raw prompt content, and engineering gets full request-level granularity without finance needing to sort through conversation logs it has no reason to see.
Role-based access control on top of this audit layer is what keeps the two views properly separated in practice. Engineering roles get access to the metadata stream at full granularity, including the virtual key and model-version detail needed to debug a cost spike. Finance roles get access to the same metadata stream rolled up into cost centers, projects, and model families, without the conversation content attached to it. Neither team gets a watered-down version of a single shared report. Each gets the full view its job requires, drawn from one source of truth, captured once at the gateway, and never duplicated or reconciled by hand after the fact. That single point of capture is what makes the AngelList outcome, a same-day fix once visibility existed, something an organization can count on rather than something it stumbles into after months of silent loss.
