An owner told us why he’d moved work off our agent and back onto a fixed-price tool. Not accuracy. Not speed. He couldn’t tell what he was spending. “I have no idea what my burn is on this. I have no idea what the cost is by looking at the usage.” That’s a product problem, and this week it shipped fixed, in three parts.
The problem with tokens
Nobody budgets in tokens. A construction business runs on line items, invoices, and a monthly number somebody has to defend. When a usage dashboard says 11M of 40M remaining, it is technically precise and practically useless. It asks the customer to hold your pricing table in their head and do arithmetic before they can answer the only question they care about. Am I about to get a hefty bill?
The alternative they compare us against isn’t a cheaper AI. It’s a predictable one. A fixed per-seat price is legible even when it’s more expensive, and legibility wins deals. Opaque token math quietly converts a pricing advantage into a churn signal.
We had built the meter for ourselves. Every number on that page was one an engineer would want. Tokens consumed, tokens remaining, a weekly average. All correct, and none of it in the unit the person paying the invoice actually thinks in. That gap is easy to miss from the inside, because the dashboard looks complete.
So the fix wasn’t a new feature. It was making the existing numbers answerable. A dashboard that can’t be reconciled gets ignored, and an ignored meter is the same as no meter. The customer stops checking, then gets surprised by an invoice, and the surprise is what costs you the renewal. Legibility isn’t a courtesy on consumption pricing. It’s the product.
1. Dollars on every metric
Every token figure on the Usage page now carries a dollar counterpart. The headline shows what’s left in currency alongside the token balance. The monthly breakdown shows spend for the month. The per-user, per-channel, and per-skill views each show their own cost, and the weekly average is expressed both ways.
One detail matters more than the rest. The conversion uses the tenant’s own pack pricing, not a fleet-wide average rate. A blended rate would have been faster to build. It also would have produced numbers that don’t reconcile against an actual invoice, which is worse than showing no dollars at all. A number that’s close but wrong destroys trust in the whole dashboard. The math is also traceable. The page links out to the pricing it’s applying, so anyone who wants to check the arithmetic can.
2. Export, because spreadsheets win
The second thing that owner asked for was blunter. “Can I chart this out or can I export this information? I’d like to be able to do it without manually keystroking it in.”
Usage now exports. One row per usage event, with timestamp, channel, user, skill, tokens, and cost. The export respects whatever filters are on screen, so the file matches what you were looking at rather than dumping everything. Finance people don’t want our charts. They want to reconcile our numbers against a bill in their own tooling. If that takes manual re-keying, it doesn’t happen, and the numbers stay unverified.
Tenant boundaries hold on the export path, not just in the UI.
3. The bug we’re least proud of
Digging into one customer’s usage turned up something uncomfortable. Some of the tokens on their dashboard were ours. Sessions our support and QA people ran inside their tenant, triage and testing and agent-in-Teams debugging, were metered against the customer’s quota. Their “10M used” was inflated by our own work.
To be clear about what this was and wasn’t. It was not a tenant-isolation problem. Nobody’s data crossed a boundary. It was a billing-attribution bug. It’s the kind that only ever errs in our favour, which is exactly why it deserved a P0.
The fix classifies every LLM call by who actually initiated it, then excludes Boon-side usage from the customer’s usage view, breakdowns, activity log, and exports. All of it happens at a single choke point, so the surfaces can’t drift apart. It’s now enabled for affected orgs.
The interesting part is a signal we deliberately didn’t implement. The original plan included matching on usernames containing boon or support. It sounds reasonable until you look at real customer directories, where support@ addresses and people with surnames like Boone are perfectly ordinary. Misclassifying a real user as internal means silently under-billing them. Worse, it means hiding their usage from their own dashboard. We kept the precise signals, service-account identity and verified staff email domain, and dropped the fuzzy one. Then we wrote tests specifically to prove the false-positive case stays closed. Three good signals beat four with a landmine in it.
Why this is worth a post
None of these three are impressive engineering. Together they’re the difference between a customer trusting the meter and a customer routing around it. Every AI product billed on consumption owes its users a legible answer to “what is this costing me,” in their currency, exportable, and free of the vendor’s own traffic.
We’re probably still getting part of this wrong. The dollar figures are only as good as the pricing they’re keyed to, and a customer mid-way through a plan change will see a number that needs explaining. That’s the next thing to fix.
If you’re evaluating agents on consumption pricing, that’s a fair thing to demand before you sign. Of us, or of anyone else.
