Jev vs OpenAI's Decisions API: which to build on

Jev vs OpenAI’s Decisions API comes down to four differences: price ($0.042 vs $0.10 per million input tokens), inputs (Jev is text-only, OpenAI’s takes images), access (Jev is waitlisted early access, the Decisions API is an open public beta), and compliance posture (OpenAI documents Zero Data Retention and HIPAA eligibility; TypeSafe does not advertise an equivalent). On the part that matters most — whether the probabilities are trustworthy enough to automate on — neither has independent, published calibration numbers. That one you settle on your own data.

What a decision model returns

Both do the same unusual thing: you send evidence (a ticket, a document, a form) plus typed questions, and get back a typed answer with a probability distribution and a confidence value. No prose, no JSON to parse, no retry when the model wraps its answer in an apology. We covered the category in what System One models are; here is the shape, from TypeSafe’s quick start:

{ "department":  { "choice": "technical", "confidence": 0.78,
                   "probabilities": { "technical": 0.85, "billing": 0.15, "sales": 0.0 } },
  "frustration": { "score": 1.0, "confidence": 1.0 },
  "is_urgent":   { "noul": 1.0 } }

OpenAI’s Decisions guide uses near-identical vocabulary: choice, score, and predicate (TypeSafe calls the yes/no primitive a Noul), each returning probabilities plus confidence. Two labs converging on the same interface within a fortnight is the strongest signal here — stronger than any benchmark either of them published.

Jev vs OpenAI’s Decisions API, side by side

Every figure below comes from the vendors’ own current documentation, read on 12 October 2026.

The price gap is 2.4×, which sounds decisive and usually isn’t: at these rates a million decisions a month costs tens of dollars either way. The gaps that change an architecture are images (if your evidence is a photo of damaged goods, Jev is out until you OCR it) and access — you cannot put a waitlist on a roadmap.

What a real swap looked like: 88% cheaper, 10 days to production

TypeSafe has published one customer case study, and it is unusually specific. Talent marketplace Jack & Jill replaced Gemini 3.1 Flash Lite with Jev for the initial scoring stage of candidate matching — 6,000 candidates per open role, daily. Their published numbers: cost per 1,000 candidates scored fell from $0.755 to $0.092, median screening time from 20.3s to 10.3s, and recall of “winners” (candidates a hiring manager later asked to meet) went from 93.9% to 94.6% — a difference the write-up itself calls statistically insignificant. Ten days from first test to 100% of calls.

Two caveats: it is a vendor-published study about a vendor’s own customer, which we have not independently verified, and the baseline was already a cheap model — the honest headline is “8× cheaper than Gemini Flash Lite”, not “100× cheaper than AI”. The useful part is the method anyway: 150 live roles with known outcomes, counting how many real winners each model kept, plus AUC (0.924 vs 0.933). A day of work, and the only thing that tells you whether a swap is safe.

What independent testing says, a month in

Jev launched on 15 September 2026; the Hacker News thread is at 1,989 points and 520 comments as of today. What has surfaced since:

• InfoQ reported an OpenChamber analysis of 12,759 launch-week posts: a median 7× speedup and 30× cost saving against TypeSafe’s headline 193.6× and 444.6×, at 76ms median latency. TypeSafe’s own announcement concedes its figures “are on the higher end of real world gains”.
• Every’s Dan Shipper ran editorial checks over twelve passages: a median 0.35s per passage against 8.83s for Fable 5.1, catching six of seven planted defects to Fable’s seven. Faster and cheaper, marginally less accurate — on twelve passages, which is a vibe check, not a benchmark.
• The loudest HN critique is that the latency comparison is apples-to-oranges: a model emitting a constrained decision does less work than one generating prose, so the multiplier depends entirely on the baseline. That holds.
• “Can’t hallucinate” means “can’t emit an invalid type.” TypeSafe is straight about this — its 0% figure is “not empirical”, it follows from schema matching. A valid-but-wrong answer is still entirely possible, and is the failure mode your review queue exists for.

A note on sourcing: a widely-shared practitioner write-up on Medium argues that the real shift is from tokens to decisions as the unit of AI in a backend. We agree with the architecture argument, but it reports no measurements of its own — its examples and limits come from TypeSafe’s documentation — so read it as a well-argued opinion, not independent evidence.

The limits both vendors document

TypeSafe publishes a jaggedness page for jev-1.13 listing nine known failure modes, last reviewed 2 October 2026. The ones that bite in automation work: it reads instructions literally, it does not count reliably, it cannot compare dates, accuracy drops as the state fills with irrelevant detail, and answers can shift with the order of your choice options. Keep arithmetic, dates and permissions in code; give the model the judgment call only.

Two operational details. TypeSafe’s rate limits are subject to change without notice while demand is high, and jev-latest is an alias that moves when a new version ships — if you tuned thresholds against a version, pin the versioned ID. OpenAI’s guide gives the equivalent advice: set thresholds from labelled examples in your own application, weighing false positives against false negatives.

How we’d choose

Havoric is an AI automation and web development agency — we automate repetitive manual processes and build the web and mobile apps around them, and classification-and-routing steps are the bulk of what sits inside those automations. What we would do on an AI automation project this quarter:

1. Build the eval before you pick the vendor. 150–300 historical cases with known outcomes, from your own logs. Measure recall of the cases that mattered and accuracy at your confidence threshold, not overall.
2. Put decisions behind one interface. One decide() function that maps your questions to a provider’s request shape. Then “Jev vs OpenAI’s Decisions API” is a config change you rerun the eval against, not a migration.
3. Default to the open beta for anything with a deadline. A waitlist is a project risk, not a technical one, and it is the harder kind to explain.
4. Keep the human review queue regardless. Calibrated probabilities make the threshold meaningful; they do not make the low-confidence branch unnecessary.

The pattern we keep seeing as an AI agency is that the model is the cheapest, most swappable part of any automation — and the teams who capture the cost reduction are the ones who already had an eval and a review queue to swap against.