We Classified 1,852 Articles With Jev for $0.12. First-Pass Triage Just Got Too Cheap to Ration

Hello, this is Ryuta Hamamoto from TIMEWELL.

Last week I had an AI read all 1,852 articles on our site, one at a time, and answer two questions about each: is this about export control, and which of our services fits the person reading it. It took 49 seconds. By the published price list, it cost about $0.12. That is the kind of cleanup we had been putting off for years with the same excuse every time: we would need a person to sit down and read everything, and nobody has that week to spare.

The model was Jev, announced by TypeSafe AI on September 15, 2026 (US time)¹². The launch coverage led with "an AI that writes no text" and "40 to 200 times faster," and that is how I read it at first too. Running it myself changed my mind. The speed is not the point. The point is that first-pass triage now costs so little that it stops being a decision.

The short version:

• Jev writes nothing. It returns a choice, a score, or a true-or-false probability. Output is free precisely because there is no writing step
• Our 1,852 articles: 49 seconds, about $0.12, roughly $0.00007 each (estimated from the price list)
• When cost disappears, two assumptions go with it: that you sample, and that you do the cleanup once
• In Japanese, a binary question hit 96.4% precision. A nine-way choice agreed with our labels only 36% of the time. Thresholds have to be measured on your own data
• No images, no audio. It is also bad at arithmetic and counting

Throughout, numbers that developers reported under their own conditions are marked as such. Our figures are from our own run, though the cost is estimated from the price list rather than read off an invoice.

First-pass triage changed by two orders of magnitude

Say a support message arrives. A chat model will write you something courteous: "This looks like a billing question, let me route you to the right team." But the program underneath does not want that sentence. It wants the routing decision and a number saying how sure the model is. Prose has to be parsed back into something a branch can use. Jev removes that step by never producing the prose.

You send a block of text and the questions you want answered. There are only three kinds. A Choice picks one option from a list. A Score places the input on a scale you define. A Noul returns the probability that a statement is true, from 0 to 1. Choice and Score come back with per-option probabilities and a confidence value. You can mix dozens of questions into a single call³, and because they are evaluated in parallel, adding questions barely moves the latency.

TypeSafe calls this a System One model, after Kahneman's fast, intuitive System 1. The documentation is blunt about the boundary: these models "do not write replies, produce code, or generate explanations of their reasoning"⁴. Founder Diogo Almeida worked on the research behind ChatGPT at OpenAI and says he spent two years building this with a training method called RLCD², which aims to make the returned probabilities line up with how often the model is actually right¹.

All of that is mechanism. Here is the part that matters commercially. Because it never writes, you are not billed for output. Input runs $0.042 per million tokens, output is free⁵. The cost of first-pass triage now depends on almost nothing but how much text you send.

What it actually cost

The first two rows are ours. The rest are the vendor's and developers' own figures.

Work	Volume	Cost	Time
Classifying our articles (ours, 3 questions each)	1,852	$0.12	49 s
Deciding article CTAs (ours, 5 questions each)	1,852	$0.10	~2 min
Pull-request checks (reported)	1,000	$0.07	~0.5 s each
Reranking case law (official cookbook)	1,200 calls	$0.0645	not stated

For our two runs we sent about 2,000 characters per article and asked three to five questions at once. That works out to roughly $0.00007 an article. Ten thousand articles would not reach a dollar.

For comparison, Paolo Rosson, who built the pull-request checker, posted that his version runs "7 cents for 1,000, versus about $14.50 on a large model"⁶. That is his own comparison and not an independent benchmark, but the rough two-orders-of-magnitude gap matches what we measured.

At this price, you stop deciding whether a job is worth doing. That was the strongest impression from the whole exercise. Reviewing 1,852 articles by hand is 31 hours at a minute each. Outsourced, it is real money. So it sat on the list for years. At twenty cents, you just run it the moment you think of it.

When the cost disappears, the design changes

Cheaper does not simply mean faster. Three assumptions stop holding.

You can stop sampling. Analysis used to start with "we can't look at everything, so pull a hundred and find the pattern." If the full set runs at a realistic price, there is no reason to pull a hundred. In our own cleanup, a 40-article sample showed 30% agreement and I nearly concluded the model was useless. Across all 1,852, the disagreements turned out to be concentrated in specific categories, which told us the problem was in our taxonomy rather than the model. The sample could not show that.

You can stop doing it once. Add an article and rerun the whole corpus for twenty cents. Change your mind about the question and rewrite it and run again. A stale spreadsheet nobody remembers building becomes an output you regenerate.

You can stop narrowing before you ask. Questions run in parallel, so adding them barely costs latency. There is no need to stage it as "check urgency first, then ask more only for the urgent ones." Ask everything at once and combine the answers in code. The official guidance says the same thing from the other direction: "Code handles deterministic work and owns the control flow. The model appears only where the system needs programmable common sense or needs to interpret unstructured data," and ask "the most explicit, narrow, specific, atomic questions you can"⁷.

20 places it replaced a first pass

These come from implementations published in the days after launch, plus the official cookbooks. They run from "work people used to sort by reading" through "drop it before the expensive model sees it," then screen automation, then experiments where latency is the whole point. I looked at the game and self-driving demos too and left out the ones that do not translate into a business decision.

Work people used to sort by reading

01. Fourteen checks on a code change. Paolo Rosson pastes a pull-request diff into a single call and gets back fourteen checks as probabilities: leaked secrets, SQL injection, deleted tests. He reports $0.00007 per pull request and half a second. This is not a claim that the review matches a human. As a first pass before a person looks, the numbers are realistic⁶.

02. Scoring a post against 61 questions. Rob Hallam, who runs SuperX, throws 61 questions at a draft post at once to score how likely it is to spread. He reports all 61 answers in about a second at $0.0004 per post, tuned on 9,481 posts from 207 creators, picking the more viral of two posts two times out of three⁸. It is the most direct use of "questions are free" I have seen.

03. Sorting live comments into questions, reactions and requests. Japanese developer kogiso built a demo that routes streaming comments into four buckets. Push only the questions to the host's screen, tally the requests afterwards. He notes it suits "small decisions inside an app or workflow"⁹.

04. Filtering a database by what the text means. Zachi added a function to PostgreSQL that takes a condition written in English. Write WHERE jev(people, 'could work from home') and each row gets judged. No index, no embeddings. He reports 129 rows in about a second for $0.0009. The model is not writing SQL. It is answering inside the SQL, row by row¹⁰.

05. Type a column header, get the rows classified. nader dabit's predictive spreadsheet takes a header like "Urgency" and grades every row by reading it. He reports about 100 ms per row. A spreadsheet that recalculates meaning rather than numbers. One caveat: what counts as urgent differs by team, so the real work is agreeing on the definitions before you hand it over¹¹.

06. Choosing which bot and which model gets the job. Milind S built a chief-of-staff layer that reads an incoming task, decides which idle bot to wake, and which model to give it. Nobody has to remember not to spend a frontier model on a trivial job. Model routing is one of the vendor's own headline use cases¹²¹³.

07. Finding "that PDF from earlier." The same dabit built a launcher where you can type "the PDF I downloaded earlier" without remembering the filename. Conventional launchers rank by aliases, substrings and frequency; here the intent gets read on every keystroke, and he reports the list reordering in about 100 ms¹⁴.

08. Pulling up the slide that matches what you just said. Rinte's demo picks the slide that fits the speaker's current sentence. It does not author anything; it chooses among pages you already made. In a follow-up he explains that the conversational turn-taking runs on a separate speech model and only the judgment was split out, because doing the judging inside the conversational model made it slow¹⁵.

Drop it before the expensive model sees it

09. Decide what to keep before you summarize. tamara's "instant compaction" opens with a good line: why, in 2026, is context compaction still a summarization prompt? Instead, every tool call in the session gets scored and the irrelevant ones are dropped, which makes compaction instant¹⁶. Summarizing is writing, so it is slow, and important details fall out. Decide what to keep first and there is less to write. This is the most portable idea in the article.

10. Choosing which logs reach a coding assistant. The Chinese-language account 梭哈.AI published an explainer on the approach above. When you are deep in a long coding session, the assistant stalls for seconds at a time to build a summary each time the context fills. Scoring the accumulated logs and throwing the useless ones away avoids the stall¹⁷. A Chinese walkthrough appearing two days after launch says something about how fast this spread.

11. Reordering what retrieval found. The official cookbook works through 3,565 legal passages. Fast full-text search pulls the top 30, then each candidate gets a true-or-false question — is this the cited case? — and the list is reordered by the returned probability. Across 40 queries, top-1 accuracy went from 5% to 18% and top-10 from 38% to 62%, using 1,200 calls for $0.0645. The vendor states the limit plainly: "It cannot add a passage that fast search did not select"¹⁸. You still need the net.

12. Adding it to notes search. Ian Nuttall wired it into search in the notes app keep.md and reports reranking "7x faster than the current approach," with tagging "50x faster than a separate small model and no failures"¹⁹. There is also jev-search, a small tool that bolts optional reranking onto Obsidian notes. If you noticed that cases 04, 09 and 11 are the same shape, you have the point of this article. Line up candidates, ask about each one, keep what clears the threshold.

Screens and the physical world

13. Getting through a flight search in about seven seconds. Gregor Zunic, founder of the browser agent Browser Use, searched Google Flights from Zurich to London. He posted seven seconds at $0.0039. Buttons and inputs on the page get turned into a numbered list, and the model picks which action goes on which element. A small language model handles the cases that need actual typing, like a city name. The demo stops at results, not at a purchase²⁰.

14. Turning the screen into text, then picking where to click. Milind S's setup never sends a screenshot anywhere. A small local vision model crops the on-screen elements, on-device OCR reads their labels, and only those strings go out. Probabilities per element come back, the highest gets clicked, and detection runs again. He reports about 90 ms per decision²¹. For a model that cannot see, this is the cleanest way I have found to show it a screen.

15. Talking to your browser. Moritz Kremb connected voice instructions to browser actions. You speak, the transcript goes out, a probability per target comes back, the browser clicks. He reports about 300 ms for the judgment and $0.0002 per action. That is not the end-to-end time from speech to pixels²².

16. Putting the judgment inside a Chrome extension. RaZaan shipped an extension where the agent reads the page and decides the next click. Living in the browser makes it a natural fit for internal approval screens and repetitive SaaS chores²³.

17. Driving an iOS simulator. iOS developer camsoft2000 wired it into his own simulator-control tool and had it perform tasks like adding a reminder. The tool extracts the accessibility tree, condenses it, the model picks the next action, the tool executes it and asks again whether to continue or stop. This does not solve device permissions or real-hardware conditions, and he says the integration is still unpublished²⁴.

When latency is the whole point

18. Doom, one short decision at a time. This is TypeSafe's own launch demo. Game state goes out as structured text and the next action comes back. The official post says roughly ten calls per second at about $7 an hour, notes that the input is structured data rather than images, and adds that "a conventional Doom bot can play better"¹. I liked that they put the caveat on their own marketing demo.

19. Splitting reflex from planning. Wuyang Zhou paired Jev with OpenAI's GPT-6 Astra to play Minecraft. In his description, Jev reacts instantly to events like a zombie attack, while Astra plans ahead toward larger goals²⁵. Same structure as case 08, and in a business setting it reads as "first response on the fast model, complicated calls on the large one."

20. Turning a trade decision into an order. Jarrod Watts's jev-trader reads price data for a pair, answers buy or sell, and places an order on an exchange where blocks are produced roughly every 300 ms, so the decision and the order fit inside that window. The repository ships with a dry-run setting that places no real orders without a private key, and a stub model that is the default. It is not evidence that the strategy makes money²⁶.

Cheap is not the same as safe to be sloppy with

Having spent the article on cost, here is the other side. Our 1,852 articles were also an accuracy measurement, using the category already in each article's front matter as ground truth.

Asked as a binary — is this article about export control, economic security or sanctions — the model hit 96.4% precision and 87.9% recall at a 0.20 threshold. Out of 1,547 articles that were not on that topic, it wrongly flagged ten. For Japanese, that is comfortably good enough for a first pass.

Asked to pick one of nine categories, it agreed with us 36% of the time. That gap is the finding. Chasing it down, the fault was mostly ours: one category had become a catch-all holding 892 articles. Lining up binary questions beats reaching for a multi-way choice, both for accuracy and for being able to explain the result. I read this as field confirmation of the vendor's own advice to keep questions narrow, specific and atomic.

Thresholds deserve the same care. At the default 0.5, recall dropped to 75%. Dropping to 0.2 still produced only ten false positives out of 1,547. The misses have a shape, too: adjacent topics like security clearance and anti-espionage law clustered between 0.40 and 0.49. Whether you want the adjacent material is a decision you get to make, but only if you measure.

The vendor does not hide the weak spots either: literal interpretation, poor arithmetic and counting, unreliable date comparison, and degraded accuracy when irrelevant material is added²⁷. And returning a well-formed answer is not the same as returning a correct one. The site says the model does not hallucinate, which means it will not emit a value outside the schema; both Hacker News and The Register have pointed out that a valid-but-wrong value is still possible²⁸. That is what the probabilities are for. The official guidance is a three-band operating rule: act automatically on high confidence, proceed carefully on medium, and on low "do not act — route to a human, request clarification, or fall back to a different system"²⁹.

One more note on cost. Only the judgment is cheap. Turning screens into text, speech recognition, OCR, the retrieval net itself — those are separate line items. Since images cannot go in directly, anything visual needs a stage in front of it⁴. Look at the total.

If you are wiring this into RAG, the cookbooks are specific. One pattern puts a classification step between retrieval and generation and asks four things of each passage: does it address the subject, does it carry information usable in an answer, does it contradict the premise, and is it trying to manipulate the answering system. That last one is prompt-injection detection, and anything over the threshold is dropped before generation sees it³⁰. Even there the vendor notes that "nothing here is a security boundary." Our own enterprise AI, ZEROCK, is built on GraphRAG, and the lesson from that work is that retrieval quality usually comes down to what you pass and what you drop rather than which algorithm you picked. A judgment layer fits that naturally. The fundamentals are in seven practical techniques for improving RAG accuracy.

Three things to take away if you don't write code

One: list the work you dropped because it cost too much. The full inventory. Reclassifying every inquiry. Pulling the action items out of every meeting note. They are all sitting on someone's someday list because there is no headcount for them. At twenty cents a run, the premise changes. Write down three first-pass jobs your team gave up on for cost reasons. That inventory matters more than the tool choice.

Two: hand over binary questions, not "figure it out." Our own numbers are the argument: 36% for a nine-way choice, 96% for a binary. Instead of asking "how urgent is this," ask whether the customer is asking for a human, whether they have written in before, and whether they mention an amount, then combine the answers in code. That decomposition is a job for someone who knows the work. It cannot be handed to an engineer.

Three: pick the threshold and the stop condition first. Where to cut is something you measure, and leaving the default in place will quietly lose things. The three-band rule exists because a tool that automates judgment needs its stopping line drawn in advance²⁹. Being cheap is not permission to be careless. If anything, cheap means you can afford to re-measure more often.

One last thought. Read as a benchmark story, this launch looks small. No prose, no vision, no arithmetic. But in a year where the price of the same capability keeps falling, shipping a component that returns nothing but a cheap decision is not a small thing. As I argued in the two curves of autonomy and cost, the advantage in AI is shifting from which model you pick to how you run it, what you log, and who can stop it. If you want help mapping where the decision points in your operation are, and how far to hand them over before a person takes back control, talk to us about WARP.

References

Footnotes

1. Introducing System One Models and Jev (TypeSafe AI, Diogo Almeida). The System One definition, 70–500 ms latency, the 40–200x claim, $0.042/MTok input with free output, RLCD, and the Doom demo (about ten calls per second, roughly $7/hour, structured data rather than images as input, and the note that a conventional bot can play better) all come from this post. The page shows September 18, 2026, apparently the updated date; the announcement date is in note 2 ↩ ↩² ↩³

2. Diogo Almeida's announcement post (September 15, 2026, US time) and the TypeSafe AI account's post the same day. The claim about co-inventing ChatGPT and spending two years in stealth on RLCD and Jev is from the former. Press coverage: The Register, September 16, 2026 ↩ ↩²

3. Introduction (TypeSafe AI Docs). The three primitives, the return values, mixing question types in one call, and "No text generation, no parsing." ↩

4. System One (TypeSafe AI Docs). "System One models do not write replies, produce code, or generate explanations of their reasoning." and "Jev currently accepts text input only. It evaluates strings, JSON objects, and arrays of text. Images, audio, and video are not supported (yet)." ↩ ↩²

5. Models (TypeSafe AI Docs, retrieved September 19, 2026). Current model jev-1.13.0, $42 per billion input tokens ($0.042 per million) with free output, 64k context, text only, "English is the primary training language and where accuracy is currently best," and other languages "handled but not equally well; test on your own content before relying on Jev for a non-English workload" ↩

6. Paolo Rosson's post (September 17). The $0.00007 per pull request, the half-second latency and the "7 cents for 1,000 versus about $14.50" comparison are all his own reported figures ↩ ↩²

7. How to build with TypeSafe (TypeSafe AI Docs). "Code handles deterministic work and owns the control flow. The model appears only where the system needs programmable common sense or needs to interpret unstructured data." and "Ask the most explicit, narrow, specific, atomic questions you can." ↩

8. Rob Hallam's post (September 18) and a second post the same day ↩

9. kogiso's post (September 18) ↩

10. Zachi's post (September 18) and the repository ↩

11. nader dabit's post (September 18) ↩

12. Example use cases (TypeSafe AI Docs). "Replace or supplement embeddings in RAG pipelines with semantic search, scoring, and ranking" and "Use Jev to build a custom router that chooses which LLM receives each prompt" ↩

13. Milind S's post (September 17) ↩

14. nader dabit's post (September 18) and the experiments repository ↩

15. Rinte's post (September 18) ↩

16. tamara's post (September 18) and the repository ↩

17. 梭哈.AI's post (September 18) ↩

18. Re-ranking (TypeSafe AI Cookbooks). CLERC, 3,565 passages, 40 queries, BM25 top-30 reordered with Noul, top-1 5%→18%, top-10 38%→62%, 1,200 calls for $0.0645, and "It cannot add a passage that fast search did not select." ↩

19. Ian Nuttall's post (September 18). The 7x and 50x figures are his own, under his own conditions ↩

20. Gregor Zunic's post (September 17) and the public repository, which records 7.1 seconds including page load and typing ↩

21. Milind S's post (September 18) ↩

22. Moritz Kremb's post (September 17) and the repository ↩

23. RaZaan's post (September 18) and the public page ↩

24. camsoft2000's post (September 18) and the AXe repository ↩

25. Wuyang Zhou's post (September 18) ↩

26. Jarrod Watts's post (September 17) and the repository ↩

27. Jev 1.13 jaggedness (TypeSafe AI Docs). Literal interpretation, weakness at arithmetic, counting and date comparison, degradation with irrelevant context, and "jev-1.13 is not trained to generate text." ↩

28. Introducing System One Models and Jev (Hacker News, September 2026). 1,890 points and 495 comments as of September 19, 2026; the valid-but-wrong point and Almeida's replies are in that thread. The Register (September 16, 2026) raises the same caveat ↩

29. Confidence (TypeSafe AI Docs). Confidence as a 0–1 value derived from the probability distribution, absent for Noul; high means act, medium means proceed carefully, low means "Do not act. Route to a human, request clarification, or fall back to a different system." ↩ ↩²

30. Classifying RAG passages (TypeSafe AI Cookbooks). The four questions, thresholds held as constants in one place, and "Nothing here is a security boundary." ↩