Console

Usage & cost

What the Gateway processed, what it cost, and whether that is going up. Prices are frozen at the moment they were charged, not recomputed from today's catalog.

/dashboard/usage reads the priced ledger for the whole organization, with optional filters for one runtime or one API key. Every row in that ledger carries its own arithmetic — the token counts, the per-million prices that were in force, and the resulting dollar figure — which is what makes a historical number stable.

Org-scoped rather than runtime-scoped, because spend belongs to the organization: the Gateway serves accounts that never had a runtime at all, and the invoice is cut per org.

Cost is priced when it is spent

When a request completes, the Gateway prices it against the model catalog as it stands at that instant and writes cost_usd onto the row. Reading that number back later never re-prices it. Editing a price in the catalog therefore moves future rows and nothing else.

cost_usd is what the customer owes — the provider's list price at the published Lobstack rate on managed traffic, and pass-through on BYOK, where you paid your own provider. What we paid is a separate column and is not surfaced in the Console or the usage API. The arithmetic is on Metering & cost.

That is not a small detail. Before the ledger existed, every dollar figure in the Console was recomputed from the current catalog on each read, so a provider price change silently rewrote last month's spend.

A total built from unpriced rows is a floorThis surface does not estimate. It used to read an analytics route that priced an unknown model at Claude Sonnet rates “so cost never silently disappears”, which meant every row came back with a number and a call the meter could not price was indistinguishable from one that genuinely cost that much. The ledger stores cost_usd as null in that case and the route reports unpriced_requests alongside every sum. Where any of them is unpriced, the figure is drawn as at least this much, the count is stated above the tiles, and the bar for that day carries a marker rather than being filled in.

And when the two ledgers disagree, the page says sogateway_requests traces every request; token_usage is what an invoice is built from. They are two writes and either can fail alone — which happened for three days from 8 September 2026, unnoticed, because nothing compared them. When traced requests are missing from the priced ledger, a line above the tiles says how many and that every dollar below understates what was served.

Time windows

One control at the top — 7, 14, 30 or 90 days — scopes everything below it except the allowance panel, which counts the billing period. Buckets are calendar days in UTC, and every day in the window is drawn including the ones with no traffic: the trace records every request that reached the Gateway, so an absent day is a real zero rather than a missing reading.

The tiles are tokens, split into prompt and completion, and requests, with the failure count and p95 alongside. Each carries a sparkline over the same window.

Breakdown

One table, three dimensions, chosen with a tab: Model, API key or Runtime. Each row carries requests, errors, tokens, cost and p95 for that group alone, the columns sort, and a download button writes the current table as CSV. Time is not one of the tabs, because time is the chart above it.

The whole view is in the URL — period, filters and the chosen dimension — so a link lands somebody else on the same reading.

The spend chart

One bar per UTC day of ledger spend. A day containing unpriced requests is marked rather than filled in, and a day that is entirely unpriced draws only the marker — because the height of a bar is a claim about an amount, and there is no amount to claim. The earliest column is partial: the window runs back to the minute, not to midnight.

The allowance panel

The allowance panel is not scoped by the range control. It counts the current billing period, because that is the period the allowance resets on. Beneath it sits the average cost per request, which is scoped to the selected range.

It renders in the unit the account was actually sold, so it takes one of three shapes. The Overview surface carries the same figures as a compact tile.

Meter	What the panel shows
`spend`	Dollars spent against the allowance, a bar, what is left, the reset date, and the allowance broken into included, topped up and savings credited. Plans that sell top-ups get buttons that open Stripe Checkout for a pack.
`requests`	Requests against the included count, and no dollar figure at all. Those tokens are billed by your own provider at rates Lobstack does not see, so any number here would be invented.
`legacy`	The message quota bar, exactly as it was. A subscription bought in messages is measured in messages.

An em dash is not zeroEvery dollar figure in the panel can be null, and null renders as an em dash rather than as $0.00. A customer who has spent nothing and a customer whose spend cannot be read are in different situations, and one number for both tells the second one something untrue. The allowance table answers today, so a payer with no row yet is the first case — nothing spent, and the panel says so. When the read itself fails, the panel states what the plan includes and says the balance is unavailable rather than inventing one.

What used to be at the foot of this page

Channel mix, session categories, workflow counts, CPU, RAM and disk gauges and a health-check table. All of it reported on an agent VM through /api/agent/analytics, the runtime is retired, and the tables behind the gauges were dropped. None of it is rendered anywhere now, and nothing replaces it: there is no machine to sample.

When the totals are a floor

Two things can make a dollar figure here a lower bound rather than a total, and both are stated on the page when they apply: rows the meter could not price, and a row cap binding on a very large window. Neither is rounded into the number — a floor that is presented as a total is the one failure this surface exists to avoid.