The dashboard
What each number means, why the lead metric is money you did not spend rather than usage, and which rows are deliberately excluded from every total.
Every layer of Soba produces one number, and the dashboard is where they meet. It leads
with the one no gateway can compute.
Inference you didn't pay for#
The headline figure, per month, and deliberately not a usage graph.
It is the sum of what the runs served on user-hardware and user-subscription
compute would have cost had your app served them on its own keys: the money that
stayed in your account because the run landed on compute your user had already bought.
user-key is counted separately, and deliberately. Those runs also cost you nothing,
but they are not free: they spend the machine owner's provider account by the token, so
folding them in would make the headline figure larger by counting money somebody else
paid.
It is auditable, which is the point
Take the figure, take your own provider bill for the same month, and the two should
explain each other: the runs your app served (app) are on your bill, and the ones in
this figure are on nobody's, which is what makes them a saving rather than a transfer. A
number you cannot check against an external document is a number you eventually stop
believing.
It is also the figure a plan exists to move. The connectedReward lever
buys connection rate, connection rate moves this number, and the difference between the
reward's cost and this number is the whole economic case.
The rest of it#
|
What it answers |
| Users |
Who is on which plan, their allowance and what they have used this period |
| Runs |
Every run with its cost class, its cost in micros, the model, and whether it ended on done or error |
| Machines |
Each connected machine, its runtimes, whether it is awake and whether its CLI is signed in |
| Connection rate |
The share of users who have connected their own compute. The number the reward is buying |
| Conversions |
Which trial users became paying customers, when, and what their trial looked like: runs on their own compute against runs on your keys, and how long after the allowance ran out they paid. See Stripe |
| Cost class mix |
Where runs actually landed, which is how you tell a routing intent from a routing outcome |
| Spend |
Metered cost against your ceilings, per run and per period |
| Failures |
Runs that ended on an error, grouped by cause |
| Stripe activity |
Every write Soba made to your Stripe account. See Stripe |
Cost class mix is the one people underuse. An app can declare
prefer: ["user-hardware", "user-subscription"] and still hand 80% of its runs back
to your own app, because preference is not reachability. The mix is where that shows up,
and it usually means machines are asleep rather than that the route is wrong.
Troubleshooting a machine is the other half of that story.
Environments change every total#
An environment switcher sits on the app, defaulting to
production, and the aggregates are not simply filtered by it:
development is excluded from every aggregate. Billable usage, connection rate,
inference you didn't pay for, cost class mix. A developer testing against their own
machine is arithmetically identical to a customer connecting theirs, and counting
them would inflate every headline number with the people building the product.preview is shown separately, never hidden. It costs real money on your own
keys and you need to see it. It is not customer revenue, so it never enters the
avoided-cost figure.
That exclusion is the reason environments exist at all. Everything else they do is
downstream of getting these numbers honest.
What it does not show#
Prompts and outputs. The dashboard is built from usage and run records (model,
provider, token counts, cost class, cost, outcome), because that is what billing and
routing need. What a run was about is your product's business, and
What Soba sees says exactly where that line falls.