The most interesting AI model of the year can’t write a sentence

The most interesting AI model of the year cannot write a sentence, and that is the point. Jev is a model you call, not one you talk to, and that changes what software can afford to ask. Jev’s speed and price survived two launch-day tests and an afternoon of ours. The vendor’s accuracy figures are agreement with two chat models, and the probabilities Jev returns are the claim to test, so we tested it.

TypeSafe AI came out of stealth on September 15, 2026 with a $40M seed led by DCVC. The CEO is Diogo Almeida, a primary author of OpenAI’s InstructGPT paper. Access is by early-access waitlist, and the launch names no customers. TypeSafe’s launch release, the InstructGPT paper.

Market note reviewed September 17, 2026. We ran Jev for one afternoon on public-domain text through the early-access API; those measurements are ours and are dated. The benchmark figures are TypeSafe’s own published evaluation and two launch-day third-party tests. The worked economics are illustrative.

Notice what Jev refuses to do

TypeSafe calls Jev a System One model, after the fast, intuitive half of Kahneman’s pair, and describes it as “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.” Hand Jev a document, a ticket or a transcript and a set of questions, and Jev returns an answer to each with a probability attached. Noul is yes or no as a float from 0 to 1. Choice is one option from up to 255, with a probability on every option. Score is a position on ordered levels. Ask several at once; they run in parallel inside one call of about 32,000 tokens. Introducing Jev, Jev API reference.

What Jev refuses to do is the point. “System One models do not write replies, produce code, or generate explanations of their reasoning.” There is no prose to parse, no JSON to repair, and no category invented outside the list you supplied. The FAQ says Jev “is neither small nor an LLM,” and is candid about the limit: “Jev guarantees the shape of its answers, not that every decision is correct.” Read the 0% hallucination figure in TypeSafe’s plots as a statement about shape; the blog says the number “is not empirical.” TypeSafe commits not to train on customer inputs; the weights are closed. Introducing Jev.

Count what becomes affordable at 0.4 seconds

The name is a nod to Jevons paradox: make a resource cheap enough and consumption of it explodes. The resource here is judgment. On TypeSafe’s own workflow evaluation, Jev costs $0.0004 per case and answers in 0.4 seconds; Claude Opus 5 costs $0.1761 and takes 37.8 seconds. Input is $0.042 per million tokens, and output is “FREE (too cheap to meter)” because there is no autoregressive decoding to meter. TypeSafe workflow evals.

That ratio is the vendor’s best case, and TypeSafe says so. What the price buys is a different kind of question. Every’s head of evals put 37 documents through 21 questions and received 777 judgments in under 0.7 seconds. Good Start Labs ran 10,500 calls with “zero failed gradings.” At that speed a decision can sit inside a request, inside a loop, or in front of every output a language model produces. Classifying, routing, scoring, ranking and verifying stop being pipeline stages and become expressions in code. Every’s launch-day test, Good Start Labs.

Read a novel in four seconds

We spent an afternoon with the early-access API and three public-domain books. From the US East Coast, a single request answered in a median 185 milliseconds. With sixteen requests in flight the timing run reached 56 requests a second and the largest demo 70, and none of the roughly 700 calls whose retries we logged met a rate limit. The whole afternoon, roughly 1,000 calls and 2,400 judgments, cost under three cents. The three exercises below are ours; scripts and raw results are kept with the article’s sources.

Take the first exercise. We cut Alice’s Adventures in Wonderland into 209 passages and asked six typed questions of each. Which character is most present, where the passage takes place, whether Alice is frightened, whether food or drink is involved, whether she changes size, and how much nonsense is in it. That is 1,254 judgments, returned in 4.1 seconds for one cent. Nothing was generated; every answer is a pick from a list or a probability. Rolled up by chapter, the book’s shape comes back the way a reader would draw it.

Frightened, food and size change are the share of passages in each chapter where the answer was yes; nonsense is the mean position on a four-level scale; the setting is the one Jev chose most often. Alice is most frightened in the pool of tears, changes size where the bottle, the cake and the mushroom are, and eats most at the tea party. The book gets sillier as it goes, peaking at the tea party and the Lobster Quadrille. The Hatter turns up in the courtroom, which is where Carroll put him.

The second exercise is a toy that shows the 255-option ceiling in use. Each of the 59 sentences of chapter one became a 227-way Choice over an emoji palette with a “none of these fits” escape. The run took 1.5 seconds and chose the escape zero times. The result opens 🥱🐇🐇🐇🕳️🕳️🕳️🕳️🫙, locks and unlocks 🔒🔑🔑🚪🚪, and for “in my going out altogether, like a candle” it chose 🕯️ with a probability of 0.99. The median probability on the chosen emoji was 0.56, which is what an honest model should say when it has 227 options and several plausible ones.

Try it yourself

Reading numbers is one thing. What a decision model changes is easier to see than to read, so the three demos below call the same early-access API we measured, with the questions fixed on our server and only your text going up. Each one shows the round trip, the model’s own time, and what the call cost. None of them generates a word: everything you see drawn was chosen from a list or scored on a scale.

Notice what the dashboard did not need. There is no prompt asking for a summary, no JSON to repair, no second call to classify before extracting. The call carried questions for a contract, a support thread, a story and a press release all at once; the model answered every one, and the page drew only the branch that applied. The layout was a decision, made in the same round trip as everything else.

That is the whole novel in a few seconds, and it is the same chapter map as our afternoon run, drawn in front of you. Five passages share each call, so the model is answering thirty typed questions at a time, and the squares arrive in the order the batches come back rather than the order of the book. The chapter table settles as the averages fill in.

The last one is the smallest and the easiest to feel. Thirty sentences, sixty judgments, one call, and a paragraph that shows you where its own mood turns.

Treat calibration as a property you demonstrate, not one you name

Jev is trained with RLCD, “Reinforcement Learning for Calibrated Decisions,” and the published corpus on the method runs to about six sentences. The reward function, architecture, parameter count, training data, compute and calibration method are withheld. There is no paper and no model card; Almeida says the architecture “is close to the chest for now.” Nowhere in the documentation is there a reliability diagram, an expected calibration error or a Brier score. Jev API reference, Hacker News thread.

The probabilities are the product, so the question is whether they are calibrated. The test is mechanical. Bucket the model’s answers by the probability it reported, then check what share of each bucket was actually right: if the 0.2 bucket comes out true about 20% of the time, the probability means something. Plotting those buckets is a reliability diagram; expected calibration error and the Brier score are two ways of scoring the same plot. Calibration is a property you demonstrate, not one you name. So our third exercise was the test.

We took 100 sentences each from Carroll, Austen’s Pride and Prejudice and Dickens’s A Tale of Two Cities, shuffled them, and asked a three-way Choice: who wrote this? Jev answered all 300 in 4.3 seconds for half a cent and was right 267 times, 89%. Carroll was easy, 96 of 100; Austen 94; Dickens 77, whose dialogue was mistaken for Austen sixteen times. Then we bucketed by the probability Jev put on its own answer.

That is a reliability table, and on this task the probabilities mean what they say: expected calibration error across those seven bins is 0.016. When Jev said 0.95 or more, on 166 sentences, every one was right. When Jev said 0.7, the answer was right about three times in four.

Two caveats, and the second is the useful one. First, these are three of the most reproduced books in English, so some of the 89% may be recall rather than reading. To probe that, we shuffled the words of every sentence and asked again. Accuracy fell to 59%, above chance at three ways but far below intact prose, so most of what Jev reads is syntax and voice, not a bag of words. Second, confidence barely moved. The mean probability on the chosen author stayed 0.84, and the 125 scrambled sentences Jev marked at 0.95 or above were right only 83% of the time, not 100%. Calibration held on real prose and degraded on garbage. That is the warning to carry into any deployment: calibration is a property of a distribution, so measure it on yours.

RLCR, Reinforcement Learning with Calibration Rewards, from MIT, adds a Brier-score term to the correctness reward and beats post-hoc confidence classifiers. Its abstract reads: “While ordinary RL hurts calibration, RLCR improves it.” Temperature scaling calibrates an ordinary classifier with one parameter, so the claim worth making is that RLCD beats a temperature-scaled encoder. One afternoon on one task is not that proof. The afternoon produced a reliability table where there was none. Damani et al. 2025, Guo et al. 2017.

Read the benchmark as agreement, not accuracy

The evaluation covers 711 cases across four workflows, scored against this reference: “Instead of debating the correctness of the harness and labels, we assume that the code is correct, and measure against the current smartest large models. For this eval, the reference labels are generated via an average of the responses of GPT-6 Astra and Claude Fable 5.1, both at high thinking, answering every question in the harness.” Every accuracy figure is agreement with a two-model consensus. No human-verified label exists. TypeSafe workflow evals.

TypeSafe discloses this itself: the reference “biases answers towards OpenAI and Anthropic’s models,” and the workflows “were made by individuals on our model capabilities team, so some bias could exist.” The raw data adds what the blog omits: on Security Incidents, Fable “refused or failed” on 88 documents, and Claude Opus 5, itself a scored comparator, was substituted as their judge. Four days before launch TypeSafe wrote: “We need to stop outsourcing credibility to a leaderboard and just be honest.”

Nine models were scored, eight of them chat models and one of them Jev. The two used as the reference answer, GPT-6 Astra and Claude Fable 5.1, grade the test and so do not appear in it.

Jev is fifth of nine, tied with Sonnet 5 and 6.3 points behind the leader, at a fraction of the cost and time. The homepage’s “193.6x Faster, 444.6x Cheaper” names no comparator; our arithmetic from TypeSafe’s own table resolves it to Sonnet 5 for speed and Opus 5 for cost. Those are the slowest Anthropic model and the most expensive model on the board; neither is the top scorer. The blog concedes the pair is “on the higher end of real world gains.” TypeSafe workflow evals.

Per task, Jev beats Sonnet 5 on Security Incidents, 61.7% to 60.8%, and sits 2.3 points behind the leader on Customer Service, 76.0% to 78.3%. On Invoice Processing, the workflow closest to your work, Jev scores 61.8%, eighth of nine and 16.6 points behind Opus 5 at 78.4%.

Eighth of nine is a warning sign, not a verdict. No model scored above 79.1% on any task. If the reference encoded verifiable fact, frontier models would sit far closer to it, so part of every gap here is disagreement between judges rather than error. Across all four workflows, Jev’s 67.8% and Opus 5’s 73.1% may not differ in correctness at all. The same symmetry cuts the other way on invoices: a 16.6-point gap is too wide for judge disagreement to absorb on its own. Nine frontier judges from seven families carry “only about 2 independent votes’ worth of information,” so two are worth close to one. A score cannot exceed its answer key. Kohli 2026, Dorner, Nastl and Hardt 2025.

Two early-access tests, from one corporate family, were the only independent data at launch. On 12 passages with planted defects, Jev caught 6 of 7 and Claude Fable 5.1 caught all 7, at a median 0.35s against 8.83s per passage. Across 6,003 rubric checks, Jev agreed with five LLM judges 90% on average while the LLMs agreed with each other 88 to 95%. Neither figure establishes which model is more often correct. Every’s launch-day test, Good Start Labs.

Compose decisions the way you compose functions

The power of the method is composition, and TypeSafe’s cookbooks show the shapes. Select instead of generate: “A regex finds the candidate values in the text. Tune it to over-find.” A Choice then picks among the spans, so “the value you get back is one of those spans, copied unchanged,” with “none of the candidates fits” as the escape. Jev cannot write INV-0042; Jev can point at it. Verify, then escalate: a cheap model extracts, Jev checks each field with a yes-or-no probability, and only flagged items go to a reasoning model. TypeSafe’s cascade escalates when any field flag crosses a threshold, and on 100 prompts reports that “the cascade frontier sits up-and-left of every single model.” Pre-parsed value extraction, SDE cascade.

Three kinds of tool can hold a closed-set decision, and they fail in different places.

The absent comparator is the encoder: a small classifier you train once on your own labelled examples and then run on your own hardware. Being faster than a chat model at classification is a bar encoders cleared in 2018, and no encoder appears in TypeSafe’s materials. The honest counterweight is also the real advantage: an encoder needs labelled data and a training run per task; Jev needs a schema. ModernBERT, Warner et al. 2025.

Put Jev in front of the model that reads the page

We learned Jev’s thesis the hard way. Our classifier’s verdict used to be scraped out of free prose with a regex, and in one live run three of six documents were overwritten with an impossible empty result; the fix was a code-owned schema with closed enums. Every closed decision in a document pipeline is now a candidate: which extractor runs, which span is the total, whether a value agrees with its source, and what deserves the expensive model. Vision stays where it is. Jev is text-only, “not on images (yet…),” and a model that cannot see a page cannot be the primary extractor. Introducing Jev.

Our proposed design is a hybrid: a fast first decision, a vision model for what needs greater attention, and keep what the fast model gets right. At 10,000 documents a month on TypeSafe’s published per-case figures:

Cost falls at any escalation rate, so cost does not decide the design. The number that does is the error rate among decisions that did not escalate. A confident wrong decision on the fast path never reaches the expensive model. That rate is knowable only if the probabilities are calibrated, and measurable only against human labels. On three novels the probabilities held; on our documents, that is still to be measured.

Decide after a labelled set, not after a launch

If you run closed-set decisions over text at volume, and can label a few hundred of your own cases, Jev is worth a queue position and an afternoon like ours. If your decisions need the page, or need a value written out, keep the model you have and put Jev in front of it. We plan to evaluate Jev against our own classifier on a human-labelled set. We’ll publish what we find — including if it loses. Record the test in the software pilot scorecard and define the fields first, as in OCR vs document parsing. The deliverable is a reliability table on your documents.