Imagine an AI that classifies a support ticket, scores a candidate answer, or routes a user intent in 114 milliseconds—at $0.000081 per call. No waiting for a paragraph of chain-of-thought. No parsing fragile JSON. No hallucinated fields. Just a typed decision with a probability and a calibrated confidence score.
That is what TypeSafe AI’s Jev promises. It runs 193.6× faster and costs 444.6× less than a comparable LLM on System One tasks—the high-volume, low-latency judgments that modern software makes millions of times a day. And it achieves this not by being a smaller or cheaper LLM, but by being something architecturally different.
This article explains what a System One model is, how Jev works under the hood, where it excels, and where you should still reach for a traditional LLM.
The Kahneman framing: System 1 vs System 2
Psychologist Daniel Kahneman described two modes of human thinking:
- System 1 is fast, intuitive, and automatic. You use it to read a stop sign, detect sarcasm, or decide whether an email looks like spam. It operates in milliseconds and requires no conscious effort.
- System 2 is slow, deliberate, and reflective. You use it to write an essay, solve a proof, or debug a race condition. It requires sustained attention and working memory.
Traditional LLMs—GPT, Claude, Gemini—are System 2 machines. They reason token by token, generating chains of thought before arriving at an answer. This makes them extraordinary at open-ended generation but enormously wasteful when all you need is a yes/no call or a 1-to-5 score.
Jev is designed to be a System 1 machine for software. It takes a structured input state and returns a typed decision—no reasoning chain required.
How Jev differs from LLM + structured output
A common pattern today is to prompt an LLM with a JSON schema and hope it complies:
response = llm.generate(
prompt="Classify this ticket: 'My GPU is on fire'",
schema={"category": str, "urgency": int, "confidence": float},
)The LLM still generates text token by token, then you parse and validate it. If the model hallucinates a field, wraps the JSON in prose, or produces an invalid enum value, your code breaks—or worse, silently accepts a wrong type.
Jev works differently. The decision space is defined before inference:
decision = jev.classify(
input=ticket_text,
choices=["billing", "hardware", "software", "other"],
)
# → {"choice": "hardware", "probability": 0.97, "confidence": 0.94}The model evaluates the predefined choices in parallel and returns a typed result. It can be wrong about which choice is correct, but it cannot produce a type error. There is no schema to hallucinate against—the schema is the architecture.
This is what “zero hallucination” means for Jev: zero schema hallucination, not zero mistakes. The distinction matters. Jev can misclassify a ticket. It cannot return {"categori": "billng"}.
Three output primitives
Jev exposes three primitive question types, each returning a decision plus probability and confidence:
| Primitive | Purpose | Returns | Example |
|---|---|---|---|
| Choice | Select from finite options | Selected option + probability + confidence | ”Is this search query well-formed?” → valid, 0.98, 0.95 |
| Score | Rate against an ordered rubric | Numeric score + probability + confidence | ”Rate this answer 1–5 for factual accuracy” → 4, 0.82, 0.88 |
| Noul | Judge a binary proposition | Float 0.0–1.0 | ”Is this claim grounded in the source document?” → 0.93 |
These primitives compose. A complex routing decision might decompose into three parallel Choice calls plus one Noul guardrail check—all resolved in a single round trip.
Under the hood: three architectural pillars
1. A new architecture, not a smaller LLM
TypeSafe AI is explicit: Jev is “neither small nor an LLM.” It uses a novel architecture designed from the ground up for decision-space evaluation rather than autoregressive text generation. This is not GPT with a constrained decoder bolted on—it is a different kind of model.
2. Parallel sampling over a decision space
Traditional LLMs generate one token at a time in sequence. To answer “is this spam?”, they must generate reasoning, then a verdict, then format it as JSON—each step depending on the previous.
Jev evaluates all branches of the predefined decision space in parallel in a single query. For a 4-choice classification, it doesn’t reason about choice A, then B, then C—it evaluates all four simultaneously and returns calibrated probabilities across them.
3. RLCD: Reinforcement Learning for Calibrated Decisions
Most modern models are tuned with RLHF (Reinforcement Learning from Human Feedback), which optimizes for human preference. RLHF produces models that sound confident and helpful—but often are overconfident. The model’s stated probability doesn’t match its actual accuracy rate.
Jev is trained with RLCD (Reinforcement Learning for Calibrated Decisions), which optimizes for calibration rather than preference. The goal is epistemic honesty: when Jev says 80% confidence, it should be right about 80% of the time across similar inputs. This matters enormously for production systems that branch on confidence thresholds.
Performance: the official numbers
TypeSafe AI publishes the following comparison for a System One task workflow:
| Metric | Jev | Comparable LLM | Ratio |
|---|---|---|---|
| Cost per call | $0.000081 | $0.013880 | 444.6× cheaper |
| Latency | 0.114 s | 8.566 s | 193.6× faster |
Input pricing is listed at $42 per billion tokens (approximately $0.042 per million)—which the company states is 238× lower than Claude Fable 5.1. Output tokens are free for Jev’s typed results.
Note that Jev AI’s own landing page uses a conservative range (40–200× speed, $0.042/M input tokens) derived from earlier benchmarks. The 193.6× / 444.6× figures are from TypeSafe AI’s latest published comparison as of September 2026.
Third-party validation: the LangChain experiment
Independent evidence matters more than vendor benchmarks. LangChain ran an experiment using Jev as an agent evaluator in LangSmith, comparing it against three LLM judges:
- Setup: Five weather-agent runs, each evaluated 100 times by four judges (Jev, GPT-5.6 Luna, GPT-5.6 Terra, Claude Sonnet 4.6) on a binary
does_passcriterion against a human oracle. - Jev result: 500/500 agreement with the human oracle (100% consistency across all 500 evaluations).
- Variance: Jev’s average per-case variance was 0.0000149. GPT-5.6 Luna’s was 433× higher, GPT-5.6 Terra’s was 913× higher, and Claude Sonnet 4.6’s was 92× higher.
- LLM agreement rates: Terra 99.8%, Luna 96.4%, Claude Sonnet 4.6 80.0%.
LangChain was careful to note this is an observational experiment on a narrow task—it does not prove that low variance is caused by RLCD training. But the result is striking: a System One model produced perfectly stable, perfectly accurate binary judgments on this task at a fraction of the cost and latency of any LLM judge.
This positions Jev as a third category of evaluator, alongside:
- Code-based evaluators: fast, deterministic, cheap—but limited to syntactic checks.
- LLM-as-judge: semantically flexible—but slow, expensive, and high-variance.
- System One evaluators (Jev): semantically aware and fast, stable, calibrated.
When to use Jev (and when not to)
Jev excels when you need fast, repeated, structured judgment:
- Intelligent branching: replace brittle if/else chains with semantic routing.
- Classification: tickets, logs, documents, intents, risk levels.
- Scoring: answer quality, relevance, safety, factuality.
- Guardrails: “Is this response grounded?” “Does this output violate policy?”
- LLM-as-judge replacement: stable, cheap evaluation at scale.
- Batch processing: millions of parallel decisions in map-reduce pipelines.
Jev is the wrong tool for:
- Long-form writing or code generation—it doesn’t generate free text.
- Complex mathematical derivation—it makes decisions, not proofs.
- Open-ended exploration—it needs a predefined decision space.
- Tasks requiring chain-of-thought reasoning—use a System 2 LLM for those.
The practical pattern is to use Jev for the fast decisions around LLM calls (routing, validation, evaluation) and reserve LLMs for the generative steps.
Production integration patterns
Teams adopting Jev should follow these practices:
- Define decision spaces carefully. The quality of Jev’s output depends on the quality of your choice/score definitions. Ambiguous categories produce ambiguous probabilities.
- Structure input state. Pass structured context (metadata, retrieved documents, conversation summary) rather than raw free-text prompts.
- Branch on confidence, not just the top choice. High confidence → auto-execute. Medium → conservative path or retry. Low → human review or LLM fallback.
- Monitor calibration curves. Track whether stated confidence matches actual accuracy over time. Watch for distribution drift as your data changes.
- Compose atomic questions. Complex decisions decompose into parallel Choice/Score/Noul calls, each with its own confidence.
- Keep an escalation path. For high-stakes decisions, route low-confidence cases to a human or a slower, more powerful LLM.
Background: TypeSafe AI
Jev is built by TypeSafe AI, founded by Diogo Almeida—publicly described as a co-inventor of ChatGPT. The company introduced Jev as its first public System One Model on September 15, 2026.
Try Jev
You can try Jev through the Jev API, available at half price via DefAPI: