Same call, same answers
You set one number, target_agreement. Jevstiller returns the label Jev would have returned on
at least that share of requests, and keeps checking it on live traffic.
before your app ──► Jev
after your app ──► Jevstiller ─┬─► local model most requests └─► Jev unsure, novel, or 2% auditSame call, same answers
You set one number, target_agreement. Jevstiller returns the label Jev would have returned on
at least that share of requests, and keeps checking it on live traffic.
Past the rate limit
Jev caps out at 1,200 requests a minute. The local model runs at thousands per second on one GPU, with single-digit millisecond latency.
A bound, not a vibe
Routing thresholds are chosen against a Clopper–Pearson upper bound on held-out data, then re-verified forever on a random audit slice.
Falls back on its own
If the audit shows the contract is broken, every request goes back to Jev until a new model passes.
Jev is fast, cheap and typed. It is also a ceiling: 1,200 requests per minute per key, ~350 ms per answer, hosted only. Jevstiller is for the workload that outgrows that: bursts, backlogs, latency budgets in milliseconds, boxes with no egress, or not wanting every classification to depend on one external API.
In an offline replay of Banking77 (77 intents), the local model took 71% of traffic at 99.5% agreement with the teacher, at ~2,000 rows/s on one GPU. How that was measured →
Alpha (0.1.0). The loop is tested end-to-end and validated on replays with a perfect “oracle” teacher. The
benchmark against live Jev is pending. The next milestone is a
drop-in HTTP proxy: point TYPESAFE_BASE_URL at it and change no code.
Jevstiller is an independent open-source project (MIT). It is not affiliated with, endorsed by, or supported by TypeSafe.