Skip to content
Jev in 24 Hours: What the Hype Gets Right, and What I Measured Myself
Tool Reviews

Jev in 24 Hours: What the Hype Gets Right, and What I Measured Myself

Over the last two days my X timeline has been almost nothing but Jev. A demo is not production, so I wired Jev into my own agent stack and ran a small benchmark against my existing setup.

Mike Yang
September 20, 2026
9 min read
5 views
#Jev
#TypeSafe
#AI agents
#browser automation
#benchmarks
Decorative wave
Over the last two days my X timeline has been almost nothing but Jev. One Chinese-language account that tracks English AI Twitter full time called it the densest burst of original content the account had seen in six months. Every few hours someone posted a new demo: a browser agent running a flight search in seven seconds, a Claude Code session compressed from 156k tokens to 62k, a news classifier chewing through 428 items while a general-purpose model was still on item six. I have read enough of these cycles to know that a demo is not production. So instead of reposting, I signed up, wired Jev into my own agent stack, and ran a small benchmark against the way I was already doing things. ## What Jev is, in three minutes Jev is the first model from TypeSafe AI, released on September 15, 2026. The founder is Diogo Almeida, who co-invented ChatGPT at OpenAI and spent the last two years in stealth on a training method he calls RLCD. The company raised a reported $40M seed. The name comes from the Jevons paradox: when something gets cheaper to use, people use far more of it. That is the bet. A chat model is autoregressive. Even when you ask it a yes/no question, it generates the answer one token at a time, and latency starts in seconds. Jev does not generate text at all. It takes a `state` (a string, a JSON object, or an array) and a map of typed `questions`, and returns one typed answer per question with probabilities, in a single parallel pass. TypeSafe calls this a System 1 model, borrowing Kahneman's term for fast, intuitive judgment. There are three question types: | Type | What it answers | What comes back | |---|---|---| | `noul` | Does a condition hold? | P(yes). 0.5 means yes and no are equally likely, not "medium". | | `choice` | Pick one from a defined set | The chosen option, a probability per option, and a confidence | | `score` | Where on an ordered scale | A probability-weighted score plus a per-level distribution | A few hard facts that shape what you can do with it: - Text only. Images, audio, and video have to be converted to text first. - 32k tokens of context per request on OpenRouter (64k total on the official API). - Pricing is $0.042 per million input tokens. Output is free, because there is almost none. - Measured latency in the wild runs from about 70 ms to 350 ms per call. - Question IDs are not sent to the model. Everything the model needs has to be in the instructions and criteria. The cleanest framing I saw came from Jason Zhu: LLMs explore undefined space, Jev makes decisions inside a defined space, and classical ML predicts inside a narrow, well-understood vertical. The human's job moves to deciding which questions to ask. ## What people have already built with it Two days is not long, but the pattern is clear. Every credible use case has Jev making the judgment calls and leaves thinking and writing to a bigger model. | Who | What they did | Numbers | Code | |---|---|---|---| | Gregor Žunič (Browser Use) | A tiny browser agent. Jev sees the DOM and picks the element to click as a classification problem; a small LLM steps in only for typing. | Booked a flight search in 7 s for $0.0039, at 1x speed | [browser-use/jev-ultrafast](https://github.com/browser-use/jev-ultrafast) | | vlad-terin | `jev-use`, a Codex skill. Jev takes clicks, tabs, and scrolls; Codex only thinks, types, and checks screenshots. | Reported 5–10x faster page work; Jev runs a dozen steps between check-ins | [vlad-terin/jev-use](https://github.com/vlad-terin/jev-use) | | Elia Alberti | `jev-rules`. Jev decides which of your project rules apply to each prompt, so Claude reads only what it needs. | 12 rules judged in one call, 260–860 ms, about $0.00002 | [EliaAlberti/jev-rules](https://github.com/EliaAlberti/jev-rules) | | Tamara Tran | Instant Compaction for Claude Code. Jev scores every tool call in the transcript; stale reads and noise get dropped, goals, exact errors, and key code stay verbatim. Delete only, never rewrite. | A 156k-token session compressed to 62k | [thread](https://x.com/tamarajtran/status/2100694549362553153) | | Elvis Sun | `newsjack`. Matches a live news feed against 15 brands for PR opportunities and tags intent. | 428 items in 28 s; DeepSeek V4.1-flash had finished 6 in the same window | [elvisun/newsjack](https://github.com/elvisun/newsjack) | | Li Bukai | Daily classification of People's Daily articles for a regional keyword, replacing Gemini Flash Lite. | 3 s → 0.35 s per article; 5,000 articles and 30M tokens for about $1; ~15% disagreement with the old model, mostly on person-name knowledge | [thread](https://x.com/libukai/status/2100984923926728920) | Two more categories showed up without code I could verify: model routing by task complexity, and cheap pre-approval of agent tool calls as a safety gate. Both are the same shape as the rows above. And then there is the on-chain trading bot that someone open-sourced. It ran for 14 hours and lost more than 300%. Fast is not the same as right. ## What I built first: a typed-judgment CLI I already had an OpenRouter account, and Jev was listed there on day one, so that was the path of least resistance. I wrapped the endpoint in a small TypeScript CLI that takes a request file, validates it locally before spending a call, and prints one line per answer. Then I packaged it as a skill so my coding agents can call it without me in the loop. The request looks like this: ```json { "state": { "ticket": "Help! My payouts have been failing for 3 days.", "customer_tier": "enterprise" }, "questions": { "is_bug": { "type": "noul", "instructions": "Is the customer reporting a software defect?" }, "team": { "type": "choice", "instructions": "Which team should own this ticket?", "criteria": { "payments": "Checkout, billing, invoices.", "frontend": "Rendering or layout.", "none": "None of the above." } }, "urgency": { "type": "score", "instructions": "How urgent is this ticket?", "criteria": ["Can wait for the next release", "Should be fixed this week", "Blocking revenue right now"] } } } ``` And the answer, for the English example above: ``` is_bug noul P(yes)=0.96 team choice payments conf=0.71 urgency score 1.99 "Blocking revenue right now" conf=0.99 476 input tokens · $0.00002 · 0.41 s ``` I ran the same three questions on a Traditional Chinese ticket, an invoice-header question with no urgency at all. Jev answered `is_bug` 0.02, routed it to payments with confidence 1.00, and scored urgency 0.08, "can wait for the next release". The score legend came back in Chinese, unchanged. 560 input tokens, $0.00002, 0.33 s. One sample is not a benchmark, and TypeSafe says plainly that CJK is handled but not as well as English. I would want a labeled set of a few hundred items before trusting it on Chinese in production. But the shape of the answers was right. ## The main experiment: letting Jev drive the browser My agents operate a browser through a snapshot loop. Take an accessibility snapshot of the page, hand it to the model, let the model decide what to click, click, repeat. It works. It is also painfully slow, because every turn the model re-reads a context that has grown to about 200k tokens. A four-hop navigation can take half a minute and cost half a dollar. The Browser Use demo made the alternative obvious. Clicking a link is not a writing task. It is a multiple-choice question. So I wrote a runner that does the following inside a single browser process: 1. Snapshot the full page. 2. Build a candidate list in code: clickable links, section toggles, a scroll action, and an explicit "escalate to a real LLM" option. Each candidate gets an opaque key so the model cannot cheat by reading internal references. 3. If any candidate's href already contains the success string, click it. No model call at all. 4. Otherwise, ask Jev one `choice` question over the candidates. 5. Click, then let the code decide whether the task is done by comparing the final URL or title against the success string. Jev saying "done", or reporting high confidence, never counts as success. The program checks. I ran four navigation tasks on a documentation site, three times each, and compared the runner to my existing setup, which is Claude in a headless CLI with the same browser tools and with permission prompts skipped. | Task | Runner (median) | Baseline (median) | |---|---|---| | T1: open the Docs page (href shortcut) | 1.65 s, 3/3, zero Jev calls | 17.0 s, 216k tokens, $0.44 | | T2: open Quick Start (title only, forces a Jev call) | 1.90 s, 3/3, one Jev call | 30.4 s, 274k tokens, $0.51 | | T3: find the confidence page | 0.84 s, 3/3 | 16.7 s, 178k tokens, $0.45 | | T4: two hops through a collapsed sidebar section | 2.5 s, 3/3, one Jev call | 21.9 s, 273k tokens | Twelve baseline runs cost about $5.50 (T4's baseline cost is not in the table). Twelve runner runs cost less than $0.0002. The runner was 8.8x to 20x faster, with zero tokens through the main model. The gap is structural, not a tuning artifact: the baseline pays to re-read a huge context on every hop, and the runner never builds one. ### The failure that taught me the most T4 did not pass on the first version. The target page was two hops away, behind a sidebar section that starts collapsed, and nothing on the starting page had the target string in its href. Three runs, three failures. When I looked at the logs, Jev had done the right thing every time. The candidate list contained a decoy, a link titled "How to build with TypeSafe" that sits at the top of the page and looks relevant. Jev refused it and escalated. The bug was upstream of the model, in my own observation layer, twice over: - The first version snapshotted only the viewport, so the sidebar section Jev needed to expand was never in the candidate list. - A filter I had borrowed from another project, meant to drop FAQ-style buttons, matched on "How-to" and threw away the exact toggle the task required. The fix was three lines of policy: snapshot the full page, identify section toggles by their position inside a list item rather than by guessing at their shape, and describe each toggle to Jev with its enclosing heading, as in `EXPAND section "How-to" under "COOKBOOKS"`. That last change was the one that mattered. Without the heading, Jev escalated; with it, the task passed 3/3. When a decision model is wrong, the candidate builder is the first suspect, not the model. Jev can only pick from what you show it. ### Do not read confidence as correctness Jev's confidence on T4 sat between 0.75 and 0.79 whether it was correctly expanding the right section or correctly refusing to click the decoy. The number tracks how obvious the next action is, not whether the workflow is on the right path. I had a minimum-confidence gate at 0.45; raising it to 0.8 would have rejected correct hops. Tune thresholds on real data, and pin the model version once you have tuned them. ## The case against, in fairness The loudest skeptic on Chinese X, WquGuru, made three points worth repeating. First, TypeSafe's own numbers put Jev at 67.8% on their benchmark versus 74.1% for the comparison model. The "cheaper and faster" claims are measured against frontier models, and nobody uses a frontier model for yes/no questions. Second, Qwen 3.7 Flash costs $0.03 per million input tokens, less than Jev's $0.042, and it can write the title, summary, and translation in the same call. Jev cannot write a word, so the same document has to go through a second model anyway. Third, for a fixed classification task with labeled data, a fine-tuned 4B model or even naive Bayes will beat 85% F1 for a few hundred dollars of training. All three are correct. They also miss the point that showed up in every credible demo: latency. A hundred-millisecond judgment with a probability attached opens up interaction patterns that a three-second call does not, and a general classifier you can reconfigure by editing a JSON file is a different tool from one you retrain per task. Then there are the limits I hit myself. The runner returns "needs a real LLM" rather than guessing when it sees navigation built from bare divs instead of list items, virtualized lists that only render what is on screen, forms, logins, CAPTCHAs, native dialogs, or any goal that requires remembering earlier pages. Someone else raised the question about shadow DOM and rapidly re-rendering SPAs; nobody has published a test. And as one commenter noted, after a dozen clicks the page has changed under Jev and a bigger model has to come back and look. ## Where Jev belongs After a day with it, my rule is: Jev owns the judgment layer, the big model owns thinking and generation, and code owns the workflow between them. High-confidence decisions go through. Low-confidence ones bounce to a person or a reasoning model. ![Where Jev belongs: code owns the workflow, Jev owns judgment, the LLM owns thinking and writing. High-confidence decisions pass; low-confidence ones escalate.](https://bpnycnjporbaoxnwntmi.supabase.co/storage/v1/object/public/blog-images/2026/09/jev-in-24-hours/fig-1-judgment-layer.jpg) Three questions decide whether a task belongs in that judgment layer: 1. Does a sub-second answer change the product, or just shave cost? If it only shaves cost, a fine-tuned small model may win. 2. Can the system tolerate roughly 15% disagreement with a bigger model, either because a human reviews or because code has a fallback? If not, this is not a Jev task yet. 3. Can code enumerate the options in advance? Jev picks from a list. It cannot pick what you did not list. If all three are yes, run a same-task comparison on your own data, measuring accuracy, latency, and cost. Then decide. Do not decide from a demo, including mine. ## Getting started - Request access at [typesafe.ai](https://typesafe.ai). Most people reported approval within a day; a few did not get in. - Or skip the waitlist: Jev is live on [OpenRouter](https://openrouter.ai/~typesafe/jev-latest) and [Vercel AI Gateway](https://vercel.com/ai-gateway/models/jev). - Official docs at [docs.typesafe.ai](https://docs.typesafe.ai). Append `.md` to any page path to get Markdown, which is handy when you want an agent to read them. - Official agent skill: `npx skills add typesafe-ai/skills --skill typesafe-ai`, then say "use the TypeSafe skill" in your prompt. - Community code mentioned above: [browser-use/jev-ultrafast](https://github.com/browser-use/jev-ultrafast), [vlad-terin/jev-use](https://github.com/vlad-terin/jev-use), [EliaAlberti/jev-rules](https://github.com/EliaAlberti/jev-rules), [elvisun/newsjack](https://github.com/elvisun/newsjack). If you build something with it, I would like to hear what broke first. In my case it was not the model.

#Tags

#Jev
#TypeSafe
#AI agents
#browser automation
#benchmarks

Did this post help?

Your support keeps us writing.

You might also like

More from the lab.

Haiku 5.5 as a Subagent: Faster Where the Work Is Simple, No Faster Where It Isn't
Tool Reviews

Haiku 5.5 as a Subagent: Faster Where the Work Is Simple, No Faster Where It Isn't

I swapped Haiku 5.5 into two places in my Claude Code stack. As the file-search subagent it was a third faster at 1/39 the cost. As eight parallel research subagents it made the whole job no faster and 51% dearer. The lever is the integrator, not the subagent.

M
Mike Yang
10/8/2026
GPT-6 Luna in a Real Back Office: A Careful Writer, a Hesitant Tool User
Tool Reviews

GPT-6 Luna in a Real Back Office: A Careful Writer, a Hesitant Tool User

We ran the cheapest GPT-6 tier against Gemini 3.5 Flash-Lite on the daily AI work of a small B2B business. Luna wrote the best drafts and invented nothing. It still does not get every job.

M
Mike Yang
9/28/2026

Keep up with what we ship

Subscribe for new experiments, tooling notes, and what we learned building them.

We respect your privacy. No spam, ever.