Jev Can't Write a Line, But 13% of Paid Teams Use It

A Model That 13% of Paid Teams Adopted in a Day Can’t Write a Sentence

Reader, on September 15, the American startup TypeSafe AI ended two years of stealth development and released its first model, Jev. The announcement came bundled with a $40 million seed round led by DCVC. The founder, Diogo Almeida, is a former OpenAI researcher who co-authored the InstructGPT paper — the very methodology that taught ChatGPT to follow human instructions well.

The reaction was fast. Vercel announced that within 24 hours of listing Jev on its AI Gateway, roughly 13% of its paid teams were already using the model. By the same measure, that’s more than double the adoption of the GPT-5.6 family and over 6 times that of Fable 5.1 — the fastest-adopted model in the gateway’s history, according to Vercel. Within days, it also showed up in Cloudflare’s and OpenRouter’s model lineups.

And yet this model can’t write. It can’t code either, and it can’t explain why it reached a given judgment. TypeSafe says so itself, in its own documentation. It’s weak at arithmetic and date comparisons, and it reads negation and hedged phrasing literally, without picking up on nuance.

I first wrote about this for a ZDNet column. The space was tight, so a lot of the explanation got cut. Today I want to unpack all of it: exactly what Jev does, how to read the numbers the company is putting out, and where KASI — the on-device project I’m working on — is trying to take the same underlying idea.

There’s a line I say often: not everything needs superintelligence. Jev is that idea turned into a price tag.

---

Jev doesn’t write answers — it picks them

There are two things you send to Jev. One is state — text that becomes the object of judgment, like a customer inquiry, invoice data, or an agent’s execution log. The other is a question in a fixed format. There are only three kinds of questions.

Question type	What it asks	What it returns
Noul	Is this statement true?	Probability of being true (0–1)
Choice	Which candidate is it (up to 255)?	The chosen candidate, per-candidate probabilities, and confidence
Score	Where does it fall on a defined scale?	A score, per-grade probabilities, and confidence

Almeida’s own explanation on Hacker News is the clearest way to think about it: Choice maps to a match statement in code, Score to sorting, and Noul to an if statement. Noul is short for Bernoulli. In other words, the recipient of Jev’s answer isn’t a person — it’s code.

An example the Turing Post Korea team ran using early access shows this structure well. A user had reported a Wi-Fi outage, gotten no response for over a week, and followed up with “What’s happening with my ticket?” That single message triggered four separate questions at once.

• Priority (Score): medium, 83%
• Owning team (Choice): IT Helpdesk, 100%
• Deadline mentioned (Noul): 5%
• Tool to invoke (Choice, roughly 200 candidates): ticket-status 73%, wifi-troubleshoot 25%

The last answer is the important one. Going purely by keywords, you’d expect the Wi-Fi repair tool to win — but the user isn’t asking how to fix anything. They’re asking about the status of a ticket they already filed. A single agent task can hit dozens of forks like this before it’s done.

One more thing worth noting: Jev never looked up the ticket itself. It only chose which tool to invoke; the actual execution was carried out by whatever software received that choice. This split — between the thing that decides and the thing that executes — comes back later when I get to KASI.

Why It’s Fast and Cheap: It Skips the Writing Step

Ask a typical LLM¹ “does this inquiry belong to refunds, shipping, or technical support,” and the process gets long. The model generates tokens² one at a time to write out a sentence or JSON, and then software has to parse that text back out to extract the value. The answer is one of three options, but the model goes through an entire writing process just to arrive at that one option.

If the candidate answers are already fixed in advance, there’s no need to write anything. You just need to read the probability the model assigns to each candidate. Skipping the generation step makes it fast, and since the output can never fall outside the predetermined format, there’s no risk of parsing errors either. Even if you send multiple questions at once, each is computed separately and simultaneously, so response time barely increases as the number of questions grows. The published pricing is $0.042 per million input tokens, with no charge for output. Response times range from 0.07 to 0.5 seconds.

TypeSafe hasn’t disclosed its internal architecture. All that’s been revealed is a name — a new architecture, a parallel sampler, and something called “Reinforcement Learning for Calibrated Decisions (RLCD)” — with no weights and no paper released. Still, the underlying principle itself isn’t a secret. Shortly after the launch, an independent project called OpenJev reproduced the same behavior simply by reading the logits³ a public model assigns to each option and normalizing them. On a 102-row evaluation subset, the 4-billion-parameter Qwen3.5 4B achieved an 84.5% match rate, compared to 88.3% for the published Jev value on the same subset. A 600-million-parameter model managed only 40.7%. The caveat is that the sample size is small, and browser-based builds are quantized⁴, so the numbers could shift.

Two things can be read here. First, much of the efficiency Jev demonstrates comes from a design that converts problems into closed-ended choices, and that design works even on small open models. Second, that doesn’t mean Jev is just a small model wearing fancy packaging. One developer pulled 1,000 MMLU-Pro problems and ran them through Jev, getting 83%, while two open Qwen-family models on the same problems scored around 60%. In other words, the gap is small on easy classification tasks and widens on hard ones.

There’s another number from TypeSafe’s evaluation site that caught my attention more. They compared, across every model, giving the same task as one monolithic prompt versus breaking it into several narrow questions with the rest handled by code — and averaged across four tasks, the split approach was, without exception, more accurate, cheaper, and faster. Even Claude Opus 5 scores 64.8% with a single prompt but 73.1% with the split workflow. That’s a takeaway you can carry with you whether or not you ever touch Jev.

The phrase looks accurate and complete. Here is the corrected fragment:

The 193x claim: compared to what, exactly

Typesafe’s homepage states “193.6x faster and 444.6x cheaper.” Before taking that multiplier at face value, you need to check what’s in the denominator. Here’s the average across four tasks, as published by the evaluation site.

Model (workflow type)	Accuracy	Cost per case	Time per case
Jev	67.8%	$0.0004	0.4s
GPT-5.6 Luna	66.8%	$0.0033	12.9s
GPT-5.6 Terra	67.9%	$0.0304	10.1s
Claude Sonnet 5	67.8%	$0.1174	78.1s
GPT-5.6 Sol	74.1%	$0.0836	23.3s
Claude Opus 5	73.1%	$0.1761	37.8s

Benchmarked against Terra, which matches Jev on accuracy, Jev is about 25x faster and about 76x cheaper. Against Luna, the cheapest of the bunch, the cost gap shrinks to roughly 8x. The 190x and 440x figures only emerge if you use the slowest model in the table, Sonnet 5, and the most expensive, Opus 5, as denominators, respectively. 25x and 76x are already a huge gap on their own — but someone chose the most favorable baseline to inflate the multiple further. In fairness, Typesafe itself states in its announcement that this figure likely sits at the upper end of the real-world gain.

There’s a more important catch buried in the accuracy numbers. The answer key for this evaluation wasn’t written by humans. It’s an average of the responses from GPT-6 Astra and Claude Fable 5.1, used as the reference label. So that 67.8% isn’t really a correct-answer rate — it’s the rate at which Jev’s output agreed with two top-tier models.

The variance by task is also large. On customer support, Jev scores 76.0% against Sol’s best-in-class 78.3%, a gap of just 2.3 percentage points. On invoice processing, Jev drops to 61.8% against Sol’s 79.1% — a 17.3-point gap. Invoices require matching amounts, dates, and quantities against each other, and that’s precisely the area Jev’s own documentation admits is a weak point.

The phrase “zero hallucination” should be read the same way. It means the output never strays outside a fixed format. Typesafe itself has said that the 0% figure isn’t a measured result — it’s a value guaranteed by design. Wrong answers that fit the format can still occur. Classifying a technical inquiry as “billing” gets the type right and the meaning wrong.

Is 0.85 Really 85%?

The biggest unverified item here is the quality of the probabilities themselves.

The TypeSafe documentation recommends splitting confidence into three bands. If it’s high, process automatically; if it’s medium, get user confirmation or flag it for review; if it’s low, don’t execute at all — hand it off to a human or another system. In the documentation’s own example code, light tasks like checking a balance just go ahead, while high-risk operations like approving a withdrawal only move to the next step once confidence exceeds 0.9. It’s a design where the model’s admission that it doesn’t know isn’t thrown away — it becomes a branching condition.

This design only holds up if the probabilities can actually be trusted. If you gather every judgment where Jev answered 0.85, roughly 85% of them should turn out to be correct. TypeSafe hasn’t published the calibration⁵ curve that would demonstrate this, and no third party has yet verified it against human-labeled data.

There’s one independent field report worth citing here. paddo, a developer who runs a price-comparison engine, handed Jev 9,081 low-confidence product-matching cases that no human dared to review by hand. It cost 32 cents and took 13 minutes. Jev rejected 49% of them, confirmed 21%, and held off judgment on the remaining 30%. The pile humans needed to review shrank from 9,081 cases down to 2,686. When he went through 50 of them himself, 48 held up. At the same time, he wrote that 50 cases aren’t nearly enough to verify whether 0.85 really means 85%, so for now he’s only logging these verdicts in a reference column and hasn’t wired any actions to them. I think that’s exactly the right instinct.

There’s another weakness the documentation discloses that anyone dealing with these probabilities really needs to see. For a duplicate-payment inquiry, asking “is this a refund request?” produced 0.72, while asking “is this a request for something other than a refund?” produced 0.47. Add them together and you get 1.19. Two probabilities from the same question asked in reverse don’t sum to 1. The documentation’s advice: don’t expect that kind of arithmetic to hold — ask about each judgment in exactly one way, and stick to it.

Korean deserves its own note here. One independent commentary site points out that Jev’s primary training language is English. The very first weakness the documentation admits to is a habit of reading things too literally — and Korean workplace language is full of indirect refusals and unspoken omissions. In a language where “I’ll look into it” can quietly mean no, there’s no substitute for testing this on your own data.

Taking the Same Principle Inside the Device

From here, this is my own story. I’m working on an on-device AI project called KASI (Kernel Action Schema Intelligence). I’ve published the source code on GitHub under an Apache 2.0 license — free for research and personal use, paid for companies and institutions.

KASI does one thing too. It takes a Korean-language request and a JSON tool schema⁶ and turns it into one of five structured actions.

Action	Meaning	Who decides
call	Invoke a tool with arguments	Model proposes, wrapper validates
clarify	Ask back for missing information	Model or wrapper
confirm	Get consent before running a risky tool	Wrapper only
refuse	Reject an unknown tool, or an ambiguous/dangerous request	Model or wrapper
respond	Relay the tool’s execution result to the user	Model (only after receiving the result)

In this table, the wrapper is ordinary code sitting between the model and the device — the kind you can read and test.

When someone says “dim the living room lights,” there’s no reason for the model to answer in a sentence. What’s needed is a decision: which tool to call with which arguments, whether to ask back, or whether to refuse. The starting point is the same as with Jev’s system. You close off the output space.

Missing Information vs. Missing Permission

While designing this, the thing I wrestled with longest was separating clarify from confirm. “Turn on the oven” is missing a temperature. “Open the front door” has all its arguments filled in, but it still shouldn’t just execute. The first case is missing information; the second is missing permission. From the device’s side, they even need different screens. Information requires re-entering a value; consent just needs a single yes/no button.

That’s why confirm isn’t something the model chooses. The wrapper decides by cross-checking the call the model proposes against the tool’s risk tier. Risk-tier information is stripped out of the schema before it ever reaches the model. The model might guess that “opening a door is probably risky,” but that guess carries no authority. A record of consent is a state of the device, not a rhetorical flourish from the model. Nor does the model execute tools directly — final execution authority stays with the host application.

The reason I didn’t add a sixth action for “hand off to a bigger model or a human” ties back to the Jev discussion. Since every action comes with a confidence score, the host can decide whether to hand off just by looking at that number — the same idea as the three zones in Jev’s paper. If confidence falls short of the tool’s risk-tier threshold, the wrapper discards the proposal and converts it into a clarify: “please say that again.” The design defaults are 0.65 for low risk, 0.80 for medium, and 0.95 for high. This gate sits ahead of the consent gate — you shouldn’t be asking a user for consent on a proposal you’re not confident about in the first place.

The paper on this model is scheduled for publication later this year.

The Difference Is Location

Jev is only available through Typesafe’s cloud API; its weights are private, and there’s no way to install and run it yourself. Its sub-0.1-second responses only hold while the network is attached.

For appliances, factory equipment, and vehicles — environments that must keep working when disconnected and where sending data out is difficult — the judgment has to conclude inside the device itself. KASI’s target devices span three tiers: Arduino-class microcontrollers, Raspberry Pi-class single-board computers, and small PCs. The current baseline model has about 45 million parameters, and the goal is to fit it within a 16MiB model file and 32MiB of runtime memory. How far the model can be shrunk once you narrow the choices further and specialize for Korean and tool-calling is exactly the question KASI is trying to answer. My goal is to close the output down to five actions so that even a small, network-less device can respond in under 0.1 seconds.

On small devices, cutting down on writing alone isn’t enough, so I added two more mechanisms. One is grammar-constrained decoding: it extracts a grammar from the tool schema declared at that moment, so the model literally cannot generate a tool name that isn’t on the list, or a value outside the allowed range. It’s the same kind of guarantee as Jev’s “no type errors” — and it comes with the same limitation. Getting the format right and getting the meaning right have to be measured separately. The other mechanism is input normalization. When typing in Korean, full-width digits sometimes slip in — like “２２do” (full-width digits plus “do,” meaning “22 degrees”) — and these get folded down to 22. Conversely, for string arguments that need to pass through exactly as the user typed them, the original bytes are restored. Beyond Korean, the system also accepts English, Chinese, and Japanese input.

What I Can’t Show You Yet

I should be upfront about the limitations too. The public repository currently has no model weights, and the README states plainly that the repo makes no claims about quality or resource performance. Public benchmark evaluations and real-device measurements of speed and memory are still outstanding. When I re-measured a previous checkpoint on a development Mac — isolating just the model core — memory usage came in around 33.4MiB with five tools declared, already over the 32MiB target.

I need to be even more candid about the confidence scores: they’re not yet calibrated. Across two development capture runs covering 191 fully generated responses, one run assigned a confidence of 1 to 179 of them, and the other assigned 1 to all 191. Earlier, I asked Jev to produce a calibration curve — well, the same homework is sitting on my own desk. That’s why I’m calling 0.65, 0.80, and 0.95 design defaults rather than operating values. All I can honestly report right now is the direction of the design.

Oswarld’s Lens

What catches my attention about Jev isn’t the model itself but the division of labor it assumes. The calls that companies currently route through LLM APIs actually mix two different kinds of work. There’s open-ended work — writing reports, generating code, summarizing — and there’s work where the answer is really a choice among fixed candidates: classifying an inquiry, picking an agent’s next step, approving or holding a payment, deciding whether to hand off to a human. That second category doesn’t require writing anything, yet it’s been handed to the same models at the same per-call price as the first. And as agents multiply, that second category of calls grows faster, because an agent makes dozens of judgment calls for every single piece of writing it produces. Jev’s pricing shows that the cost of that judgment can drop by an order of magnitude, or more, from where it stands today.

The name Jev comes from the economist William Stanley Jevons — the paradox where more efficient steam engines led to more coal consumption, not less. Baked into the name is the expectation that once judgment gets cheap enough, AI will start showing up in small decisions that nobody currently even considers calling AI in for. Paddo’s case is a good illustration. He’d designed that review step back in June but held off, wanting to check the cost first. Once it came out to 32 cents for 9,000 cases, it became something worth running every single night. As he put it, what price changed wasn’t accuracy — it was design.

As I keep saying, not everyone needs the intelligence of a GPT-6 Astra or a Claude Fable 5.1. And not every task needs that level of intelligence either. There are models suited to work where simple classification and fast judgment matter most, and there are models suited to different environments and needs. I read the fruit-fly-brain story making the rounds lately in the same light. Somewhere out there, there are problems that a fruit-fly-sized brain is perfectly capable of solving. But as the 17.3-percentage-point swing in invoice processing shows, you only find out which tasks those are by actually measuring it.

Closing

There’s something worth doing before you decide whether to adopt Jev at all. Count what percentage of your company’s LLM call logs are calls where the candidate answers are already fixed. That percentage is the ceiling on how much cost you could actually cut. The next step is to get even a few hundred human-labeled data points for that task. You need to check against your own data not just accuracy, but whether the probability the model states actually matches its real hit rate — that’s how you set the threshold for automated processing. This matters even more for Korean-language tasks.

Companies that build actual physical devices face one more question: should that judgment happen in the cloud at all? If connectivity, latency, or data export is a concern in any way, putting a small model with a closed action space directly on the device becomes worth considering.

Jev showed, through its pricing, that judgment can become a product separate from writing. Where that judgment gets executed, and whose verification it passes through, is something each company has to decide with its own operational data.

---

💬 Among the LLM calls you’re running right now, which ones are really just “pick the right answer” tasks? Drop the task that comes to mind in the comments.

📨 If you know a colleague wrestling with agent costs or on-device AI, share this piece with them.

References & Further Reading

Primary sources

• Diogo Almeida, “Introducing System One Models & Jev”, TypeSafe AI, 2026.9.15. ··· This is the launch announcement. Read it alongside the “Nuance” notes the company itself appended under each claim.
• TypeSafe AI, “Workflow evals”. ··· This is the original source for the table in the body text. Broken down by task, it shows just how wide the variance is across models.
• TypeSafe AI documentation, “Introduction”, “Confidence”, “Jev 1.13 jaggedness”. ··· These cover the three question types, the three confidence bands, and the list of weaknesses the company disclosed on its own. If you’re evaluating adoption, I’d start with the weaknesses document.
• Vercel, “Jev is the fastest-adopted model in AI Gateway history”, 2026.9. ··· This is the source for the paid-team adoption rate within 24 hours.
• paddo, “The Thirty-Cent Judge”, 2026.9.19. ··· A write-up of 9,081 real-world uses. The author is the most meticulous about spelling out exactly what remains unverified.

Further Reading

• “You could have built Jev”, sgnt.ai. ··· A roundup of reproduction projects based on reading logits, along with MMLU-Pro comparisons.
• Kwangseob Ahn, “[Kwangseob Ahn’s AI Gentesis] Why an AI that can’t write well is generating buzz — the price Jev put on ‘judgment’”, ZDNet Korea, 2026.9.20. ··· A condensed version of this piece.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

📝 Glossary

각주

1. LLM (large language model): A model trained on vast amounts of text that generates writing by predicting what comes next. It’s the foundation behind services like ChatGPT and Claude. ↩

2. Token: The smallest unit a model uses to read and write text — think of it as a chunk slightly smaller than a word. API pricing is also billed by this unit. ↩

3. Logit: The raw score a model assigns to each candidate right before converting it into a probability. Normalize these scores and you get the probability for each candidate. ↩

4. Quantization: A compression method that packs a model’s numbers into fewer bits. You gain size and speed, at the cost of some accuracy. ↩

5. Calibration: A measure of how well a model’s stated probabilities match its actual hit rate. If a model says there’s a 70% chance of rain, and you collect all the days it made that call, seven out of ten of them should actually see rain — that’s good calibration. ↩

6. JSON tool schema: A machine-readable specification listing a tool’s name, the arguments it takes, and the range of allowed values. The model consults this spec to decide which tool to call and how. ↩