"Models have been superhuman at chat for years, so where is all the automation?" That is how Diogo Almeida opens the launch post for TypeSafe AI, the San Francisco lab he co-founded after helping build the methods behind ChatGPT at OpenAI. His answer, released on 15 September after two years in stealth and with $40 million in seed funding led by DCVC, is a model that cannot write a sentence.
State in, typed answers out
Jev takes text in and gives no text back. You send it a block of state (a string, a JSON object, an agent trace) and a set of typed questions. It returns typed answers with probabilities, all of them in a single parallel pass, in 70 to 500 milliseconds by TypeSafe's account. The price is $0.042 per million input tokens, and output is free, because there is hardly any.
There are three question types. A Choice picks one option from a defined set, a Score rates the input against described levels, and a Noul returns the probability that the answer to a yes/no question is yes. That is the whole interface. TypeSafe names the category System One, after Kahneman, and pitches it for the places where rules written by hand break too easily: routing a ticket, say, or deciding which branch a workflow takes.
The demo that made the headlines is Doom. Jev plays from a structured description of game state at ten queries a second, for roughly $7 an hour, and TypeSafe concedes a conventional bot would play better. I take one thing from it. A model of this class can now sit inside a game loop.
Every model does better inside a workflow
I think the launch post buries its best result. It is on the evals site, and it applies to every model on the chart. TypeSafe took four business tasks (security alert triage, agent trace review, invoice processing, customer service) and ran each model two ways. In one, the model gets the whole policy as a prompt and reasons its way to an action. In the other, the policy is decomposed into a workflow: narrow typed questions go to the model, and code does the rest. Averaged over the four tasks, every model is more accurate, cheaper and faster in the workflow. The gain runs from about five points at the low end to more than 35 for the smallest model, which collapses to 18 per cent when handed the policy as prose. On individual tasks the accuracy ordering reverses twice, both times for a DeepSeek model, and in three cases the workflow is slower than the prompt.
This is a harness engineering result published by a model vendor. The accuracy comes from moving control flow out of the model and into code, and it shows up for every vendor's model, including the ones TypeSafe wants to displace. Read that way, Jev follows from the harness. Code should own the arithmetic and the date comparisons (TypeSafe's own list of known failure modes says to keep both there), along with the branching. Once it does, the model's remaining job is to answer closed questions about a state it does not own. A model in that position has no use for strings. It has no use for memory either, since the program holds all the state between calls. Generation, the thing that makes an LLM slow and expensive, was doing no work in that slot, and TypeSafe deleted it.
A browser agent where the harness is the slow part
Within two days of the launch, Gregor Zunic of Browser Use published a small open-source browser agent built exactly this way. At each step the harness reads the page into a numbered table of visible controls. Jev gets that table and answers several questions in one request: which operation to perform (click, type, select, scroll, wait, done, blocked), and which element to target for each operation that might apply. The target questions are speculative, and the harness uses only the one that matches the chosen operation. When the operation is typing, a small LLM is called to write the string.
Generation is still in the system, in the two places the task needed it. In the recorded Google Flights run, 17 requests went to Jev and only two to the text model, for the two city names. The run found one-way flights from Zürich to London in 7.07 seconds, timed from the first prediction to the accepted completion. The wait for Google's results is inside that window and the initial page load is outside it. Jev's median latency was 178 milliseconds, which would put the model's share at roughly three of those seven seconds if the requests ran one after another. Zunic's post puts the cost at $0.0039. That matches the 90,558 input tokens in the log at TypeSafe's list price, though the performance notes point out that the API returns token counts and no billed amount, and that browser costs are excluded.
The same notes support the harness argument with a measurement. Browser Use ran the task against a frozen earlier version of its own loop, with identical models and settings in both arms. Median time fell from 9.45 to 7.09 seconds, and median browser protocol calls fell from 1,092 to 101. All of that came from harness changes. The new loop reads the DOM in one browser call where the old one read the accessibility tree repeatedly, and it no longer throws a decision away every time an animation touches the page. Once the model answers in 178 milliseconds, the slow part is the harness again. The evidence is thin, and the authors say so: three matched pairs, one task, one Chrome profile, a sign test at p = 0.25, and their own statement that this is not a broad benchmark.
Compaction that can only delete
A second project from the same week puts Jev in a different slot. fast-jev-compaction replaces the step agents run when their context fills up. The usual approach asks an LLM to summarise old turns, and a summary can lose the file path or the constraint that turns out to matter later. This library never rewrites anything. It shows Jev the whole conversation, abridged to fit and with tool results reduced to short notes, and asks two yes/no questions about each old tool call: does the call still matter, and must its result stay verbatim. Whatever scores under a 0.5 probability is cut: either the result is trimmed to a short head, or the call and its result go together. User and assistant text stays word for word, the first message and the newest few are pinned, and if Jev fails or removes too little, the Claude Code plugin falls back to the built-in summary.
Here Jev's inability to write is what makes the design safe. A compactor that can only delete cannot put an invented sentence into the agent's memory, so this is one place where the "cannot hallucinate" claim has teeth. The author also picked a slot where a wrong valid value is cheap. If a tool result is dropped by mistake, the agent runs the tool again. The README says as much, and adds that a probability is no proof a result is safe to delete. It reports no measurements, so for now this is a good design waiting for one.
A judge that still needs a second reader
A third early user put Jev to work as a judge. Good Start Labs, which had early access, regraded 6,003 rubric checks on 1,203 financial-research answers with Jev and five LLM judges under the same instructions. Jev matched each LLM's verdict between 86 and 92 per cent of the time. The LLMs matched each other between 88 and 95, with the three frontier models at the top, and the authors call the difference a real gap. Like TypeSafe's chart, this measures agreement, and the write-up says plainly that agreement is not accuracy. Two methodology details deserve a note. Jev's verdicts date from July while the LLMs ran in September, and a check passes at a probability of 0.70, a threshold the write-up does not validate against labelled outcomes.
Their plan for Jev is the recoverable kind of slot: a cheap second reader on every check, with disagreements sent to a person. That works only if Jev fails differently from the LLM judges, which is untested. The plan also carries a larger risk, because Good Start builds training environments. Once a judge's verdict feeds a reward, the model being trained becomes someone who wants a particular answer and is writing the state Jev reads.
What the vendor's numbers measure
How good Jev is in these slots is harder to say, because every accuracy number that follows is a vendor self-report. The four workflows were written by people on TypeSafe's own capabilities team, a bias the company flags itself.
On the averaged chart Jev scores 67.8 per cent, level with OpenAI's and Anthropic's mid-tier models and five to six points behind the best ones. The reference labels, though, are the averaged answers of the two largest frontier models, both at high reasoning effort, while everything else runs at default settings. So accuracy here means agreement with two LLMs. TypeSafe's stated reason is to avoid debating the labels, and it notes that the choice tilts the table towards OpenAI and Anthropic. Nothing on the chart, Jev included, has been measured against what was correct.
The average hides a spread as well. Jev reaches 76 per cent on customer service, a little over two points behind the leader. On invoice processing it manages about 62, where the best LLM reaches 79 and every model but the smallest beats it. Invoices involve amounts, dates and cross-references between documents, which is the territory the failure-mode list warns about. If I were evaluating Jev for finance operations I would start from the invoice number and ignore the average.
TypeSafe's home page claims 193.6 times faster and 444.6 times cheaper, and the launch post expects these to sit at the higher end of real-world gains. They appear to be drawn against the expensive end of the chart. The cheapest comparable LLM on the same chart lands one point below Jev at about eight times the cost per case. Eight times cheaper is a good discount and nothing more. Good Start's table repeats the pattern with a third party's numbers. Jev comes to $160 per million graded answers against $33,000 for the most expensive judge. But the cheapest LLM judge costs $260 and agrees with the frontier judges more often than Jev does. What that model cannot do is answer in under a second: it takes 12.9 seconds per case against Jev's 0.4. One caveat cuts the other way. The LLMs ran through TypeSafe's adapter, which constrains them to structured decisions with probabilities and which TypeSafe says tends to be slower and costlier than asking for a bare decision. I would still expect most of the latency gap to survive a fairer setup. Latency is what Jev has that the others lack.
Type safety removes the loud errors and keeps the quiet ones
TypeSafe also says Jev cannot hallucinate. By construction that is true: the output space is the schema, so an out-of-schema answer is impossible. A guarantee that holds by definition says nothing about quality, though, and TypeSafe notes itself that the zero per cent on its hallucination chart is not an empirical number. The Register raised the objection within hours of the launch: a typed answer with a probability attached can still be the wrong answer.
Type safety changes which errors you can see. A malformed tool call from an LLM fails loudly, at the parser, where a retry or an alert can catch it. A wrong valid value passes every check the type system can make. Jev removes the loud error class and leaves the quiet one, so everything rests on the probabilities attached to each answer.
Good Start measured the loud class. Its most expensive LLM judge returned an unusable first attempt on 67 of 1,203 answers, while Jev completed 10,500 grading calls in a separate run without a failed one. The authors add that this says nothing about whether the verdicts were right. Browser Use reached the same conclusion within two days of building on Jev. Its notes say "A valid operation can still be wrong", and they treat Jev's DONE as a claim to check. Each of the measured runs was verified by an independent checker outside the loop.
The launch does not show that those probabilities are any good. The docs say calibration is measured across groups of predictions and guarantees nothing about any single answer. The confidence field is a statistic computed from the shape of the output distribution, and Noul answers do not carry one. In the launch post, the evals overview and the docs pages I read, I found no reliability curve and no calibration error figure. The training method is named for calibration, but the launch material measures only agreement.
Guardrails are the wrong first job
The guardrail use case worries me most. TypeSafe pitches Jev for scoring and verifying LLM traffic, jailbreak detection included. Its own failure-mode page says the model does not treat state as hostile by default, and that an instruction planted in the state, or text that makes the case for its own label, can shift the answer. A guardrail's state is adversarial by definition. The browser agent shows both halves of the problem. Its README stresses that model output never becomes a selector, a coordinate or a line of JavaScript, and that every executed target is resolved from a node the harness observed itself. So a hostile page cannot push the agent outside that table. It can still argue for the wrong button inside it. The decision layer inherits the injection problem, and all it leaves behind to audit is a set of probabilities.
Where I would use it
I would still try Jev, and these three projects show where. All of them put it in a slot where a wrong answer is recoverable. The browser agent checks the outcome outside the loop, the compactor deletes only what the agent can fetch again, and the judge sends its disagreements to a person. The first two keep an LLM nearby for the part that needs words. A guardrail has neither property, because a missed jailbreak is not something you get to retry. Wherever you put it, I would not take the vendor's numbers in place of my own. Before swapping an LLM call for Jev, measure three things on your data:
- Calibration on your distribution: bucket the stated probabilities and check them against outcomes you have labelled, and pin the model version, because the alias moves.
- Accuracy per workflow, against labels a person has checked.
- Behaviour when the state is written by someone who wants a particular answer.
The name is a bet on Jevons Paradox: each tenfold drop in the cost of intelligence should open up far more than ten times the uses. That is probably right, which is what bothers me. Software will make far more of these decisions, and none of them will be parsed or validated, because there is nothing left to validate. When an LLM returned a malformed answer, something crashed and someone noticed. When Jev returns the wrong valid value, it ships.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.