About
Three refusals.
Fine-tuning an open-weight model is a solved problem in the narrow sense. The recipes are published, the libraries are mature, and the hardware is rentable by the hour. What is not solved is everything around it — and the complaints in this market are remarkably consistent: a run that cost three times what anyone expected, a model that scored well and disappointed in production, and weights nobody could get at when it was time to leave.
So the product is organised around three things it will not do.
It will not lease compute before the cost is authorised. Every job is estimated and reserved against a limit you set, counting reservations already open. A job that would breach the ceiling does not start. A spend limit checked after the fact is a notification.
It will not deploy a model that has not won. Every candidate is scored blinded against the model it would replace, on held-out cases from your own data. The gate returns pass, fail or inconclusive, and a recorded failure cannot be marked as passed by a person having a bad week.
It will not hold your weights. Every finished run is downloadable and publishable to a model hub in one call. Serving speaks the OpenAI chat-completions API, so leaving costs a base URL change. This is deliberately the easiest thing to verify about us.
What it is not
It is not a general model API, a research platform for custom training loops, a GPU marketplace, or something you can run on your own hardware. Each of those is a real product category with better answers in it than us, and the comparison pages name which.
It is also opinionated in a way that will annoy some people. Runs execute within validated templates, models come from a curated catalogue, and every run is single-GPU. Those constraints are what make cost forecasting, resumption and the gate possible; if they are the wrong constraints for your work, we would rather you found that out from this page than three weeks in.
On the compute layer
Compute is serverless across multiple providers. We publish everything a caller can observe — the GPU class, its memory, its hourly rate, the scaling behaviour of an endpoint, what is metered and when. We do not publish which providers, how capacity is selected, or how the platform is deployed. That is the same position any company takes on its own infrastructure, and it does not withhold anything that affects a decision you make.
Who
Onrup is built by Dipankar Sarkar. It is a commercial product, not an open-source project. The fastest way to reach a person is hello@onrup.com.
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.