Jev speed, cost and calibration: what RLCD means for your thresholds

Jev's pitch rests on three numbers: speed, price and calibration. Here is what each one actually is, who reported it, and what it means when you design a system.

Speed: 70–500 ms per request

TypeSafe reports end-to-end response times of 70–500 ms, versus seconds to minutes for frontier LLMs, and says this is 40–200× faster on System One-shaped queries (launch post). Two caveats from the same post: its evals were run from laptops on the US West Coast, where the service is hosted, and its workflow benchmarks were built by TypeSafe's own team.

Why it is fast: Jev does not generate tokens one at a time. It reads the state once and produces every answer's probability distribution in a single parallel pass. Practical consequences:

• More questions ≈ same latency. Pack related questions into one request.
• Long state is the main cost of time. Send the relevant fields, not whole pages. Long-context mode (up to 262k tokens) exists but is slower and less accurate (TypeSafe docs).
• Measure from your region. Network distance to the provider matters at this scale.

Cost: $0.042 per million input tokens, output free

TypeSafe's models page lists Jev 1.14 and Jev 1.13 at $42 per billion input tokens ($0.042 per million), with output tokens free (TypeSafe docs). OpenRouter lists the same input price for Jev 1.14 (OpenRouter). TypeSafe notes it cannot prove the price is not subsidized and expects it to go down rather than up.

Rough sizing: a short support ticket with three questions was about 450 input tokens in OpenRouter's test, so about $0.00002 per call. Your bill is driven almost entirely by state length × call count. Check your provider's model page (for example Jev 1.13 on Flatkey) before budgeting.

Calibration and RLCD

TypeSafe trains Jev with Reinforcement Learning for Calibrated Decisions (RLCD). Its framing: RLHF optimizes for answers people prefer; RLCD optimizes for decisions whose probabilities are epistemically honest, so higher confidence should mean higher accuracy (launch post). The training details are unpublished; Wikipedia notes outside speculation that it may resemble supervised training with calibration-penalizing loss terms such as the Brier score, but that is not confirmed (Wikipedia).

What calibration means for you:

• It is an aggregate property. "0.8" means roughly 80% right across many similar answers, not that this answer is 80% right.
• Confidence ≠ correctness. The returned confidence measures how concentrated the probabilities are (Confidence docs). Jev can be confidently wrong.
• Calibration is on Jev's training distribution. Check it on yours.

Setting thresholds in four steps

1. Label 200–500 real inputs.
2. Run them through Jev and bucket by confidence (or by Noul probability).
3. Plot accuracy per bucket. If it rises with confidence, calibration holds on your data.
4. Pick an act threshold where the error rate is acceptable, a review band below it, and escalate under that. Pin the model version you calibrated on.

Probabilities shift slightly between calls (OpenRouter saw a few hundredths of variation on identical requests), so define bands, not exact cut-offs.

See it working

The confidence lamp use case turns confidence into act / confirm / escalate; criteria-based model routing uses Jev to decide when a cheap model is enough. Both include copyable code.