Jev API is TypeSafe’s decision API for typed probabilistic decisions instead of open-ended text generation. Using Noul, Choice, and Score, it handles yes/no gates, agent and model routing, classification, scoring, and verification.
The problem is that many AI workflows still use full generative models for bounded decisions such as routing, classification, or verification, adding unnecessary generation cost and latency. Jev 1.13 is priced at $0.042 per million input tokens with free output, with a published 70–500 ms response range and 64K-token context window, making it specifically optimized for high-frequency decision workloads.
LinkModel complements Jev by handling the reasoning and generation layer through one OpenAI-compatible API, one API key, and unified billing. Teams can use Jev for lightweight decisions, then switch supported models by price, quality, speed, or availability without rebuilding integrations.
What Is the Jev API?
The Jev API is TypeSafe’s typed decision API for turning text or structured application state into bounded probabilistic decisions. Instead of generating open-ended answers, Jev returns structured signals for yes/no gates, routing, classification, scoring, and verification through its Noul, Choice, and Score primitives.
TypeSafe introduced Jev on September 15, 2026 as its first public System One Model, a model class designed around typed probabilistic decisions for software automation.
A Jev request has three core parts:
| Component | Purpose |
| State | Text, JSON, records, logs, or application state to evaluate |
| Model | The Jev model version handling the request |
| Questions | One or more typed decisions Jev should make |
The current API uses the /v1/systemone endpoint. Requests are authenticated with a TypeSafe API key, while the request body contains the state, model, and typed questions Jev should evaluate.
The stable model is currently jev-1.13.0, while jev-latest points to the latest available release.
Why Jev API Is Different From a Normal LLM API
A conventional LLM workflow often follows:
Prompt → generated answer → parse → validate → execute
Jev is closer to:
State → typed probabilities → business rules → execute
That difference matters in automated systems.
A support router does not need a paragraph explaining why a ticket belongs to billing. A model router does not need an essay about task difficulty. The application needs a bounded answer, uncertainty information, and a deterministic rule for what happens next.
Our review of user questions shows this is also the clearest way to understand Jev: it is not simply a smaller chatbot. Its interface is designed around deciding, classifying, routing, scoring, verifying, and gating.
Jev API Noul, Choice and Score Explained
Noul, Choice, and Score cover the three main forms of bounded software decisions: binary, categorical, and ordinal.
| Primitive | Decision type | Typical use |
| Noul | Yes or no | Risk gate, verification, eligibility |
| Choice | One option from a set | Agent routing, classification, model selection |
| Score | Position on ordered levels | Severity, quality, priority, frustration |
Noul: Jev API Yes/No Decisions
Noul answers a binary semantic question and returns the probability of yes from 0 to 1.
A workflow might ask whether a support request is urgent, whether retrieved evidence supports a claim, or whether a task needs escalation.
Noul works especially well as a gate:
Input → Noul decision → continue, reject, or escalate
Unlike Choice and Score, Noul does not return a separate confidence field. Its probability is the main decision signal.
Choice: Jev API Routing and Classification
Choice selects the most likely option from a predefined candidate set and returns probabilities across the available choices.
Typical uses include:
- Agent routing
- Model routing
- Department classification
- Tool selection
- Intent detection
- Workflow branching
Choice currently supports up to 255 options.
That limit creates an important production rule. If an application contains 100,000 products, tools, or documents, do not use Choice as the retrieval layer.
A stronger architecture is:
Large candidate pool → retrieval → shortlist → Jev Choice → execution
Retrieval finds plausible candidates. Jev makes the semantic decision among them.
Score: Jev API Ordered Judgments
Score evaluates state against 2–10 ordered levels and returns a probability-weighted result.
Instead of asking for an arbitrary risk number from 0 to 100, define levels with explicit meaning:
Low → Moderate → High → Critical
The result can fall between levels because it is calculated from the probability distribution.
This structure works well for risk, support priority, lead quality, severity, customer frustration, and other ordinal decisions because every level has a defined business meaning.
Jev API Pricing, Latency and Limits
Jev 1.13 combines $0.042/M input-token pricing and free output with a published 70–500 ms response range, a 64K context window, and documented throughput and rate limits. The table below summarizes the current Jev 1.13 specifications.
| Metric | Jev 1.13 |
| Input price | $0.042 / 1M tokens |
| Output price | Free |
| Published response time | 70–500 ms |
| Context | 64K tokens |
| State + longest question | 32K tokens |
| Rate limit | 1,200 requests/min |
| Throughput | 250,000 tokens/sec |
| Choice options | Up to 255 |
| Score levels | 2–10 |
| Input modality | Text |
These economics become more important as decision volume grows.
If an application makes one classification per hour, the architecture may not matter much. If an agent platform makes hundreds of thousands of routes, verification checks, or gates, the decision layer becomes part of the product’s cost and latency profile.
How Much Does Jev API Cost?
Jev 1.13 costs $0.042 per million input tokens, while output tokens are free. Because Jev returns probabilities, routes, and scores rather than generated text, request cost is driven primarily by the amount of state and question context sent as input.
How Fast Is the Jev API?
TypeSafe currently publishes a Jev 1.13 response-time range of 70–500 ms. Real end-to-end latency varies by request size, network conditions, workload structure, and whether multiple questions are evaluated together.
What Are the Jev API Limits?
Jev 1.13 supports a 64K-token total context window, with State plus the longest question limited to 32K tokens. Current documented limits also include 1,200 requests per minute, 250,000 tokens per second, up to 255 Choice options, and 2–10 Score levels.
Jev 1.12 Parallel Questions Benchmark: 12.2× Cheaper With Shared Context
Jev can evaluate multiple independent questions against the same shared state, avoiding repeated transmission of large context.
In TypeSafe’s parallel-questions cookbook, run with Jev 1.12, 13 questions were evaluated against a 53,777-character GDPR document.
One batched request:
Cost: $0.000497 Time: 0.27 seconds
Thirteen separate sequential requests:
Cost: $0.006090 Total time: 2.71 seconds
For this workload, batching was 12.2× cheaper and 10.0× faster.
The latency comparison sums sequential calls, so concurrent requests would reduce the wall-clock gap. The cost advantage remains more relevant because separate calls repeatedly send the same large document.
The practical lesson is straightforward:
When several decisions depend on the same context, send that context once and evaluate the questions together.
Jev API Use Cases and Observed Workflow Results
Jev is most compelling in workflows where a small semantic decision is repeated frequently and sits directly in front of another model, agent, or software action. Our research found the clearest early evidence in routing, coding decisions, local-model comparisons, and agent workflows.
Observed Agent Routing: Jev at ~1 Second vs 4–14 Seconds
In one independently reported agent-routing experiment, Jev returned routing decisions in roughly 1 second, compared with 4–14 seconds for a regular LLM using structured output.
The reported routing time was approximately:
Jev: about 1 second Structured-output LLM: about 4–14 seconds
This matters because routing happens before the actual task begins.
If a model-selection layer itself takes 10 seconds, it can erase much of the benefit gained by sending the task to a faster downstream model.
A clean architecture is:
Task → Jev Choice → selected agent or fallback → execution
For multi-agent products, routing is one of the clearest Jev API use cases because the decision is small but can occur on every request.
Observed Coding Decision Workflow: 239–430 ms
In a separate reported coding workflow reviewed in our research, Jev was used for repeated decision gates.
Reported calls took 239–430 ms, with estimated costs of $0.000013–$0.000027 per decision.
One recorded request contained 312 input tokens and 35 output tokens, with an estimated cost of about $0.0000131.
At this specific observed workload size, the estimated cost would be approximately $13–$27 per million decisions. This is not Jev’s standard cost per decision; actual cost depends on the input context sent with each request.
Local Qwen vs Jev: 144-Task Comparison
A separate 144-task typed-decision benchmark reviewed in our research compared hosted Jev with a local Qwen-based stack.
Reported accuracy:
Jev: 96.53% Local Qwen: 96.53%
Reported median latency:
Jev hosted: 368 ms Local Qwen: 239 ms
This single benchmark does not establish equal general capability.
It does show that Jev-style typed decision workflows can also be built with local models, which changes the buying decision.
Teams evaluating the two approaches should consider:
- Accuracy on their own workload
- Confidence calibration
- Privacy requirements
- Infrastructure cost
- Operational complexity
- Latency
- Maintenance burden
For production teams, those factors are more useful than treating one small benchmark as a universal model ranking.
Claude Decision Workflow: Trigger Accuracy Was Not Decision Accuracy
A Claude Code decision workflow reviewed in our research reveals another important production lesson.
The decision skill triggered in 9 of 10 cases where it should have activated, while 0 of 10 near-miss cases produced a false trigger.
At first, that looks strong.
However, when the first three real decision questions were examined, one was noisy and most of the resulting decisions were wrong.
This exposes a critical distinction:
Correctly triggering the decision layer is not the same as making the correct decision.
A serious production evaluation should therefore measure four stages separately:
Trigger → decision accuracy → confidence calibration → downstream outcome
Otherwise, a workflow can look reliable at the integration layer while still producing poor business results.
What Does Jev Confidence Mean? Is 0.90 Confidence 90% Accurate?
No. A Jev confidence value of 0.90 does not automatically mean the decision is 90% likely to be correct. For Choice and Score, confidence describes how concentrated the returned probability distribution is. Whether that confidence corresponds to real-world accuracy must be measured with labeled examples from the target workload.
A Choice where one candidate dominates the probability distribution will have higher confidence than one where several candidates are close.
A useful production pattern is:
| Confidence state | Typical action |
| High | Auto-execute when the consequence is acceptable |
| Medium | Verify, confirm, or send for review |
| Low | Reject, fall back, or escalate |
The production question is therefore not whether confidence looks high, but whether that confidence is calibrated on the target workload.
A stronger process is to create a labeled evaluation set, group predictions by confidence range, measure error rates, and then decide how much automation is acceptable at each threshold.
The business context matters.
A wrong UI route is easily reversed. A wrong financial approval is not.
Confidence thresholds should therefore reflect business risk, not simply model output.
Jev API Limitations and Production Best Practices
The largest Jev production risks are incorrect semantic decisions, weak candidate design, poor calibration, and using a decision model where deterministic code would be safer.
Typed output does not mean the answer is automatically correct. Jev can return a valid Choice that is still the wrong Choice.
Candidate design is especially important. If a router includes only Agent A, Agent B, and Agent C, Jev must choose among them even when none is suitable.
Production schemas should often include escape routes such as:
- Human
- None
- Insufficient evidence
- No suitable option
- Escalate
Jev 1.13 is currently text-only. English is its strongest language. CJK input can be processed, but equal accuracy is not guaranteed, so Chinese, Japanese, and other non-English production workloads need their own labeled benchmarks.
Deterministic operations should also remain deterministic. Arithmetic, date calculation, strict identities, policy constraints, and hard business rules belong in code, not in a probabilistic decision layer.
Finally, production teams should consider pinning jev-1.13.0 after calibration rather than relying indefinitely on jev-latest. A future alias update may preserve the response format while changing probabilities enough to affect routing or threshold behavior.
Jev API vs LLM: When Should You Use Each?
Decision models such as Jev are designed for bounded semantic decisions, while general LLMs remain better suited to open-ended generation, reasoning, planning, and candidate creation. Deterministic calculations and hard business constraints should remain in code.
| Task | Typical best-fit layer |
| Bounded semantic classification | Jev or another decision model |
| Agent routing | Jev or another decision model |
| Risk gating | Jev or deterministic rules, depending on the constraint |
| Ordered semantic scoring | Jev or another decision model |
| Semantic verification | Jev / decision model |
| Writing | General LLM |
| Deep reasoning | General LLM |
| Planning | General LLM |
| Candidate generation | General LLM |
| Deterministic calculation | Code |
A useful production architecture is:
LLM proposes → Jev decides → code executes
TypeSafe has reported selected workflow evaluations reaching 193.6× faster and 444.6× cheaper, but says these results likely represent the higher end of real-world gains rather than typical Jev performance. TypeSafe also notes that the evaluated workflows were created by members of its own model-capabilities team, so some evaluation bias may remain.
The more useful conclusion is broader:
Decision-shaped workloads can have fundamentally different latency and cost requirements from generation-shaped workloads.
Production teams should benchmark that architectural difference on their own tasks rather than assume one vendor multiplier applies everywhere.
Frequently Asked Questions
How much does Jev API cost?
Jev 1.13 currently costs $0.042 per million input tokens, while output tokens are free. The real cost per decision depends primarily on how much state and question context each request contains.
Is Jev an LLM?
Jev is positioned by TypeSafe as a System One Model, not a conventional chat LLM. It accepts text or structured state but is designed to return typed probabilistic decisions rather than open-ended generated responses.
Can Jev return the wrong decision?
Yes. Jev can return a structurally valid typed decision that is still semantically wrong. Type constraints prevent malformed or unsupported output shapes, but poor context, ambiguous questions, weak candidate design, or model error can still produce an incorrect decision.
What does Jev confidence mean?
Jev confidence describes how concentrated a Choice or Score probability distribution is. It is not automatically equivalent to accuracy. Production thresholds should be calibrated against labeled examples from the actual workload.
Can Jev replace GPT or Claude?
Not for general-purpose generation or deep reasoning. A more useful architecture is GPT or Claude for reasoning and candidate generation, Jev for routing, classification, scoring, or gating, and deterministic code for execution.
Conclusion
Jev API is best suited to workflows that repeatedly need a bounded semantic decision rather than another generated response. Noul, Choice, and Score make it useful for yes/no gates, routing, classification, verification, and ordered scoring, particularly when decision latency and repeated LLM costs matter.
he strongest production pattern is not “Jev instead of LLMs,” but separation of responsibilities: LLMs generate and reason, Jev makes bounded semantic decisions, and deterministic code enforces hard rules and executes actions. Teams should validate accuracy and confidence thresholds on their own workloads before automating high-impact decisions.
