Jev: TypeSafe’s new AI model for decisions inside software
Consider a support message: “You charged me twice. Please refund the extra payment before my next renewal.”
Before someone writes a reply, software has a few things to work out. Which queue should receive the ticket? Is the customer asking for a refund? Does the account history support the complaint? Some of that work belongs in ordinary code. Some requires interpreting what the customer means.
Jev handles that second part. TypeSafe introduced it in early access on September 15, 2026, as its first “System One” model. You give it context and questions with defined answer spaces. It returns structured decisions and probabilities that an application can use directly. It does not write the customer’s reply. [1] [2]
Jev costs $42 per billion input tokens, with no charge for outputs. Whether that translates into useful savings depends on the decisions you need it to make and how often it gets them right. [3] [4]
What you send, and what comes back
A Jev request has a state and a set of questions. The state is the material to evaluate: a message, a JSON object containing customer records, or an array of related text. Questions specify the judgments you want. Keeping those separate lets you reuse a question across different records without hiding the task inside a long conversation. The API has three question types. [5] [2]
Choice selects one option from a list you define. For a support system, that might be billing, technical, account, or other. The answer includes the selected option, the probability assigned to every option, and a confidence value. Choice supports up to 255 options. The documentation recommends an escape option such as other when your categories might not cover every input. [6]
Score places the input along an ordered rubric containing two to ten descriptive levels. You might define bug severity as cosmetic, impaired functionality with a workaround, or blocked functionality without a workaround. Jev returns a probability distribution across those levels and their probability-weighted average. A three-level rubric is numbered from 0 to 2, so a score of 1.3 is possible. It is a position on your rubric, not automatically a percentage. [7]
Noul answers a yes-or-no question with a number between 0 and 1. For “Is the customer requesting a refund?”, a value near 1 indicates a strong yes. A value near 0.5 means the model gives yes and no similar probability; it does not mean the customer wants half a refund. Noul has no separate confidence field. [8]
What the pricing chart tells you
Prices per million tokens in USD. The supplied chart matches the providers’ listed base rates checked on September 18, 2026; its OpenAI figures use standard short-context pricing. GPT-5.6 Sol’s rate is promotional. Caching, batch discounts, and other pricing tiers are not shown. [4] [9] [10]
At Jev’s published rate, one million requests averaging 2,000 billed input tokens each would cost $84 in model input charges. That is an illustrative calculation, not a measured workload. Your token count must include the questions and criteria as well as the state. [3] [6] [4]
Paying to classify a message is different from paying a model to reason through a complicated case and compose an answer. The chart does not establish that Jev can replace every model above it. It does show why a cheap classifier is worth evaluating when a label or probability is the entire output you need.
For a production comparison, I would count the cost of getting a usable decision. A cheap call that needs a second model or a human to repair it may save less than the token prices suggest. The same applies to retries and the work required to investigate mistakes.
How this differs from asking an LLM for JSON
Existing language models can already produce schema-constrained output. OpenAI’s Structured Outputs, for example, enforces supported JSON schemas. Comparing Jev only with a chatbot that ignores a request for JSON would understate what developers can already build. [11]
TypeSafe gives the model a narrower job. Jev evaluates constrained decisions without generating open-ended prose or a written reasoning trace. The company describes a specialized architecture and parallel sampler, alongside a training method called Reinforcement Learning for Calibrated Decisions, or RLCD. Its training objective includes making the returned probabilities useful as estimates of uncertainty. [12] [1] [13]
The difference matters most when an application needs several judgments about the same input. Jev evaluates questions independently, in parallel, against shared state. TypeSafe says adding questions usually has little effect on latency, although the extra questions still consume input tokens. [2] [14]
In a bug-report workflow, you could ask which department should handle the message and how severe the reported bug is in the same call. If the message turns out to be about billing, your code ignores the bug-severity answer. The fan-out pattern avoids waiting for one classification before requesting another judgment that could have been made from the original input. [14]
A genuine dependency still needs orchestration. When a later question requires information obtained after the first decision, your application has to collect that information and make another request. Parallel questions are useful when they can all be answered from the state already available. [5] [15]
Using confidence in a workflow
RLCD’s calibration goal is straightforward: among many outcomes assigned a probability of 0.8, roughly 80 percent should occur. That describes a collection of predictions. It does not certify any particular answer, and a training objective alone does not establish calibration on your company’s data. [13]
The outcome’s probability is separate from the confidence field returned by Choice and Score. TypeSafe derives confidence from the shape of the probability distribution. A distribution concentrated on one answer produces higher confidence than one spread across several answers. Treating confidence: 0.9 as a guaranteed 90 percent chance of correctness would skip the validation that the application still needs. [16]
For support triage, a wrong queue assignment may be easy to reverse. Issuing a refund has different consequences. I would use those consequences to decide how much evidence is required before acting, then test the thresholds against reviewed examples. TypeSafe’s own guidance recommends checking confidence against accuracy on your data and escalating uncertain cases. [15]
It also helps to keep the full distributions in your evaluation records. Two versions of a workflow can produce the same final label while differing substantially in how uncertain they were about it. That distinction disappears if you save only the winning category. [16]
A small integration example
TypeSafe provides Python and JavaScript SDKs, plus an HTTP endpoint at POST /v1/systemone. Authentication uses an API key. The Python client can read it from TYPESAFE_API_KEY. [17] [18] [19]
The following example asks two questions about one message. It follows the documented Python SDK interface; it has not been tested against the live Jev API. Install the package and set your key first: [19] [20]
uv add typesafe-sdk
export TYPESAFE_API_KEY="your-api-key" from typesafe_sdk import Choice, Noul, TypeSafeClient, TypeSafeError
def inspect_ticket(message: str) -> None:
if not message.strip():
raise ValueError("The customer message must not be empty.")
try:
with TypeSafeClient(model="jev-1.13.0", timeout=10.0) as client:
result = client.system_one(
state={"customer_message": message},
questions={
"team": Choice(
instructions="Which team should handle the main request?",
criteria={
"billing": "Charges, invoices, and refunds",
"technical": "Software faults and integrations",
"account": "Login and account access",
"other": "None of the listed teams fits",
},
),
"refund_requested": Noul(
instructions="Does the customer ask for money back?"
),
},
)
except TypeSafeError as exc:
raise RuntimeError("Evaluation failed; keep the ticket for review.") from exc
team = result.choices["team"]
print("Suggested team:", team.choice)
print("Team confidence:", team.confidence)
print("Refund-request probability:", result.nouls["refund_requested"].noul)
if __name__ == "__main__":
inspect_ticket("I paid twice for the same order. Please return the extra payment.") The example prints suggestions without moving the ticket or authorizing a refund. Its error handler catches the SDK’s base exception; a production application should record failures and preserve its review path when evaluation fails. [21]
The model version is pinned deliberately. The model catalog currently lists jev-1.13.0, and both jev-latest and jev-preview resolve to it. An alias can change when a release ships. Once you have tested a workflow’s thresholds, a pinned version lets you decide when to repeat that evaluation and upgrade. [4]
The API reference has a detail worth keeping in mind: question IDs such as team are response keys, not instructions sent to the model. Put the meaning of the task in instructions and criteria; a descriptive dictionary key is not a substitute. [18]
What the speed claims measure
TypeSafe advertises 193.6-times faster and 444.6-times cheaper operation based on its workflow evaluations. Those are company results for particular workloads. [3]
The launch post says these gains are likely toward the high end of real-world improvements. It reports response times of about 70 to 500 milliseconds and notes that its published evaluations generally ran from West Coast laptops near the service. Those measurements should not be read as a latency guarantee for every application or location. [1]
The evaluation site covers four workflows, including invoice processing and customer service. Its reference labels come from averaging answers from GPT-6 Astra and Claude Fable 5.1 at high reasoning settings. Other models run at their providers’ default reasoning settings. The resulting accuracy figures measure agreement with that reference, rather than independently established ground truth for every decision. [22]
Dan Shipper published an early outside comparison using four writing checks across 12 synthetic passages. Jev’s median time was 0.35 seconds per passage, versus 8.83 seconds for Claude Fable 5.1 at high effort. Jev caught six of seven deliberately introduced defects; Fable caught all seven. That is evidence of a speed-versus-accuracy tradeoff in a small test, not a general ranking of the models. [23]
I would use these results to choose a pilot, then measure the actual workflow from the application server. Record the mistakes alongside latency and cost, particularly the cases where the model is confidently wrong.
Read the limitations before automating an action
TypeSafe’s “zero hallucinations” claim needs care. The launch post explicitly says its zero figure is not an empirical measurement: it follows from guaranteed schema matching. [1]
A model restricted to billing, technical, and account cannot invent a fourth department. It can still choose the wrong one. Format validity and factual correctness answer different questions, and the documentation includes a substantial list of known failure modes. [6] [24]
For Jev 1.13, those include unreliable counting and numerical precision, problems comparing dates, and difficulty with indirect or heavily qualified questions. TypeSafe also warns that irrelevant material in a large state can reduce accuracy. Arithmetic and date comparisons should stay in code, with the model handling the part that genuinely needs a judgment. [24]
The limitations page also covers adversarial input. Instructions or misleading framing embedded in the state can influence the answer, so typed outputs do not establish protection against prompt injection. The same page warns that separately phrased questions do not necessarily obey the arithmetic relationships you might expect: asking a proposition and its negation separately need not produce complementary probabilities. [24]
Jev has practical boundaries as well. It currently accepts text, including text represented in JSON; it does not accept images, audio, or video. The catalog specifies a 64k-token total request budget, with a separate 32k-token limit for the state plus the longest question. English is its strongest documented language. Rate limits are still changing as early-access capacity expands. [4]
For customer data, TypeSafe says it does not train on user data and offers zero data retention to enterprise customers. Those are separate commitments. Confirm the retention arrangement that applies to your account before sending sensitive records. [25]
Where I would start
Support routing is a sensible first experiment because you can compare suggested queues with decisions your team already reviews. TypeSafe’s intent-routing pattern also allows an application to send straightforward requests to ordinary code, more involved ones to a specialist language model, and uncertain cases to a person. Jev can take one role in that system without having to solve the whole request. [26]
I would begin with a narrow, reversible decision and run Jev alongside the existing process without letting it act. Use examples that include ambiguous messages and inputs outside the intended categories. Decide which mistakes matter most before choosing a confidence threshold.
Then compare the proposed actions with reviewed outcomes, including how much work reaches the fallback queue. Automatic routing should be enabled only for the cases that meet the team’s error tolerance. Keep the rest on the existing review path, and rerun the evaluation when the model version or question wording changes.
Sources
Sources checked September 18, 2026.
- TypeSafe AI: Introducing System One Models & Jev
- TypeSafe documentation: Introduction
- TypeSafe AI: product overview and pricing
- TypeSafe documentation: Models
- TypeSafe documentation: State
- TypeSafe documentation: Choice
- TypeSafe documentation: Score
- TypeSafe documentation: Noul
- OpenAI API: Pricing
- Claude Platform documentation: Pricing
- OpenAI API: Structured model outputs
- TypeSafe documentation: System One
- TypeSafe documentation: AI primer
- TypeSafe documentation: Speculative fan-out
- TypeSafe documentation: How to build with TypeSafe
- TypeSafe documentation: Confidence
- TypeSafe documentation: Client SDKs
- TypeSafe documentation: HTTP API reference
- TypeSafe documentation: Python SDK
- TypeSafe Python SDK: Synchronous client
- TypeSafe Python SDK: Exceptions
- TypeSafe AI: Workflow evaluations and methodology
- Every: Mini-Vibe Check of TypeSafe’s Jev
- TypeSafe documentation: Jev 1.13 jaggedness
- TypeSafe documentation: Legal and data handling
- TypeSafe documentation: Intent routing