Decision latency and Jev speed claims
Jev (TypeSafe System One) is sold as a fast decision layer, not a chat model. Latency numbers you see in blogs are almost always vendor claims. This explainer states what TypeSafe said they measured — and what you should measure yourself. Independent unofficial page. Canonical docs: docs.typesafe.ai.
What the vendor 40x–200x (and 193x) figures measure
From TypeSafe’s 15 September 2026 launch post (typesafe.ai/blog/…), labeled here as vendor claims:
| Claim | What they say it is | Nuance they published |
|---|---|---|
| End-to-end 70ms–500ms | TypeSafe response time | Contrast with “3 to 329 seconds” for frontier chat models in the same table |
| 40x–200x faster | Same “frontier intelligence” on System One-shaped queries | Not a promise for generation, tool loops, or your region |
| 193.6x faster / 444.6x cheaper | Homepage-style figure from their workflow evals | They say these sit on the higher end of real-world gains; workflows built by their capabilities team; reference = average of named large LLMs in a System One wrapper |
| Parallel sampling | All questions in one query, not token-by-token strings | Side-by-side demo used a short, dense state that “paints our model in an advantageous light” |
They also say published speed checks were generally run from West Coast laptops (service location they disclosed). Your p50 will include TLS, region, and door (Gateway vs first-party).
The parallel questions cookbook claims 12.2× cheaper and 10.0× faster batching 13 questions vs 13 calls on one GDPR article — again their measurement, not ours.
We do not invent a jev.pro latency number.
What actually dominates your clock
- Door RTT —
api.typesafe.aivs Vercel vs OpenRouter vs Workers AI. - State tokens — billed and, on
jev-1.13, accuracy-toxic when irrelevant. - Question count — official story: extra questions cost tokens, barely wall-clock, because they run in parallel. Still verify.
- Retries — 429/529 backoff can dwarf a 200ms success.
- What you do after — if Jev routes to a reasoning LLM, that LLM owns the user-visible latency.
Adding questions is usually cheaper than adding a second HTTP call. Chaining Choices to generate text is officially slow and weak (jaggedness).
How to time a path (no vendor numbers required)
import time
from typesafe_sdk import Choice, Noul, TypeSafeClient
client = TypeSafeClient(model="jev-1.13.0")
state = load_ticket() # your production-shaped state
t0 = time.perf_counter()
r = client.system_one(
state=state,
questions={
"dept": Choice(instructions="Queue", criteria={"billing": "…", "tech": "…", "other": "…"}),
"urgent": Noul(instructions="Time-sensitive?"),
},
)
ms = (time.perf_counter() - t0) * 1000
log(ms, r.model, r.usage.input_tokens)Record success-only p50/p95, error rate, and resolved model. Compare to an LLM-in-a-JSON-schema wrapper on the same questions if you need a relative number. Methodology: offline evaluation.
FAQ
Is 193x a benchmark I can cite in a procurement deck? Cite TypeSafe and quote their caveats (high end, in-house workflows, West Coast). Do not cite jev.pro as the measurer.
Does pin jev-1.13.0 change latency vs jev-latest?
Only if the alias moves to a different build. Today’s models page had both aliases on jev-1.13.0.
Rate limits? Vendor: 250,000 tokens/s and 1,200 rpm, dynamic. 429 is a latency event.
Limits
No independent bake-off. Schema-safe ≠ correct. Hub: Explainers. Sibling: offline evaluation.
Sources
Public TypeSafe or adjacent documentation only. No private claims.