Jev answers yes/no and multiple-choice questions with calibrated confidence

TLDR

Jev (closed, TypeSafe, launched September 15): a model that answers yes/no and multiple-choice questions with a confidence score attached, instead of writing prose. Spam or not, which queue, how urgent, one to five. Answers in 70 to 500 ms, at $0.042 per million input tokens, listed in beta on OpenRouter. Think classifier, not chatbot.

OpenJev (open, September 16): the same idea running in your browser on WebGPU. No API key, no server, no waitlist. Open openjev.com, pick a model, and decisions run on your own device, including a phone. On a consumer RTX 3090 the full reproduction reaches 96 percent of Jev’s published agreement.

The one-sentence split: a regular LLM writes the essay; Jev answers the multiple-choice question.

View this post on X →

Do you need a 3090? No.

This is the most common confusion in the discussion, so here is the direct answer.

The 3090 belongs to the OpenJev repo’s benchmark rig: the measured comparisons (5.21x faster than JSON generation, the accuracy tables) were run natively with the full Qwen3.5-4B model on an RTX 3090. That is the lab setup, not the requirement.

The browser demo is a different build. The page itself is about 2 MB of HTML, JavaScript, and CSS. The model weights download once - 639 MB for Qwen3 0.6B, 1.56 GB for MiniCPM5 2B, 3.01 GB for Qwen3.5 4B - then live in your browser cache. After that, inference runs entirely on your device through WebGPU. No API calls, no cloud round-trip, works with the network disconnected after the first load.

The demo detects phones and switches to the 0.6B model automatically. Anything current that runs WebGPU - desktop Chrome, Edge, Firefox on a laptop, modern Android - can run it.

Where each one runs

	Jev via OpenRouter	OpenJev native	OpenJev in browser
What it is	TypeSafe’s closed decision model, beta	The reproduction on your own GPU	Same weights, WebGPU, client-side
Hardware	None (cloud)	Consumer GPU (a 3090 was used for the measurements)	Any WebGPU browser, phones included
First load	Nothing to download	Model weights on disk	~2 MB app + 639 MB to 3 GB one-time weight download
Latency	70 to 500 ms end to end	1.0 s for 21 parallel decisions, 0 output tokens	Same class as native, scaled to the device
Cost	$0.042 per million input tokens, output free	Electricity	Free
Privacy	Data leaves your machine	Stays local	Never leaves the device
Accuracy (TypeSafe subset)	0.883 (published)	0.845 (Qwen3.5-4B, native)	0.813 (browser Q4 builds)

*Three ways to run it: through their API, on your own GPU, or in your browser - the last one needs no server at all.*

What using Jev actually looks like

Skip the architecture talk. Here is a real exchange.

Your app has a support ticket and needs it routed. You send Jev one request with the ticket text and the question:

ticket: "My invoice shows $340 but my card was charged $420."
question: "Which team should handle this: billing, technical, or refunds?"

Jev answers back:

billing: 0.87
refunds: 0.11
technical: 0.02

That is the whole response. Your code reads it like a hash: if answer.top == "billing" { route(billing) }. No essay to parse, no “I’d be happy to help with your billing question” fluff to strip out, no JSON schema to validate against. And the 0.11 on refunds is information - if the gap between first and second place were 0.04 instead of 0.76, you would know to send this one to a human.

Ask it a yes/no question instead and you get one number back: “Is this customer about to churn?” returns 0.31. Your code applies a threshold: above 0.6 fires a retention offer, below 0.2 does nothing, in between queues a human look. You decided the threshold; Jev supplies the probability.

The three question shapes, from the OpenRouter listing:

Yes/no - TypeSafe calls this shape “Noul” (yes, really). You ask a yes/no question and get a probability you can threshold. “About to churn: 0.31.”
Pick-from-a-menu - you define the options, it picks one and shows the runner-ups. “billing 0.87, refunds 0.11, technical 0.02.”
Number-on-a-scale - you define the scale, it lands on a number. “Urgency: 4 of 5.”

Everything else follows from that difference. Ask five questions about the same ticket and they run in parallel in one call, because none of them needs to wait for a paragraph to finish generating. Output tokens are free because there barely are any.

TypeSafe’s published numbers: 70 to 500 ms end to end, up to 190x faster and 440x cheaper than LLM paths on its own workflows, $0.042 per million input tokens. Those are the vendor’s numbers, from the vendor’s workflows.

Why it is cheap: there is no essay to pay for

The confusion in most threads about Jev is thinking of it as a small chatbot. It is the opposite of a chatbot, and that is where the savings come from.

A chat LLM answers a yes/no question by writing an essay you then have to parse. The round-trip looks like this: your system prompt and context go in (hundreds to thousands of tokens), the model composes prose out (the answer plus its reasoning, plus whatever hedging it felt like), and your code reads the prose back into a value. You pay for all three stages, on every message, for every tool call, forever.

A decision model deletes two of the three stages. The typed schema is the prompt - there is no system prompt to re-send, because the question already defines the answer space. There is no generated text to pay for or parse - the model returns a probability distribution over your options directly. What remains is the only part you actually needed: reading your state and committing to an answer.

One reply in a thread full of confusion landed the whole category in seven words: “hotdog, not hotdog, but for everything.” That is what TypeSafe built - the Silicon Valley app as a primitive, minus the image recognition, plus calibration. LLMs generate possibilities; decision models choose between them. When the choosing is a tenth of a cent and the generating is reserved for work that needs it, the token bill changes shape.

Jev or LLM? Eight everyday jobs, split

The fastest way to see the boundary is to walk the same product through both tools:

Job	Regular LLM	Jev / OpenJev
Support ticket arrives	Writes the reply	Picks the queue (“billing 84%”), scores urgency 1-5
Comment posted on your app	Drafts a moderation report with reasoning	Flags spam in ~300 ms, client-side, for free
Agent mid-task	Writes the code	Answers “continue, retry, or abort?” at every step
Signup form	(nothing)	Scores fraud risk before you spend anything on the account
Lead arrives	Writes a personalized outreach email	Scores fit 1-10, routes to the right rep
Long document	Reads and summarizes it	Answers “does this paragraph support the claim?” for every paragraph in one parallel batch
User asks a question	Answers it	Routes it: docs, sales, or engineer
Weekly newsletter	Writes the digest	Predicts which subject line a subscriber opens

The pattern: wherever the answer space is already known, the decision model is the little cousin that does it 100x cheaper. The LLM writes the paragraph; Jev fills in the Scantron sheet. Keep the big model for the hard thinking and writing, use the decision model for the rapid-fire judgments in between. Matt Van Horn (17,000 views in a day) compresses it: “Keep the big model for the hard thinking and writing. Use Jev for the rapid-fire decisions in between.”

*The two-tier split: the LLM handles generation-heavy moments, the decision model handles the judgment calls between them.*

An independent test

An early-access review by Henrik Lindfors (September 18, model version jev-1.13.0) put Jev through a real job: classifying 24 Norwegian public-hearing responses about a salmon tax, against DeepSeek V4.1 Flash as the reference.

	Jev	DeepSeek Flash	DeepSeek + reasoning
Stance agreement	0.86	0.89	0.88
Substance, exact level	19 of 24	14 of 24	14 of 24
Cost per 1,000 documents	$0.22	$1.31	$3.08
Median latency	0.32 s	2.7 s	26 s
Slowest request	1.3 s	17.9 s	250 s

*Cost and latency from the lindfors.no test: Jev at $0.02 and 0.32 s per run, DeepSeek V4.1 Flash at up to $0.074 and 26 s with reasoning.*

Jev read all 24 documents for half a cent. Turning reasoning on bought two extra stance labels (within noise) for ten times the latency. On the exact-level task, the small decision model beat the frontier model on the frontier model’s own labels. The reviewer’s caveats: Jev reads instructions at face value, indirection costs accuracy, and it is English-first (the test was in Norwegian, and it worked anyway).

OpenRouter, the API aggregator that carries Jev, ran its own comparison and published the numbers: tagging a batch of support tickets - cancelling, refund, angry, bug report, escalate - took Jev 2.3 seconds at a tenth of a cent, while a chat LLM needed 20 seconds on the same batch. The examples are live in OpenRouter Labs with the source code included. When the platform selling access to both models measures this gap itself, the marketing claim stops being marketing.

The open reproduction

*Accuracy ladder on the shared 102-row TypeSafe subset: the browser Qwen build reaches 0.845 against Jev’s published 0.883.*

On September 16, a day after Jev launched, TheoLeeCJ’s openjev repo asked one question: “Can we run something like Jev on a 3090 at home?” The repo’s answer, measured across pinned revisions and committed run logs, and with 1,413 stars as of September 18: the interface reproduces, the accuracy does not quite.

The native reproduction runs frozen Qwen3.5-4B, reads option logits directly in a single forward pass, and samples nothing. Same 21 binary criteria, same RTX 3090:

Output path	Time	Output tokens
Direct logit readout	1.0 s	0
JSON generation baseline	5.3 s	111

Same results, 5.21x faster. The browser build (639 MB to 3.01 GB one-time download, cached) scores 0.813 balanced accuracy on the repo’s authored judgments and 0.845 on TypeSafe’s own published 102-row subset, where Jev’s published result is 0.883. That is 96 percent of the closed service’s agreement, no waitlist, running in a browser tab.

The repo commits pinned model revisions, prompt hashes, SHA256SUMS, perturbation checks, and explicit claim boundaries. It states plainly that it copies how Jev works, not Jev’s undisclosed model or training, and the README’s demo GIF labels itself a measured replay rather than a live run.

OpenJev in the browser is the web-app use case

The browser build is not a demo trick. It is the first time a decision model runs client-side in a web page, and that unlocks jobs no API can serve:

Web-app scenario	Why OpenJev-in-browser wins
Comment widget spam gate	Classify before the POST; bad content never even uploads
Offline-first mobile app (field tools, aviation, remote work)	Decisions work on a plane; zero connectivity needed
Privacy-critical screening (health, legal, HR forms)	The text is never sent anywhere - the classifier comes to the data
Client-side form validation	Score “does this input look valid?” before the server call
Cost-free scale	No API bill at any traffic level; the visitor’s GPU does the work
No-account products	Decisions before signup; nothing to leak because nothing is stored server-side

The weights cost a one-time download (639 MB for the phone-friendly 0.6B), then every decision after that is free, instant, and private. For a web developer this is the same jump as when maps, video, and cryptography moved from server APIs to the client: the capability becomes a frontend dependency.

For the phone case specifically: the demo auto-detects small devices and selects the 0.6B model, which trades some accuracy for the smaller footprint. The ladder holds across all three browser model sizes - the interface works at every scale; only the agreement percentage moves.

Four days later: a category forms

Jev launched September 15. By day four the space had a shape nobody planned.

Laya landed on HuggingFace on day three: a 421M-parameter decision model built on ModernBERT, Apache 2.0, three checkpoints (English, 100+ languages, typed decisions), pip install laya. Its benchmark table claims 0.766 vs Jev’s published 0.727 on typed decisions, calibration three times better (ECE 0.081 vs 0.246), and roughly 33ms answers against Jev’s measured 236 to 276ms. The honest catch, which their own card states: Jev’s numbers are third-party published, not self-measured, and Laya’s context window is 512 to 1024 tokens against Jev’s tens of thousands. Laya classifies short states, not documents.

trycua shipped CUA-S1-FORMS the same week: a 2.8MB, 706K-parameter model for one job only, form filling, where it scored 99.7% against hosted Jev’s 83.6% on their eval. Too small to generalize, too good at its niche to ignore.

And a third effort promised itself: a repo and a waitlist page, benchmarks “dropping soon”. We are leaving it out until weights exist. In four days the rule already shows: the winners publish weights, the laggards publish screenshots of timelines.

	Jev (TypeSafe)	OpenJev	Laya	CUA-S1-FORMS
Weights	closed API	open, browser demo	open, Apache 2.0	open, 706K params
Context	~60k tokens	config-dependent	512 to 1024	task-scoped
Speed	236 to 276ms	5.21x faster claimed	~33ms claimed	single job
Verified	yes, independent	yes, public code	yes, files on HF	yes, repo + eval
Cost	$0.042 / 1M input	free	free self-hosted	free

The pitch is forming too. Greg Isenberg published ten Jev-native product sketches overnight and pulled 17,000 views by morning. Most are apps, but the three best are agent-architecture primitives: pruning an agent’s possible next steps before expensive reasoning starts, scoring every action by reversibility so consequential steps wait for a human, and routing only low-confidence decisions into human queues. LLMs generate possibilities, decision models choose what happens next, and the products that combine both cheaply are the ones to watch.

The direction of travel is clear. The decision layer is being commoditized from below in real time, which is exactly the pattern this site tracks for every other layer of the stack.

Where it does not apply

Jev cannot speak, explain, or reason through a novel problem. It fits answers to questions you already understand. It produces no natural language, so anything needing an explanation (code review feedback, a tutoring nudge, a written report) still needs a generative model. Its read of instructions is literal; complex qualifying language costs accuracy. And the open reproduction is measured on binary judgments. Five-level scoring of unstructured text is untested territory, which matters if you were hoping to point it at your own messy categories.

The sharpest counter-argument came from Quentin Adt: “after few layers of abstraction you end-up with a very high probability of very low confidence answer. a probability of 0.9^7 is < 0.5.” He is right about the arithmetic: seven chained 90-percent decisions compound to a 48 percent chance the whole chain held. Pipelines that compose many Jev calls inherit compounding uncertainty, and need thresholds, escalation paths, or a different shape of architecture. That is a v1 constraint on composition, not a refutation of the interface. But it is the strongest criticism the launch has produced, and anyone building with it should price it in.

Why this matters for local

The pattern repeats what made local inference viable: a closed service demonstrates the demand and the pricing, and an open implementation arrives within days that keeps most of the value on hardware you own. The closed service’s beta is gated. The open version is a browser tab. Ecosystem variants (mini-jev on an LLM, independent comparisons against Mistral and Gemini Flash-Lite) are already appearing.

Whether this becomes a second pillar of applied AI or a niche utility is the open question. Obie Fernandez, who has spent three years putting LLMs into production codebases and wrote the book on the patterns, went further than most: “I predict that all the major frontier labs will have JEV-style offerings within the next few months. I will not be surprised one bit if decision models end up being bigger than LLMs in the long run.” Tobi Lütke’s response: “Totally agreed.” Label that as a prediction, not a measurement. But when the person who wrote the patterns book and the Shopify founder say it in the same thread, the claim is worth tracking.

For the local-AI builder the practical split is now concrete: generative models where language has to be produced, decision models where a choice has to be made, and the option to run the second category entirely on your own machine. Today, not when a waitlist clears.