Is Jev really ultrafast? TypeSafe's System One model, tested

Just how fast is "ultrafast"?

Speed is the whole pitch here, so let me start with the numbers TypeSafe actually publishes, then poke at them.

TypeSafe says Jev's end-to-end response time is 70ms to 500ms, against 3 to 329 seconds for frontier LLMs on System One shaped queries. On its homepage it goes bigger with a workflow benchmark: 193.6x faster and 444.6x cheaper, though the launch post is honest that those "are on the higher end of real world gains." A demo on the same page clocks a single decision at 0.114 seconds and $0.000081, against 8.566 seconds and $0.013880 for an LLM baseline.

Here is the same set laid out with the caveats attached, because the baselines matter as much as the numbers.

The 70-500ms range is the number I would actually plan around, because it describes one request rather than a whole workflow. At that latency a decision can sit inside a request that a user is waiting on, which is the thing you cannot do when a classification step takes eight seconds.

Why Jev is fast: one parallel pass, not a token stream

The speed is not a tuning trick, it comes from a different design. An LLM samples one token at a time, in sequence, until it has produced a string for a human to read. Jev generates all its outputs in a single parallel pass and never produces free text at all.

You send Jev a state (a string or a structured object) plus a set of typed questions. It evaluates each question in parallel against that same state and returns typed answers with probabilities and a confidence score. Because each question is scored on its own, TypeSafe says adding more of them barely changes the response time, so you can ask "is this urgent," "which department," and "how frustrated" in one call and still land inside your latency budget.

That is why the framing of Jev as a fast primitive is fairer than "a faster LLM." It slots in wherever you are currently coercing a language model into emitting a JSON blob you then parse and pray is valid, the same "which layer am I choosing" question that shows up in AgentKit vs the Anthropic API. It does not slot in where you need writing, explanation, or multi-step reasoning.

The speed comparison is not quite apples to apples

This is the part the launch-day crowd caught within an hour, and it is worth being straight about. Jev is fast partly because it is doing less. The top comment on the 1,929-point Hacker News thread reframed the whole launch, and the sharper latency critique came right after:

"'70-500ms vs 3-329 seconds' are apples-to-oranges unless the LLM baseline is doing comparable work... If Jev is skipping generation entirely for a narrow structured task, of course it's faster."

ramon156, Hacker News

That is a fair hit. Comparing a model that emits three typed values against a model that writes a paragraph, then calling the first one 200x faster, is measuring two different things. The honest read is that Jev is extremely fast for the decision-shaped slice of work it targets, and that slice is real and common. It is not faster at the jobs it simply does not do.

So the number I trust most is not on TypeSafe's site at all. It came from Vercel's CEO putting Jev into a shipping product:

"We're seeing extraordinary results from @typesafeai... Jev is up to 18x faster (p95) and more accurate."

Guillermo Rauch, X

An 18x speedup at p95 on a live safety-review step is both smaller and far more grounded than the 200x marketing figure, and it points at exactly where ultrafast pays off.

Where the speed actually pays off

Sub-second latency only earns its keep when a decision sits on the critical path, with something waiting on the answer. That is the pattern to look for: a fast checker in front of a slower system.

The worked example Cloudflare publishes is, tellingly, a support ticket: feed Jev "Help! My payouts have been failing for 3 days" and it returns is_urgent at 0.95, department as billing at 0.8 confidence, and a frustration score, all in one call. That is triage, routing, and sentiment in a single request, which is precisely the kind of step an AI ticket triage flow runs thousands of times a day. When each call is 100ms instead of 8 seconds, you can run it synchronously as the ticket lands rather than in a slow background queue.

The developer who summed up the appetite best was already doing this by hand:

"this is exactly how I am using LLMs in production, to narrowly make choices and return structured data... Jev's focus on structured I/O and confidence scores are game changing."

lubujackson, Hacker News

The confidence score is what makes the speed usable in a loop like this: act instantly on the certain answers, and route the shaky ones to a bigger model or a human. That is the same discipline behind good AI agent design and any serious agent-assist step, where the goal is speed without letting a confidently-wrong call reach a customer.

What it costs to run this fast

The other half of "ultrafast" is that it is cheap enough to call constantly. TypeSafe prices Jev at $0.042 per million input tokens with output free, which it frames as 238x lower on input than Claude Fable 5.1, and describes output as "too cheap to meter." There is no standalone pricing page yet, and on sustainability the launch post is refreshingly plain: "We can't prove it isn't subsidized; we'll need the long-term to prove the sustainability of our pricing (which we expect to go down, not up)."

Cheap-per-call plus fast-per-call is what unlocks the Jevons-paradox pitch the model is named for: when a decision costs a fraction of a cent and returns in 100ms, you stop rationing it and start calling it everywhere, the way you already lean on cheap primitives across AI workflow automation. That is a genuinely different posture from paying LLM prices for every classification.

Should you build on Jev's speed?

My read after going through the docs, the demos, and the pushback: reach for Jev when the job is a narrow, well-scoped decision your code consumes and latency is on the critical path, such as routing, moderation, intent detection, scoring, or a fast safety gate in front of a bigger model. That is where the 70-500ms and the free output genuinely change what you can build.

Do not reach for it expecting a faster ChatGPT. It does not write, explain, or hold a conversation, and a tool this fast invites overuse on jobs a simple classifier or rule should own. The line to hold is that Jev is a primitive: it gives you a great decision in milliseconds, and you still own the pipeline, the escalation logic, the deflection strategy, and every action after the decision. Speed at the decision does not buy you any of that.

Try eesel

If you run support, the honest translation is this: Jev is a brilliant engine, not the car. It will tell you a ticket is urgent, billing, and from a frustrated customer in about 114 milliseconds. It will not open the ticket, draft a reply grounded in your help center, apply the refund, or hand off to a human when it is unsure. Someone still has to build that layer.

eesel is that finished teammate. It is an AI support teammate you plug into your helpdesk, and it already makes the triage, routing, and escalation calls Jev exposes as primitives, then acts on them end to end. It learns from your past tickets and help center, and you can simulate against historical tickets before it ever touches a live customer.

And if you liked Jev's developer ergonomics, you will like this: eesel is not dashboard-only. The eesel CLI (npx @eesel/cli) operates the same teammate from a terminal, a person can run eesel chat or eesel activity by hand, scripts can automate it in CI, and coding agents like Claude Code, Codex, and Cursor can drive it, since every command prints JSON and --dry-run shows the exact call before it fires. Every workspace is also an MCP server. Jev gives you the fast decision; eesel gives you the teammate that acts on it. You can try eesel free.