jAIn · available today
jAIn searches model space against your table, scoring every candidate on held-out accuracy and inference latency together. Search runs once. The model it finds runs on every request after that.
→ Latency is scored as hard as accuracy, so the search rejects the heavy ensembles that usually win offline benchmarks. It passes your production model on accuracy just before the hour — and by then the winner is already several times faster to serve. You pay for search once. You pay for inference on every request for the life of the model.
+4.1 points of accuracy and roughly a tenth of the inference cost, on the same table, from one eight-hour search.
Hosted sandbox, nothing to install — or pull the container and point it at your own data.
Where jAIn loses, the benchmark below shows it.
Scored on held-out data under your metric, against the incumbent your team built and tuned. Where it doesn't win, the benchmark below says so.
A candidate that gains a point of accuracy and triples inference cost loses. The winners are lean because leanness is scored, so the model you deploy is usually several times faster than what it replaces.
The winner exports as plain code and weights you own and deploy. If you cancel tomorrow, what it found is still serving traffic on Monday.
How it works
A person tuning a model tries maybe forty things and gets tired. jAIn proposes candidates continuously — preprocessing, model family, hyperparameters, ensembling, pruning and distillation, all as one search space rather than six separate decisions.
Every candidate is scored twice — once on held-out accuracy, once on what it costs to serve. A stack of nine models that gains a point and takes 90ms loses to a single pruned tree that gains half a point and takes 5ms. Most AutoML optimises only the first number, which is why its winners are so expensive to deploy.
The plateau is real and we'd rather show it than hide it. Past a certain budget the search is finding tenths, and on most problems that's the point to stop and ship.
The record
Each row is a real dataset with a real incumbent model a real team had already built and shipped. Same metric they used, same hardware for the latency measurement. Losses are in the list.
| Dataset | Incumbent | Metric | Hand-built | jAIn | Δ | Inference |
|---|
Under a few thousand rows, selection pressure overfits the held-out split before the search finds real structure. A regularised GLM usually wins and is easier to defend.
When you already know the governing relationship, encode it. jAIn has no way to take your domain knowledge as an input yet, so it spends budget rediscovering it.
If irreducible noise dominates, our median lift is under a point. Real and measurable, and rarely worth a procurement cycle.
If a regulator needs coefficient-level reasons, a searched ensemble is a harder story than a GLM. Attribution ships, but attribution isn't structure.
Two ways in
Same search either way. Most people evaluating jAIn pull the container and point it at their own table — if you'd rather see it work first, the sandbox takes about thirty seconds.
Runs fully on your hardware. No upload, no callback, no telemetry. Works in an air-gapped environment.
Email and password, then upload a CSV. No role dropdown, no use-case form, no call with anyone.
Where it plugs in
Deployment is a container and a service account, not a migration.
Enterprise
We work with a deliberately small number of design partners at a time. If jAIn earns a place in your stack, this is what the next conversation covers.