← /blog
· ACE Engineering#scorecard #frontend #dashboard #observability #finops #cost #gateway #managed-api-stack

The receipt, not the promise: ACE's real-time cost dashboard

Every cost-saving layer in ACE — cache, router, compaction — is a claim until you can see it happen. Here's what the built-in dashboard shows, where the numbers come from, and why the whole point is that you never have to take our word for it.

The receipt, not the promise: ACE's real-time cost dashboard

A cache that says it saved you money, a router that says it downgraded a request to a cheaper model, a compactor that says it shrank your prompt — none of that is worth anything to a buyer unless they can watch it happen. Every other post in this series describes a layer that cuts your bill. This one is about the thing that turns the claim into a receipt: a live dashboard the gateway gives you out of the box, fed by the same request stream that serves your traffic.

What you actually see

Open the dashboard on a running ACE gateway and the first thing that loads is Proxy Savings — CFO Proof: five headline numbers — tokens saved, dollars reclaimed, cache-hit ratio, savings rate, and latency delta — each with its own live trendline. Scroll and it gets more specific:

  • Request pipeline — how many requests came in, how many were answered from cache, how many were compacted before the upstream call, and what that compaction actually did to the token count.
  • Routing distribution — which requests got classified into which skill/complexity bucket, and which model endpoint actually served them.
  • Cost attribution — spend and savings broken down by provider, team, and feature tag, plus a run-rate projection once there's enough traffic to extrapolate from.
  • Request lifecycle — the most recent requests, each annotated with what happened to it: cache hit or miss, which routing tier, how much it was compacted, what it cost, and what the same tokens would have cost against your most expensive model as an explicit counterfactual.

There's no separate BI tool to stand up and nothing to integrate. The dashboard renders itself straight out of the gateway with no charting library, no JS framework, no CDN dependency to bring in — a deliberate choice, not a shortcut: a security team evaluating a gateway shouldn't have to also audit a dashboarding stack.

Where the numbers come from

The thing worth trusting isn't any single card, it's that every card on the page is a view over one event stream, not five independently-maintained counters that can quietly drift apart from each other. Every request — cache hit or miss, cheap-tier or flagship, compacted or not — produces one record carrying tokens in and out, cost, cache tier, provider, team, and latency. The dashboard, the metrics feed, and the ROI analytics view all read from that same shape — so "tokens saved" on the dashboard and "tokens saved" anywhere else in the system can't disagree, because they were never two separate ideas to begin with.

Recording that event is synchronous and non-blocking: it's appended and returned instantly, never holding up the response the caller is waiting on. That matters because the moment cost accounting adds latency to the thing it's supposed to be saving latency on, you've built a tax, not a savings layer.

The "dollars saved" number is a counterfactual, and getting it right is worth taking seriously: a cache hit costs effectively nothing, but what it avoided has to be credited as the real avoided cost, not a rough capacity guess. Get that wrong and two one-word exchanges can appear to "save" tokens that never existed — a savings number that quietly overstates itself in your favor is worse than one that undercounts, because nobody double-checks a number they like. The dashboard's underlying invariant is blunt about this: tokens saved can never exceed tokens actually processed.

Why this is its own layer, not a feature of the others

It would be easy to treat the dashboard as a nice-to-have wrapped around the cache, the router, and the compactor. It isn't. A savings claim you can't observe isn't a savings claim you can act on — you can't tune a cache threshold, catch a routing regression, or notice a compaction ratio drifting to zero if the only evidence is a number someone told you. The dashboard is what makes every other layer in this series accountable to the traffic actually flowing through it, in real time, without asking you to wire up a separate observability stack first. That's the direction all of ACE's cost-saving layers are headed: not just doing the optimization, but making it something you can watch happen and verify for yourself.


References

  1. FinOps Foundation, FinOps Framework — the industry vocabulary this dashboard's "reclaimed spend" and cost-attribution views are built around. finops.org/framework
  2. Prometheus, Exposition Formats — the plain-text metrics format this kind of gateway telemetry is built to be compatible with, so an existing Prometheus/Grafana setup can scrape it directly. prometheus.io/docs/instrumenting/exposition_formats
  3. Timescale, TimescaleDB Documentation — the class of time-series Postgres store this kind of production telemetry backend is built on. docs.timescale.com