Pillar
A price you authorise before it is spent.
How does Onrup stop costs running away?
Before any job leases compute, its maximum cost is estimated and reserved against your available headroom — your limit minus settled spend minus reservations already open. If the reservation cannot be made, the job does not start. The limit is a gate in front of the work, not an alarm behind it.
The sequence matters more than the feature
Almost every platform in this category has spend controls of some kind. The question worth asking is when they run. Measuring consumption and firing an alert past a threshold tells you about an overrun once the money is gone. That is useful, and it is not a limit.
Here the order is: estimate the maximum cost of the job, reserve that amount against available headroom, and only then acquire compute. A job that would breach the ceiling returns a specific error at submission and never reaches a GPU.
The second half is counting open reservations, not just settled spend. Without that, three jobs submitted in the same second each pass the check individually and collectively exceed the limit — which is exactly the scenario where an overrun is least expected and hardest to explain afterwards.
What you see
{
"plan_id": "pro",
"subscription_status": "active",
"allows_compute": true,
"spend_limit_cents": 50000,
"reserved_cents": 1840,
"settled_cents": 12655,
"available_cents": 35505
}Available headroom is a computed figure rather than a subtraction you are expected to do yourself. When a submission is refused, the error carries both the estimate and the headroom, so the reason is in the response rather than in a dashboard.
Metering you can reason about
Compute is metered per GPU-second above a one-minute floor, from $0.09 per GPU-hour. Time spent waiting for capacity is not billed. Teardown is not billed. Metering starts when your job is on the GPU and stops when it comes off.
Every usage event records the pricing revision in force when it happened, which means an invoice from six months ago can be reconstructed exactly even after prices change. Events that have not yet settled are reported separately rather than folded into a single figure that pretends the delivery lag does not exist.
Where the money actually goes
For a model that reaches production, training is a handful of bounded runs and serving is every request forever. The single most common source of waste is not an expensive training run — it is an always-warm endpoint left over from an experiment three weeks ago, billing continuously with nothing calling it.
The second is model size. Deploying an 8B for a task a 1.7B handles identically is a decision paid for on every request, indefinitely. The evaluation gate makes finding the smallest sufficient model a measurement rather than an argument.
Frequently asked questions
What is the difference between a spend limit and a budget alert?
When it is checked. A reservation is made before compute is leased, so a job that would breach the ceiling never starts. An alert fires after the money is gone, which makes it a notification rather than a limit.
What happens if I hit the limit mid-run?
Running work continues to its natural end — killing it would waste everything already spent on it. New work is refused with a specific error code until headroom exists.
Why do reservations expire?
An abandoned job would otherwise hold budget forever. Reservations release after a fixed window and the headroom returns.
Do I pay for queue time?
No. Metering starts when your job is on the GPU and stops when it comes off. Waiting for capacity and tearing down afterwards are not billed.
Start with the free tier
A magic link creates your account, your tenant and your first API key. No card until you ask for compute.