Jev is TypeSafe AI’s first System One model, designed for applications that need structured decisions rather than generated prose. It evaluates supplied information against clearly defined questions and returns typed answers, probability distributions, and, where applicable, confidence scores.
Unlike a conventional large language model, Jev is not intended to chat, write code, or create long-form content. Its purpose is to make bounded judgments that software can immediately use for classification, routing, scoring, verification, prioritization, and workflow control.
Model information was reviewed on September 21, 2026.
Jev Technical Specifications
| Specification | Details |
|---|---|
| Developer | TypeSafe AI |
| Model family | System One |
| Current stable version | Jev 1.13 |
| Versioned model ID | jev-1.13.0 |
| Stable alias | jev-latest |
| Input | Text, JSON objects, or arrays of text values |
| Output | Typed decisions and probability distributions |
| Question types | Choice, Score, and Noul |
| Context limit | 64,000 tokens per request |
| Additional context constraint | 32,000 tokens for the state plus the longest question |
| Published input price | $0.042 per million tokens |
| Published output price | Free |
| Published rate limits | 250,000 tokens per second and 1,200 requests per minute |
| Primary language | English |
| Direct multimodal input | Not supported |
Pricing, aliases, and rate limits may change. Developers should verify the latest information before moving a workload into production.
What Is Jev?
Jev is a decision model developed by TypeSafe AI. Instead of generating a sequence of open-ended tokens, it selects values from answer spaces defined by the developer.
A Jev request contains two main components:
- State: The information that the model should evaluate, such as a support ticket, transaction record, agent trace, product description, or JSON-formatted application state.
- Questions: Typed definitions of the judgments that should be made about that state.
The resulting answers are intended for direct use by software. An application can branch on a selected category, compare scores, inspect probabilities, apply a confidence threshold, or send an uncertain case to a human reviewer.
Jev therefore acts as a probabilistic decision layer between application data and deterministic business logic. It handles judgments that are difficult to express through fixed rules while allowing application code to retain control over thresholds, permissions, and actions.
How Does Jev Work
Three Decision Primitives
Jev supports three question types designed for different kinds of software decisions.
Choice selects one option from a predefined set. It is suitable for tasks such as intent classification, ticket routing, policy categorization, and model selection. The response includes the selected option, the probability assigned to each option, and a confidence score.
Score evaluates the state against an ordered rubric. It can measure qualities such as urgency, risk, relevance, frustration, or content quality. The response includes a score, probabilities for each rubric level, and a confidence score.
Noul estimates the probability that a statement is true. It returns a value between 0 and 1 and is useful for verification, policy checks, eligibility decisions, and completion gates. Unlike Choice and Score, Noul does not return a separate confidence field because its output is already a probability.
Parallel Question Evaluation
A single request can contain multiple Choice, Score, and Noul questions. Jev evaluates them independently and in parallel against the same state.
For example, a support platform can classify a ticket, assess its urgency, and estimate whether human escalation is needed in one request. TypeSafe states that adding independent questions has little effect on response time.
Questions within the same request cannot depend on one another’s answers. Sequential decisions should be implemented through separate calls connected by application logic.
Type-Safe Responses
Jev’s possible response structures are defined before inference. This prevents malformed JSON, unexpected fields, and explanatory text from appearing where a category or numeric value is required.
Type safety only guarantees the response format. Jev can still return a valid but incorrect decision, so production teams must evaluate its accuracy using representative data.
Explicit Probability and Confidence
Choice and Score expose the probability distribution behind each answer. Their confidence value summarizes how strongly that distribution favors one outcome.
Applications can use confidence to automate clear decisions, request confirmation when uncertainty is moderate, and route ambiguous cases to a human or fallback model.
The appropriate threshold depends on risk. Tagging a support ticket can tolerate more uncertainty than approving a transaction or executing an irreversible action.
Low-Latency Inference
TypeSafe reports end-to-end response times of approximately 70 to 500 milliseconds. This makes Jev suitable for interactive routing, repeated agent checks, and other decision-heavy workflows where a slower generative-model call could affect responsiveness.
Actual latency depends on state size, service load, network conditions, and deployment region.
Request-Level Customization
Jev is not customized through account-specific fine-tuning or LoRA adapters. Developers adapt it by supplying relevant state, writing precise instructions, defining clear criteria, and combining atomic decisions in application code.
This approach keeps business rules visible and allows teams to change workflow logic without retraining the model.
Versioned Models and Stable Aliases
TypeSafe provides fixed model IDs and moving aliases. jev-1.13.0 identifies a specific release, while jev-latest points to the latest stable version. jev-preview may move to a newer preview release when one is available.
Aliases simplify experimentation, but their behavior can change after an update. Production applications with calibrated thresholds should pin a tested version and record the model ID returned with every response.
Benchmark Performance of Jev
Jev is not designed for general-purpose benchmarks focused on writing, coding, mathematical derivations, or long-form reasoning. More relevant measurements include decision quality, probability calibration, latency, cost, and output reliability.
TypeSafe reports:
- End-to-end response times of 70–500 milliseconds
- Approximately 40–200× faster execution on comparable System One tasks
- Peak workflow results of 193.6× higher speed
- Peak reported cost improvements of 444.6×
These are vendor-reported results and should not be treated as universal performance guarantees. TypeSafe’s workflow evaluations compare models on structured decision graphs and use the averaged predictions of selected high-end external models as reference probabilities.
TypeSafe also acknowledges that members of its model-capabilities team created the evaluated workflows, which may introduce bias. The reported gains are likely closer to the upper end of what applications may observe.
Jev vs Structured-output LLM vs Classical Classifier vs Rules Engine
| Dimension | Jev | Structured-output LLM | Classical classifier | Rules engine |
|---|---|---|---|---|
| Primary function | Bounded probabilistic decisions | Generation with a structured response | Prediction for a trained task | Deterministic logic |
| Answer space | Defined in each request | Constrained through a schema | Fixed during training | Fixed in code |
| Uncertainty | Native probabilities and confidence | Depends on the model and method | Often available but may require calibration | Not probabilistic by default |
| Output structure | Guaranteed for supported primitives | Usually requires constrained generation and validation | Fixed by implementation | Fixed by implementation |
| New-task setup | Define state, questions, and criteria | Create a prompt and schema | Collect labeled data and train a model | Write explicit conditions |
| Open-ended generation | No | Yes | No | No |
| Extended reasoning | Not its target workload | Supported by capable models | No | Limited to encoded logic |
| Adaptation | Request-level instructions and criteria | Prompt and context changes | Retraining or feature engineering | Code changes |
| Best fit | High-volume judgment inside software | Tasks combining reasoning and generation | Stable, narrow, data-rich predictions | Explicit and stable conditions |
Jev is most useful when fixed rules are too brittle, creating a dedicated classifier would be expensive, and the application does not need generated text.
A traditional LLM remains the better choice when a task requires research, explanation, content creation, planning, or multi-step reasoning. A rules engine remains preferable when the correct condition is already explicit and deterministic.
Recommended Use Cases
Jev is best suited to frequent decisions with a predefined answer space.
- Routing and triage: Classify requests, select queues or tools, and prioritize urgent cases.
- Agent control: Check task completion, evaluate proposed actions, and identify cases that require confirmation.
- LLM evaluation: Assess relevance, evidence support, policy compliance, or response quality.
- Moderation: Categorize policy violations, score severity, and escalate uncertain cases.
- Data enrichment: Convert messages, reviews, leads, and records into categories, scores, and probability features.
- Real-time decisions: Support low-latency application behavior where a full generative response is unnecessary.
Limitations of Jev
Jev is intentionally specialized, and its narrow design creates several important limitations.
- It cannot generate prose, code, summaries, or conversational answers.
- It is not intended for extended research or multi-step reasoning.
- Type-safe output does not guarantee a correct business decision.
- Images, audio, video, and binary files must be converted into text or structured data before submission.
- English is the strongest documented language.
- Non-English and CJK workloads require independent evaluation.
- Questions within one request are evaluated independently.
- The model cannot construct a sequential reasoning chain across those questions.
- TypeSafe has not disclosed the model’s parameter count or released its weights.
- Customization is performed through the request rather than customer-specific fine-tuning.
- Published performance gains come from TypeSafe’s own evaluation framework.
- Moving aliases may introduce behavioral changes without an application-code change.
Jev should not replace deterministic code for permissions, financial calculations, legal requirements, file-size limits, or irreversible-action policies. Probabilistic models are useful for uncertain judgments, not for conditions that software can already evaluate exactly.
How Does CometAPI Provide Access to the Jev API?
Jev is not currently available in CometAPI’s public model catalog. CometAPI plans to evaluate and integrate Jev once model access becomes available and the required connection permissions are opened.
After integration, developers will be able to check the CometAPI model directory and API documentation for the supported model ID, request format, pricing, rate limits, and endpoint availability.
Until the integration is officially announced, developers should use TypeSafe’s console, native API, or official SDKs to access Jev. A CometAPI integration should only be considered available after Jev appears in the public model catalog with verified API information.