Open the search terms report for last month. There are forty thousand rows in it. You sort by spend, read the top two hundred, add a handful of negatives, and close the tab. The other 39,800 rows were never judged by anyone, and you made peace with that a long time ago, because reading them was never going to happen.
That arithmetic changed last week. Not the part everyone is talking about, and not entirely in the direction the pricing page suggests.
A model that does not write anything
On September 15 a company called TypeSafe came out of stealth with a model named Jev. The interesting thing about it is what it refuses to do. It does not produce sentences. Their words: System One models “do not write replies, produce code, or generate explanations of their reasoning.”
What it does instead is answer a typed question. You hand it some state (a search term, an ad comment, a product page, an inbound form) and a question with a fixed list of allowed answers, and it hands back one of those answers with a probability attached. You cannot get a paragraph out of it. You cannot get a surprise out of it either, because every possible output is defined before the call is made. Their framing: “unstructured state in, typed probabilistic decisions out.”
If you have ever asked a chat model to label five thousand things and gotten back four thousand clean labels plus a thousand rows where it explained itself, invented a sixth category, or wrapped the answer in a friendly sentence, you already understand the appeal.
The price of a judgment
The published numbers are why this belongs in a marketing conversation and not only an engineering one.
Input costs “$0.042 / MTok.” Output tokens are free, described as “too cheap to meter.” A call runs “70ms-500ms” end to end, and the docs say “most queries complete in about 100 ms.” On the same page they put frontier language models at “from $0.20 to $10 / MTok” for input, output around five times that, and three to 329 seconds a call.
Run it against the search terms report. A term plus a short instruction is roughly eighty tokens of input. Forty thousand of those is 3.2 million tokens, which comes to about thirteen cents. The same job on a language model, using TypeSafe's own stated range and paying for the output it has to write, lands somewhere between about $1.25 and $62.
Which gives you the first honest conclusion, and it is not the one the pricing comparison is reaching for: at forty thousand rows, cost was never what stopped you. Sixty dollars would not have stopped you. What stopped you is that nobody was going to read forty thousand rows, and a three second call, made one at a time, turns that job into thirty-three hours. At a hundred milliseconds it is about an hour.
The money starts mattering one scale up. Judge every session, or every product against every placement every week, and call it two million decisions a month. That is about $6.72 on Jev against roughly $62 to $3,100 on a language model, depending which one you would otherwise have reached for. My favorite number in the whole launch is buried in a demo where they had the model play Doom. The engineer building it was nervous about running ten queries a second, “which ends up costing ~$7/hour.” Ten judgments a second, all day, for the price of lunch.
What gets cheap is the thing you were sampling
Two things change and only one of them is the bill.
The first is that sampling becomes census. Every place your process says "review the top 200" exists because judgment used to be expensive. The top 200 by spend is not a sample, it is the head of the distribution, and it excludes by construction the long tail where quiet waste lives. Small slices also make you confident about noise, which is its own expensive habit (the winner was often a coin flip). Judging all of it is a different activity from judging the top of it.
The second is where the decision can happen. A hundred milliseconds fits inside a page load. Three seconds does not. That is the line between a judgment that shows up in a report next Tuesday and a judgment that changes what somebody sees while they are still on the site.
It cannot hallucinate, and it can still be wrong
This is the part I would slow down on.
The launch post says Jev “can't hallucinate.” That is true, and it is narrower than it sounds. It means the model cannot return a value outside the set you defined. Ask for one of five intent categories and you get one of those five, every time, no invented sixth, no prose around it. That is a guarantee about the shape of the answer.
It is not a guarantee about the answer. Their documentation says so, plainly, and I think it is the most useful sentence they published: “Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct.”
Both things are true at once, and the gap between them is where all the work lives. Calibrated means that out of a thousand answers marked 80% confident, about eight hundred are right. It does not tell you which eight hundred.
Then the second-order problem, which I have not seen anyone mention. A typed answer never looks wrong. When a chat model goes off, it usually tells on you: the output rambles, hedges, contradicts itself, comes back in the wrong format, says something no human would say. That weirdness was doing real work. It was your smoke alarm. A clean label with 0.83 next to it looks identical whether it is right or badly wrong, at any volume, forever. Take the smoke alarm out and you need to install a different one on purpose, because this thing will never volunteer that it is off.
Credit where it is due on the evidence
TypeSafe is unusually honest about its own claims, and it is worth reading what they admit to.
On speed: “our published evals are generally run from our laptops on the West Coast.” On the benchmark workflows: they “were made by individuals on our model capabilities team, so some bias could exist.” On price: “We can't prove it isn't subsidized.”
And then the line worth reading twice, about how the benchmark decides what the right answer even is: “We use the average of GPT-6 Astra and Fable 5.1 as the reference answer.” So a high score means it agrees with two other models. Agreement is not correctness. Three systems can be wrong about the same ad in the same way, and the scoreboard would call that a pass.
None of that makes the product bad. I would rather buy from people who write it down. What it tells you is how to read the launch: the price and the latency are facts you can verify in an afternoon, and the intelligence claim is homework the vendor set and graded. The only grader who matters for your account is you, on your data.
The jagged edges sit exactly where marketing work sits
They publish a page listing what the model is bad at, which is not a normal thing for a vendor to do. Read as a list of your own weekly tasks, it is pointed.
- “Jev is not a calculator.” And “jev-1.13 does not count reliably.” So not your budget math, and not "how many of these mention shipping".
- Dates: “Asking which of two dates comes first, how far apart they are, or whether one falls inside a window is unreliable.” Did this order land inside the promo window is a code question, not a model question.
- “jev-1.13 answers the question you wrote, not the one you meant.” Anyone who has written a brief knows the distance between those two, and here nobody pushes back.
- “Accuracy falls as the state grows with content unrelated to the decision.” The instinct is to hand it everything you know about the visitor. That makes it worse, and it makes a wrong answer impossible to trace.
Their fix is the same each time, and it is good practice with or without this model: “Extraction is a judgment, so give it to the model. Arithmetic is not, so keep it in code.”
What I would actually do with it
Access is a waitlist right now, so this is a plan and not a review. I have not run it.
- Pick a job you currently sample, not one you already do well. The value is in the 39,800 rows nobody reads, not in doing the top 200 slightly faster.
- Hand label two hundred rows yourself first. That is your answer key, you build it once, and without it you have no way to know whether any of this works. Per the section above, it will look like it is working either way.
- Use a band, not a threshold. Their own cookbook shows no below 0.30, yes above 0.70, and everything in between going to a person, because with a single cutoff “probabilities 0.49 and 0.51 cause opposite actions even though both express substantial uncertainty.” They are careful to call that band illustrative rather than a recommendation, which is the right caution. Pick your own numbers off your own answer key.
- Ask one thing per question and combine the answers in code. A question that secretly contains three questions is where accuracy goes.
- Send the smallest state that can answer it. Filter first.
- Run it beside the decision you would have made anyway for a month before you let it act alone. That month is the cost of the whole thing, and it is a lot cheaper than the alternative.
Where we land on this
Cheap judgment does not remove work, it moves it. When judging a row costs a fraction of a cent and comes back before the page finishes loading, the constraint stops being what you can afford to decide and becomes what you can afford to check. That is a better problem. It is still a problem, and it is one most teams will not budget for, because the output looks tidy from day one.
The other half is the input. A decision is only ever as good as the state you hand it, and for most of the traffic you already paid for, the state is an anonymous row: one session, two pageviews, no name attached. A hundred millisecond judgment about a stranger is still a judgment about a stranger. Knowing who is actually on the page is what makes the cheap decision worth making at all.