What Is the Jev Model?
Jev turns text or JSON state into typed choices, scores, and probabilities. It is built for decisions inside software, not chat or free-form generation.
The Jev model is TypeSafe AI's first System One Model: an AI model designed to make narrow, structured judgments that software can consume directly. Instead of writing a paragraph, Jev receives a text or JSON state, evaluates one or more typed questions, and returns choices, scores, probabilities, and confidence values.
That makes Jev interesting for classification, routing, ranking, verification, and guardrails. It does not make Jev a replacement for a chat model, coding model, calculator, or deterministic business rule.
Fact-checked September 19, 2026. Jev launched in early access on September 15. The current documented model is jev-1.13.0. Prices, limits, latency, and capability claims below come from TypeSafe's own release post and documentation. We did not receive a private briefing, run a billable Jev benchmark, or independently reproduce TypeSafe's speed and quality claims.
Jev model at a glance
| Item | Current documented value |
|---|---|
| Developer | TypeSafe AI |
| Model class | System One Model |
| Current versioned ID | jev-1.13.0 |
| Stable alias | jev-latest |
| Endpoint | POST https://api.typesafe.ai/v1/systemone |
| Input | Text only, supplied as a string, JSON object, or array of text values |
| Output | Typed Choice, Score, and Noul answers |
| Context | 64K tokens per request; 32K for state plus the longest question |
| Direct API price | $0.042 per 1M input tokens; output is currently free |
| Published default limits | 250,000 input tokens/s and 1,200 requests/minute; subject to change |
| Vendor latency claim | 70–500 ms end to end |
| Release status | Early access |
The official spelling is Jev, not an acronym written out as J-E-V. TypeSafe says it named the model after economist William Stanley Jevons. The “System One” label draws on the fast, intuitive System 1 described in Daniel Kahneman's Thinking, Fast and Slow.
What does Jev actually do?
Think of Jev as a probabilistic semantic function:
unstructured or structured state
+ predefined questions and answer spaces
-> typed decisions and probability distributions
An ordinary LLM is optimized to continue a sequence and generate strings. Even with JSON mode, your application still asks a generative model to compose an answer. Jev gives up free-form generation. The caller defines the available output shape first, and the model evaluates every question against the same state.
TypeSafe describes its training method as Reinforcement Learning for Calibrated Decisions (RLCD). Its objective is not merely to select an answer, but to produce probabilities whose confidence tracks accuracy across groups of predictions. Calibration is statistical: a probability of 0.8 should correspond to roughly 80% accuracy across comparable cases. It does not guarantee that one specific answer is correct.
Choice, Score, and Noul
Jev exposes three question types. They are the core of the API, not formatting options added after generation.
| Primitive | Question shape | Returned value | Good fit |
|---|---|---|---|
Choice | Which option fits? | Selected option, probability for every option, confidence | Intent routing, classification, ranking a closed set |
Score | Where does this fall on a described scale? | Weighted score, level probabilities, confidence | Severity, quality, urgency, risk bands |
Noul | Is this statement true? | Probability from 0 to 1 | Detection, verification, binary gates |
A Choice can contain up to 255 options. A Score accepts 2 to 10 descriptive levels. Noul has no separate confidence field because its 0-to-1 value is already the probability of “yes.”
Multiple questions in one request are evaluated independently and in parallel against the same state. That is useful when a workflow needs several signals, but it also means one answer does not automatically condition another. If question B depends on question A, your code should make that dependency explicit.
A Jev API request
This shortened example follows TypeSafe's documented request shape. One support message is evaluated for routing, frustration, and urgency in a single call.
curl https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "My payouts have failed for three days and I am losing sales. Please help now.",
"model": "jev-latest",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, invoices, or refunds",
"technical": "Bugs, outages, or integrations",
"sales": "Pricing, upgrades, or new accounts"
}
},
"frustration": {
"type": "score",
"instructions": "How frustrated is the customer?",
"criteria": ["Calm", "Frustrated", "Very angry"]
},
"is_urgent": {
"type": "noul",
"instructions": "Does this message convey urgency?"
}
}
}'
The response keeps the same question IDs. department returns one of the three allowed strings plus a distribution across all three. frustration can be fractional because it is the probability-weighted position across the supplied levels. is_urgent returns only the probability of yes.
The exact values will vary with the input, criteria, and model version. Your code, not the model, decides what probability is high enough to act on.
Jev versus an LLM and a classifier
Jev occupies a useful middle ground, but the differences matter.
| Dimension | Jev | Generative LLM | Traditional classifier |
|---|---|---|---|
| Primary job | Make bounded semantic judgments | Generate or reason in free-form text | Predict labels learned for one fixed task |
| Output space | Defined per request | Open-ended, even when constrained by a schema | Fixed by training |
| New rubric | Describe it in the request | Prompt or tool schema | Usually collect data and retrain |
| Probabilities | First-class API output | Often unavailable or poorly calibrated | Common, if the model exposes them |
| Text generation | No | Yes | No |
| Best role | Semantic branch inside a workflow | Creation, explanation, coding, multi-step reasoning | Stable high-volume task with labeled data |
Calling Jev “just a classifier” misses its request-time flexibility. Calling it “a faster LLM” misses that it cannot generate an explanation, draft an email, write code, or invent a new answer outside the options you supplied.
JSON mode is also not the same contract. JSON mode constrains the syntax of generated text. Jev constrains the answer space itself and returns the full distribution used for the decision. That is valuable, but only when the problem can be expressed as bounded questions.
Price, context, and throughput
TypeSafe currently lists Jev 1.13 at $0.042 per million input tokens, or $42 per billion. Output is free “too cheap to meter,” although responses still report output-token usage.
| Input volume | Direct Jev input cost |
|---|---|
| 10,000 tokens | $0.00042 |
| 1 million tokens | $0.042 |
| 100 million tokens | $4.20 |
| 1 billion tokens | $42.00 |
These are arithmetic examples, not invoice measurements. They exclude retries, preprocessing, another model in a cascade, storage, engineering work, and any future pricing changes.
The context contract has two simultaneous limits: all state and questions together must fit within 64K tokens, while the state plus the single longest question must fit within 32K. More context is not automatically better. TypeSafe's own jaggedness guide says irrelevant detail causes accuracy to fall.
The published 250,000 tokens/s and 1,200 requests/minute limits are account limits, not a per-request speed promise. TypeSafe explicitly warns that they are changing dynamically during early access.
How strong is the speed claim?
TypeSafe reports 70–500 ms end-to-end response time and says Jev can be 40–200x faster than frontier models on “System One shaped” queries at comparable intelligence. Its launch materials also highlight a workflow evaluation where Jev was 193.6x faster and 444.6x cheaper.
Those numbers are vendor results, not a neutral benchmark. TypeSafe discloses several important caveats:
- The published latency runs were generally made from company laptops on the US West Coast, where the service was based.
- The workflow tasks were made by TypeSafe's model-capabilities team, so selection bias may exist.
- The reference answer averaged GPT-6 Astra and Fable 5.1, which can favor those model families.
- Competing LLM calls came through OpenRouter and TypeSafe's structured wrapper.
- TypeSafe calls the 193.6x and 444.6x results the high end of expected real-world gains.
The right conclusion is narrower: Jev's constrained output and parallel evaluation create a credible path to very low latency and cost for bounded decisions. They do not prove that Jev is 40–200x faster on every task, equal to a frontier LLM in general intelligence, or better at work that requires generation and multi-step reasoning.
“Zero hallucinations” needs a precise definition
TypeSafe markets Jev as unable to hallucinate. The defensible part is schema safety: a Choice answer cannot invent a fourth option, and the service should not return prose where your code expects a number. TypeSafe says this output matching is guaranteed by construction rather than measured empirically.
But a type-correct answer can still be semantically wrong. TypeSafe's own Jev 1.13 documentation lists failures involving:
- literal readings and missed implied intent;
- unreliable counting, arithmetic, dates, and numeric precision;
- multi-hop indirection;
- long state containing irrelevant detail;
- adversarial or prompt-injected content;
- contradictory instructions and criteria;
- probabilities that do not obey intuitive identities across separately phrased questions;
- any task that requires text generation.
So the practical claim is zero out-of-schema generation, not zero decision error. Production code still needs evaluation data, conservative thresholds, deterministic validation, and an escalation path.
Where Jev fits well
Jev is a strong candidate when all three conditions hold: the answer space is bounded, the judgment is semantic rather than mathematical, and another piece of software will consume the result.
| Workload | Why Jev may fit | Important guardrail |
|---|---|---|
| Support-ticket routing | Closed set of teams and useful uncertainty signal | Include other; review low confidence |
| RAG passage filtering | Score relevance, contradiction, or injection risk | Keep source verification outside the model |
| LLM input/output guardrails | Many narrow checks can run in one request | Treat adversarial input as a tested threat model |
| Entity matching | Score whether two records refer to the same thing | Let code enforce exact IDs and invariants |
| Content moderation | Bounded labels and severity levels | Tune thresholds per harm category |
| Agent action routing | Choose a tool or decide whether a skill applies | Keep permissions and destructive-action checks in code |
It is a poor default for writing, summarization, code generation, open-ended extraction, exact arithmetic, date comparison, or long causal reasoning. Use normal code for exact logic and a generative or reasoning model when the output itself must be created.
A production checklist
- Keep deterministic work in code. Parse dates, count items, calculate money, and enforce permissions without a model.
- Ask atomic questions. Split “Should we approve this request?” into the independent facts that decision actually depends on.
- Describe every boundary. Add
otherornonewhen a Choice is not exhaustive, and write concrete Score levels. - Test on your own distribution. English is the primary training language; TypeSafe says other languages, including CJK scripts, are not equally accurate.
- Calibrate actions, not just predictions. Use different confidence thresholds for reversible UI routing and high-impact automation.
- Pin a version after tuning.
jev-latestcan move. Log the versioned response ID and migrate thresholds deliberately. - Escalate uncertainty. Route ambiguous cases to a person or a slower reasoning model instead of forcing a decision.
- Measure accepted-task cost. Include retries, false decisions, human review, and downstream LLM calls, not only token price.
Is Jev available through OmniaKey?
Not at the fact-check date. We found no Jev route in OmniaKey's current catalog or codebase. The endpoint and prices in this article belong to TypeSafe's direct API, and publishing this guide does not announce an OmniaKey integration.
Check the live OmniaKey model catalog for actual gateway availability. For open-ended coding and agent work, the coding-agent model guide covers the generative models that fit a different part of the stack.
Final verdict
Jev is best understood as a new interface for semantic decisions, not as a universal replacement for an LLM. Its most compelling idea is simple: let a model handle fuzzy judgment, force the output into a type your program understands, expose uncertainty, and keep composition and exact logic in code.
The current API is unusually inexpensive on paper, and the architecture is designed for low latency. The model is also in early access, text-only, strongest in English, and openly documented as weak on math, dates, indirection, irrelevant context, and adversarial input. Treat the speed and intelligence comparisons as vendor evidence until matched independent tests exist.
Frequently asked questions
Is Jev an LLM?
TypeSafe calls Jev a System One Model rather than an LLM. It understands natural-language state, but it does not generate free-form text. TypeSafe has not disclosed enough architecture detail in the sources reviewed here to independently settle how closely its underlying network resembles a conventional language model.
Can Jev replace GPT or Claude?
No. Jev cannot write, explain, code, or perform open-ended generation. It can complement a generative model by routing requests, checking outputs, scoring evidence, or deciding when a slower model should run.
What do Choice, Score, and Noul mean?
Choice selects from a closed set and returns all option probabilities. Score places the state across 2–10 described levels. Noul returns the probability that a yes/no statement is true.
Does Jev really have zero hallucinations?
It cannot generate a value outside the declared answer type, which eliminates a major class of parsing and schema failures. It can still choose the wrong valid option or assign a misleading probability. Type safety is not semantic correctness.
How much does the Jev API cost?
TypeSafe lists Jev 1.13 at $0.042 per million input tokens, with output currently free. Direct prices and rate limits can change during early access.
Does Jev support images or Chinese?
It is text-only. Strings, JSON objects, and arrays must ultimately contain text. Chinese and other CJK scripts are accepted, but TypeSafe says English is currently strongest and tells developers to test non-English workloads on their own data.
Primary sources
- TypeSafe: Introducing System One Models & Jev
- TypeSafe documentation: Introduction
- TypeSafe documentation: System One
- TypeSafe documentation: Models and pricing
- TypeSafe documentation: HTTP API reference
- TypeSafe documentation: Confidence
- TypeSafe documentation: Jev 1.13 jaggedness
Evidence was checked on September 19, 2026. Jev is changing quickly during early access; recheck the versioned model ID, price, limits, language behavior, and data terms before production use.