A San Francisco lab came out of stealth with $40M and a model that cannot write a sentence. The limitation is the whole idea, and it lands on the part of automation that quietly costs the most.
Jev is a model that returns typed decisions instead of text. You hand it a block of state and a set of questions whose possible answers you have defined in advance. It picks one of those answers for each question and attaches a confidence score. It cannot write you a paragraph.
That sounds like a downgrade until you look at what most automation actually does. TypeSafe AI came out of stealth on 15 September 2026 with $40M in seed funding led by DCVC, and Jev as its first public model. The founders include Diogo Almeida, who worked on InstructGPT and ChatGPT at OpenAI. The model is named after Jevons paradox, which is a fairly direct statement of intent: make the unit cheap enough and people use far more of it.
It has been out for four days and the claims around it are large. Here is what it is, what people are building, and which numbers are still only TypeSafe's own.
It answers typed questions about a piece of state. There are three kinds and you can mix them in one call. A choice picks one option from a list you supply. A score rates the state against an ordered rubric. A noul returns the probability that a yes or no statement is true.
Every answer comes back with a probability for each option and a separate confidence figure. The confidence is the interesting part. TypeSafe trained the model with a method it calls Reinforcement Learning for Calibrated Decisions, which optimises for probabilities that match real outcomes, so answers given at 90% should be right about 90% of the time across many answers. That is what lets you write a threshold and mean it.
TypeSafe calls this a System One model, borrowing the label for fast, intuitive thinking. The framing is that a chat model performs deliberate reasoning you mostly do not need when all you want is a decision.
A language model writes its answer. Jev selects one. That single difference produces most of the others.
When you ask ChatGPT, Claude or Gemini for JSON, the model still produces it one token at a time, each conditioned on the last. Structured output modes constrain that process and they work well, but the answer is still being written. It can stop early, and you still parse a string before your code can branch on it.
Jev evaluates all the questions at once against the same state and returns values drawn from the sets you defined. A schema error is not unlikely, it is unavailable, because there is no string to malform. That is also the honest version of the no-hallucination claim. It is not that the model was trained out of making things up, it is that it was never given the ability to invent a value.
The trade is total. Jev will never write your customer's email, summarise a call or explain its reasoning. Those stay with a language model.
A week in, the pattern in what developers are sharing is consistent, and we have catalogued the builds separately. Jev is being slotted into the places where a frontier model was doing small repetitive judgement work and charging full price for it.
An agent driving a web page has to decide which element to click next, over and over. Asking a chat model to reason about the button takes seconds every time.
Posed instead as a choice between the elements already on the page, the answer lands in a few hundred milliseconds. That is the difference between an agent that feels responsive and one that stalls.
Safety and policy checks usually get sampled, because running a frontier model over every message in a pipeline is hard to justify on cost.
At a fraction of a cent per check, screening all of them stops being a budget decision. Teams are using it to catch prompt injection and contradictions before anything acts on them.
Retrieval hands back far more candidate passages than are worth putting in a prompt, and the usual filter is a similarity score that does not understand the question.
Scoring each candidate for relevance first means the context window gets spent on the passages that earn it, and the expensive model gets called once.
Category, severity and whether the customer is already angry are three separate questions about the same ticket, and they come back from a single call.
Each answer arrives with a calibrated confidence, so the confident ones can be automated and the rest handed to a person, rather than guessing where the line sits.
Developers have wired it into Tetris, Pac-Man and Doom, scoring the legal moves every frame instead of asking a model to plan a strategy.
The same shape covers buy, sell or hold decisions per block of a blockchain, and robotics. Anywhere the decision has to land inside a loop that will not pause for it.
Anything that means producing a value rather than picking one. TypeSafe is unusually direct about this, and the limits are sharper than the launch coverage suggests.
There is a subtler failure mode too. Questions needing several interpretive hops degrade noticeably, and questions pointing straight at a field in the state you supplied do best. Getting good results is less about prompt craft than about shaping the state so the question is nearly a lookup.
No. Every headline number so far is TypeSafe's own. Worth saying plainly, because the figures are being repeated without the caveat attached.
The claim is 193.6 times faster and 444.6 times cheaper: 0.114 seconds against 8.566, and $0.000081 against $0.013880. Those came from one workflow TypeSafe designed and ran itself, against a single frontier model. There is no published accuracy at a matched quality bar, which is the number that decides whether a cheap call is actually cheaper. There is no comparison against a small language model or an ordinary classifier, which is what many of these tasks would otherwise use. Latency is quoted as an average rather than a distribution, and averages hide the tail that breaks a real-time loop.
The pricing is checkable and genuinely low at $0.042 per million input tokens with output free. The structural claim about type errors holds up on its own logic. The performance multiples are marketing until somebody outside the company reproduces them.
As the routing layer, not the writing layer. Most automations we build are roughly nine parts decision to one part language. Is this a refund request, is this lead worth a call, does this invoice need a human, which of these six paths does it take.
Those decisions are where the latency and the bill accumulate, because each one has historically meant another call to a model built to hold a conversation. Pushing them onto something that answers in 100 milliseconds and charges almost nothing changes what is worth automating at all. A check you could not justify running on every record becomes one you run on all of them.
The language model does not leave the stack. It still drafts the reply and writes the summary. It stops being the thing that decides whether a reply is needed at all.
On the pre-submission audit, where the same checks get run against every build. We ship FlutterFlow apps to both stores, and before anything goes to review somebody walks a list that barely changes from project to project.
Do the privacy labels match what the app actually collects. Does every permission string explain itself. Is there placeholder copy or test data sitting in a screenshot. Is login gating content the reviewer is expected to see. Is a debug flag still set. We wrote up the six rejection reasons we see most often because the same handful accounts for nearly all of them.
That list is a set of yes or no and severity questions asked against one piece of state, which is the shape Jev takes without any adaptation. Each check returns a confidence, so the ones it is sure about get logged and the uncertain ones get a person. The same pattern covers first-pass triage on a failed build, where the question is which of a known set of causes this looks like rather than what the fix should say.
Being straight about the stage: the model is four days old and we are running this alongside the manual review, not instead of it, precisely because the calibration is the part nobody outside TypeSafe has tested. What it has changed already is where the review time goes. Nobody is re-reading a checklist to find the two items worth arguing about.
For internal decisions that are reversible and already have a human fallback, it is worth a pilot. Routing, triage, relevance scoring and guardrails all fit, and all fail safely when the model is wrong.
For anything customer-facing or irreversible, wait. It is early access, TypeSafe labels it version 0.01, and the calibration that makes the confidence scores worth trusting is exactly the property nobody outside the company has tested. The sensible first project is one you can measure against whatever you do today, where being wrong costs a re-run rather than a customer.
