← Use cases

Jev ultrafast

Searching for a "jev-ultrafast" build? There isn't one — and you don't need it. Jev is already the ultra-fast model: it's TypeSafe AI's System One decision model, and it returns a typed, calibrated answer in roughly 70–500ms, often 40–200x faster than prompting a frontier LLM for the same decision. The speed isn't a special mode or a smaller variant; it's how Jev is built. Here's why, and how to make your own calls as fast as they can be.

Jev's model ids are jev-latest (the rolling head) and pinned versions such as jev-1.14 — there is no separate "ultrafast", "turbo", or "mini" tier to opt into. Every Jev call already runs the same fast path. So the real question isn't which variant to pick; it's why one call is so quick, and what on your side keeps it that way.

Jev — one decision ~70–500ms · single parallel pass Frontier LLM — same decision prompt → generate text token by token → parse
One decision: Jev returns the typed answer in a single parallel pass (~70–500ms); a frontier LLM has to generate text token by token and then be parsed.

Why Jev is fast by design

A chat model answers a decision by generating a sentence one token at a time, and then your code parses that prose back into the value you wanted. Jev skips both ends: you declare the answer space up front as typed questions, and Jev emits the typed value directly — one of your options, a score, or a calibrated yes/no — in a single non-autoregressive parallel pass. That one forward pass, not a cut-down model, is the source of the speed. Nothing is decoded token by token, so there's no generation latency and nothing to repair afterwards.

All your questions, one round trip

A single /api/v1/decide call can carry many typed questions, and Jev evaluates them against your state in parallel and returns them together. Routing, an urgency check, and a safety gate on the same ticket are one request and one latency, not three. Collapsing several LLM prompts into one Jev call is often where the biggest real-world speed-up comes from.

How to get the lowest latency

Fast and never malformed

Because Jev only ever emits a value inside your declared answer space, a choice is always one of your options and a noul is always a number — a 0% structured-output error rate. You never pay the extra round trips of retrying a mangled JSON blob, so the fast call is also the reliable one. Its confidence is calibrated too: Jev is trained with RLCD (Reinforcement Learning for Calibrated Decisions), so you can act on the probability directly — auto-accept above a high threshold, send the uncertain middle to a human.

One fast call

This is the whole thing — a tight state, two typed questions in one request, a calibrated decision back in well under a second for a fraction of a cent (output tokens are free):

const res = await fetch("https://jevtypesafeai.com/api/v1/decide", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.JEV_KEY}`, // jv_live_...
  },
  body: JSON.stringify({
    model: "jev-1.14",            // pin a version for stable latency + thresholds
    state: { message: ticket.body },
    questions: {                    // both answered in one parallel pass
      queue:  { type: "choice", instructions: "Route this ticket.",
                criteria: { billing: "payments", bug: "broken", sales: "pricing" } },
      urgent: { type: "noul",   instructions: "Is it urgent?" },
    },
  }),
});
const { answers } = await res.json();
route(answers.queue.choice, answers.urgent.noul > 0.8); // ~70–500ms, typed, no parsing

FAQ

Is there a "jev-ultrafast" model I should use?

No. There's no separate ultrafast, turbo, or mini variant. Jev's model ids are jev-latest and pinned versions like jev-1.14, and every call already runs the same fast path. Jev is the fast model — you don't opt into speed, you get it by default.

Why is Jev so fast?

It's a non-autoregressive parallel sampler: it emits the whole typed answer in one forward pass instead of decoding text token by token. That single pass is why a decision lands in ~70–500ms, often 40–200x faster than prompting a frontier LLM for the same thing — not because it's a smaller model.

How do I make my Jev calls as fast as possible?

Batch every decision about the same state into one call (they're answered in parallel), keep the state tight, pin a version, reuse a warm HTTP connection, and call server-side from a region near the gateway. The biggest win is usually collapsing several LLM prompts into one Jev call.

Does the fast path cost accuracy or reliability?

The speed comes from the architecture, not a quality trade-off. Output is always inside your declared schema (0% structured-output error), and confidence is calibrated via RLCD, so the fast call is also the one you can gate on. Frontier LLMs still keep a few points of raw accuracy on hard tasks — pin a version and validate thresholds on your own data.

See also: How does Jev work · Jev context window · Jev 1.14 (latest version) · Jev benchmarks · Playground

Feel the speed in the browser

Run a real decision with no signup and watch it come back in a few hundred milliseconds, then grab a jv_live_ key and call /api/v1/decide from your own code.

▶ Try Jev freeGet an API key →
Jev ultrafast: why Jev is the fast decision model · Jev by TypeSafe AI