Jev and the Case for System One AI
KynodexA large share of production LLM traffic answers small, closed questions: is this ticket urgent, which queue does it go to, is this tool call safe, does this citation back the claim. We send those questions to a model built to write essays, then parse its JSON, retry when it breaks, and trust a confidence it cannot measure.
That costs seconds per call and cents per thousand. Worse, an LLM's stated certainty barely tracks whether it is right, so there is no reliable signal for which answers deserve a human second look.
Jev, released in September 2026 by TypeSafe AI, is a bet that these decisions deserve their own kind of model. It is worth a careful look, partly for what it does well and partly for how much of its pitch is still self-reported.
What Jev is
Jev does one job: it decides. Hand it some context and a few questions whose possible answers you have already fixed, and it hands back a structured verdict with odds attached. There is no prose and no explanation; the consumer is your program, not a person.
Who built it. TypeSafe AI, a San Francisco startup founded in 2024. Its founder, Diogo Almeida, previously worked at OpenAI on InstructGPT and ChatGPT. The company spent about two years in stealth and raised a $40M seed led by DCVC.
When. Early access opened on 15 September 2026. The current version is jev-1.13, proprietary, with no published paper or weights.
The name. "System One" borrows Kahneman's term for fast, intuitive judgment, as opposed to slow deliberate reasoning. "Jev" nods to William Stanley Jevons: Jevons observed that making a resource cheaper tends to raise total use, and TypeSafe expects the same of machine judgment.
TypeSafe pitches it as something you call like any other function in your codebase. Jev supplies the judgment; when and how to act on it remains logic you own and test.
How it works
Every call has two parts: a state (a string, a JSON object or an array of text) and a dictionary of named questions. Each question is one of three primitives.
Primitive | What it asks | What comes back |
|---|---|---|
| Pick one option from a set you define (up to 255) | The option, a probability per option, a confidence score |
| Place the input on an ordered rubric | A continuous score and a confidence score |
| Is this statement true? | One probability from 0 to 1 |
Questions are evaluated side by side rather than one after another, so a call with six questions takes little longer than a call with one. A trimmed response from TypeSafe's quickstart looks like this:
{
"department": {
"choice": "technical",
"probabilities": { "billing": 0.159, "technical": 0.84, "sales": 0.001 },
"confidence": 0.596
},
"is_urgent": { "noul": 0.999 }
}
Two design choices matter most for engineers:
The schema is enforced by construction. You list the legal answers up front, and nothing else can come back. Retry-and-repair code for malformed JSON goes away.
Confidence is trained, not prompted. TypeSafe trains with what it calls RLCD (Reinforcement Learning for Calibrated Decisions), where the training signal is whether a stated 80% turns out right about 80% of the time, not whether a reviewer liked the answer. Use the answer to pick the branch and the confidence to decide whether to take it automatically.
Developers can call it through a REST API (model: "jev-latest"), the Python typesafe_sdk, Vercel AI SDK 7 via AI Gateway, OpenRouter, or LangChain's langchain-typesafe package. Context is capped at 64k tokens.
The numbers: claims and what others measured
Jev is clearly far faster and cheaper than an LLM on closed decisions. How much more accurate or calibrated it is has not been independently shown yet.
What TypeSafe says. Input costs $0.042 per million tokens and output is free. End-to-end responses take 70 to 500 ms. The homepage headline is 193.6x faster and 444.6x cheaper than frontier LLMs. TypeSafe itself notes those multiples come from four workflow evals its own staff wrote, run against LLMs forced through its structured-decision adapter, and are likely at the high end of what you would see.
What others measured.
Test | Result | Reported by |
|---|---|---|
Jev vs Fable 5.1, 12 passages × 4 checks | 0.35 s vs 8.83 s median per passage; 6 of 7 vs 7 of 7 planted defects caught; about 580x cheaper | Dan Shipper, Every |
37 documents × 21 questions | 777 judgments in under 0.7 s for about a quarter of a cent | Mike Taylor, Every |
pi-warden coding-agent guardrail | About 250 ms per check; 42 holds in 17,000+ calls, about 88% correct | Community project |
Legal retrieval reranking | Top-1 accuracy 5% → 18%; 1,200 calls for $0.0645 | TypeSafe cookbook |
The Every comparison is the most useful single data point: Jev won decisively on speed and cost and lost narrowly on accuracy, missing one planted defect out of seven. That is the trade a CTO should expect, not a free lunch.
Treat the "0% hallucination" chart with care. TypeSafe concedes it is not measured; it only means the output always matches the schema. A valid but wrong answer is still possible.
Where it fits in a production stack
Think of Jev as a gatekeeper that sits ahead of your LLM, not a replacement for it. It handles the high-volume closed decisions cheaply and passes only low-confidence cases to slower, more expensive judgment.
The threshold is yours to set, which is the whole point of a calibrated score. Workloads that fit this shape:
Triage and routing. Support tickets, inbound leads, emails and comments classified and sent to the right queue.
Model routing. Pick which LLM should answer a prompt; LangChain ships this as
ModelRouterMiddleware.Agent guardrails. Score a coding agent's tool call for risk before it runs; LangChain's
AutoModeMiddlewaredoes this for bash.LLM output checks. Does a citation support the claim, is a reply on-policy, does a page contain a prompt injection.
Reranking. Score each search result against the query, then sort in code.
Map-reduce over large data. Tag every row of a crawl or a backlog when an LLM pass would be too slow or costly.
For teams in lending or other regulated work, the typed, auditable output is the attraction: every decision is a logged value with a probability, not a paragraph someone has to interpret.
Where it breaks
TypeSafe's documentation lists jev-1.13's known weak spots. In practice they fall into six areas, each with a sensible mitigation.
Risk area | What we would do |
|---|---|
Ambiguous wording | Jev takes a question at face value, so write the edge cases into the question itself |
Numbers and calendars | Keep arithmetic and date logic in ordinary code; ask Jev only for the facts you need |
Chained reasoning | Split a question that needs several inference steps into smaller ones |
Long, cluttered input | Trim context before the call; irrelevant text lowers accuracy |
Hostile input | Use it as an early screen for prompt injection, with real access controls behind it |
Writing anything | It can't; that work stays with an LLM |
The sharper criticisms are about positioning, not capability:
The no-hallucination claim is about format, not truth. As a Hacker News commenter pointed out, a schema guarantees the answer is one of your options, not that it is the right one.
The speed gap is partly apples to oranges. Every major LLM API already has a JSON mode, and a small fine-tuned classifier would also beat a reasoning model on latency.
It may be a well-trained wrapper. Some developers suspect a fine-tuned open-weight model read through its logprobs. Almeida has responded that TypeSafe's edge lies in the data used to train calibration rather than in the model design. Nothing is published either way.
Calibration is the core claim and the least tested. None of the sources reviewed shows an independent calibration study.
There is also the platform risk of a one-month-old, proprietary model from a seed-stage company. Access has already gone from waitlist to open to paused signups within a week.
What a CTO should do with this
Pilot it on one high-volume, low-stakes decision, keep the LLM as the fallback, and measure calibration yourself before trusting the confidence score.
The lasting idea is bigger than Jev: decisions and generation are different workloads. Even if TypeSafe stumbles, splitting "decide" from "write" in your architecture will pay off with whatever model fills the decision slot.
A two-week pilot that answers the real question:
Pick the workload. Choose a closed decision you already run through an LLM at volume: ticket routing, lead scoring, content tagging or a tool-call safety check.
Build a labelled set. Pull 500 to 1,000 past cases with known correct outcomes.
Run both models. Send the same cases to Jev and your current LLM. Record answer, latency and cost per call.
Check calibration. Bucket Jev's answers by confidence. Answers at 0.9 should be right about 90% of the time; if not, the threshold is meaningless.
Set a threshold. Choose the confidence above which Jev acts alone, and route everything below it to the LLM or a human.
Ship behind a flag. Keep data-handling in mind: for regulated data, confirm retention terms first (Vercel AI Gateway offers a zero-retention option).
If the calibration curve holds, you have a cheaper, faster first pass. If it does not, you have spent two weeks and learned exactly why.
Sources
Comments
No comments yet. Be the first to start the conversation.
