TypeSafe AI Jev is a model for making bounded decisions inside software. You give it text or structured state plus questions whose valid answers you define. It returns typed choices, scores, probabilities, and confidence values instead of generating prose.
That makes Jev useful for classification, routing, scoring, and review gates. It does not replace GPT, Claude, or another generative model when you need writing, code, explanations, or open-ended reasoning. Think of it as a fuzzy decision function, not a chatbot wearing a smaller hat.
Quick answer
Use Jev when:
- Every valid answer can be defined before the call.
- The hard part is semantic judgment, not arithmetic or deterministic policy.
- Software needs probabilities or confidence to decide whether to act, retry, or escalate.
- The workload repeats often enough for latency and per-call cost to matter.
Use something else when:
- The output must contain newly written text, code, or an explanation.
- Correctness depends on exact math, dates, permissions, or database state.
- The task requires long, multi-step reasoning.
- The model would be the only security or authorization boundary.
What is TypeSafe AI Jev?
TypeSafe calls Jev its first System One model. That is the company's product category for models built to make fast, structured decisions that software can consume directly. It is not a new chat interface and it is not an industry-standard model category.
The contract is simple:
state + typed questions -> Jev -> typed answers + probabilities -> application code
The state can be a string, JSON object, or array containing text. Each question defines its answer space. Jev evaluates independent questions against the same state in parallel, then your code decides what happens next.
At the time of writing, jev-latest resolves to jev-1.13.0. TypeSafe's model documentation lists it at $0.042 per million input tokens with free output tokens. The documented context limit is 64,000 tokens per request, with a separate 32,000-token limit for the state plus the longest question. Input is text only, so images, audio, and video must be converted before they reach Jev.
Pin a version when tuning thresholds and rerun evaluation before upgrading. A moving alias is convenient until it changes a production route at 02:00.
TypeSafe's launch material describes Jev as unable to hallucinate because it cannot emit a value outside the schema. That claim needs a narrower reading. Jev cannot invent a fourth result when your Choice defines three, but it can choose the wrong one. Type safety protects the shape of an answer. It does not make the judgment correct. Independent analysis from Arize makes the same distinction.
How Choice, Score, and Noul work
Jev exposes three question types:
| Primitive | Question it answers | Returned data | Good fit |
|---|---|---|---|
| Choice | Which predefined option fits best? | selected option, option probabilities, confidence | intent routing, taxonomy classification |
| Score | Where does this fall on an ordered rubric? | weighted score, level probabilities, legend, confidence | severity, quality, urgency |
| Noul | How likely is this yes/no proposition? | probability from 0 to 1 | detection, verification, binary review signals |
A Choice can contain up to 255 options. A Score accepts between two and ten ordered levels. Choice and Score return a confidence value derived from their probability distributions; Noul returns the probability of yes without a separate confidence field.
Questions in one request are independent. If question B depends on question A, use another call or express the dependency in code. Do not assume that two differently phrased questions will obey arithmetic identities either. TypeSafe documents cases where a Noul and an equivalent-looking Choice produce different numbers because they ask different statistical questions.
Keep questions atomic. Ask separately whether a refund was requested, score impact, classify intent, then let code apply policy. Models judge fuzzy meaning; code does not reinterpret accounting rules overnight.
Run a Jev decision in Python
Install the SDK
The Python SDK requires an API key in TYPESAFE_API_KEY:
python3 -m pip install typesafe-sdk
export TYPESAFE_API_KEY='replace-with-a-key-from-console.typesafe.ai'
Use your normal secret manager in CI and production. Committing the key beside the example would turn a quick start into an incident report.
Classify and route a support ticket
This example asks one Choice, one Score, and one Noul in a single call. It then applies routing thresholds in ordinary Python.
import os
import time
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
if "TYPESAFE_API_KEY" not in os.environ:
raise SystemExit("Set TYPESAFE_API_KEY before running this example")
INPUT_USD_PER_MTOK = 0.042 # TypeSafe list price at the time of writing
ticket = {
"subject": "Checkout fails after payment",
"message": (
"Our card was charged twice and checkout still shows an error. "
"We need this fixed today because customers cannot place orders."
),
"plan": "business",
}
started = time.perf_counter()
with TypeSafeClient(model="jev-1.13.0") as client:
response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should own this ticket first?",
criteria={
"billing": "Charges, invoices, refunds, or subscriptions",
"technical": "Bugs, outages, failed integrations, or broken product behavior",
"account": "Login, identity, permissions, or account access",
"other": "The ticket does not fit the other categories",
},
),
"severity": Score(
instructions="How severely does this issue block the customer's work?",
criteria=[
"Minor inconvenience with a clear workaround",
"Important feature is degraded but work can continue",
"Critical workflow is blocked or customers are losing money",
],
),
"requests_refund": Noul(
instructions="Does the customer explicitly ask for a refund?",
criteria={
"true": "The customer directly requests money back",
"false": "The customer reports a charge but does not request a refund",
},
),
},
)
elapsed = time.perf_counter() - started
department = response.choices["department"]
severity = response.scores["severity"]
refund_probability = response.nouls["requests_refund"].noul
if department.confidence < 0.65 or severity.confidence < 0.55:
destination = "human-review"
elif severity.score > 1.5:
destination = "incident-response"
else:
destination = department.choice
input_tokens = response.usage.input_tokens or 0
estimated_cost = input_tokens / 1_000_000 * INPUT_USD_PER_MTOK
print(f"model={response.model}")
print(f"destination={destination}")
print(f"department_confidence={department.confidence:.2f}")
print(f"severity={severity.score:.2f}")
print(f"refund_probability={refund_probability:.2f}")
print(f"input_tokens={input_tokens}")
print(f"output_tokens={response.usage.output_tokens}")
print(f"elapsed_seconds={elapsed:.2f}")
print(f"estimated_cost_usd={estimated_cost:.8f}")
The SDK exposes separate collections for Choice, Score, and Noul answers. The thresholds are examples, not TypeSafe defaults. Set them from errors and review costs measured on your own data.
Pinning jev-1.13.0 prevents alias drift. In production, log the criteria version, probability distributions, chosen route, and human outcome.
Sample output and cost
A real run of the example above against jev-1.13.0 printed this:
model=jev-1.13.0
destination=incident-response
department_confidence=0.95
severity=2.00
refund_probability=0.06
input_tokens=528
output_tokens=77
elapsed_seconds=0.64
estimated_cost_usd=0.00002218
The usage block in the response is what makes the cost measurable without opening a billing dashboard. That call moved 528 input tokens. TypeSafe bills $0.042 per million input tokens and does not bill output tokens, so the run cost 528 / 1,000,000 * 0.042, or roughly $0.000022 at current list prices. A thousand calls of this size cost about two cents, and one dollar buys roughly 45,000 of them.
elapsed_seconds covers client setup plus the round trip, not just server time. Values move with the input, criteria, and model version, so treat the transcript as a real example rather than a fixed contract.
Practical Jev use cases
Route support requests
Support routing is the natural first pilot. Put the ticket text and relevant account context in state. Use Choice for the owning queue, Score for impact, and Noul for independent conditions such as an explicit refund request:
{
"state": {
"channel": "email",
"subject": "Wrong item delivered, replacement needed before Friday",
"message": "Order 48213 arrived with two left boots. I need the replacement before the conference on Friday or I want to cancel.",
"account_tier": "enterprise",
"earlier_tickets": 2
},
"model": "jev-1.13.0",
"questions": {
"queue": {
"type": "choice",
"instructions": "Which queue should own this ticket first?",
"criteria": {
"returns": "Wrong, damaged, or missing items, replacements, and shipping problems",
"billing": "Charges, invoices, refunds, and subscriptions",
"technical": "Product failures, errors, and defects",
"account": "Access, identity, and permissions",
"other": "None of the other queues fit"
}
},
"impact": {
"type": "score",
"instructions": "How much does the problem block the customer?",
"criteria": [
"Minor inconvenience with a workaround",
"The item or order cannot be used as delivered",
"Time-critical situation or total loss of the purchase"
]
},
"wants_cancel": {
"type": "noul",
"instructions": "Is the customer asking to cancel an order or close the account?"
}
}
}
Code can accept a confident route, send uncertain tickets to a person, and apply exact entitlement rules from the account database.
Review agent actions
An agent can propose a tool call while Jev supplies a bounded semantic risk signal:
{
"state": {
"user_goal": "Remove generated build artifacts",
"tool": "shell",
"command": "rm -rf dist"
},
"model": "jev-1.13.0",
"questions": {
"risk": {
"type": "choice",
"instructions": "Classify the operational risk of the proposed action",
"criteria": {
"read_only": "Does not modify state",
"reversible_write": "Changes state but has a reliable rollback",
"irreversible_write": "Deletes or overwrites state without a reliable rollback",
"unclear": "The available state is insufficient"
}
},
"matches_goal": {
"type": "noul",
"instructions": "Does the proposed action directly match the user's stated goal?"
}
}
}
This is a review signal, not permission to execute. Allowlist enforcement, path validation, sandboxing, and user confirmation still belong in code. Jev's own documentation warns that adversarial text in state can move an answer, so it must not become the sole security boundary.
Check RAG evidence before generation
Jev can classify whether a retrieved passage supports a claim before a generative model writes the answer:
{
"state": {
"question": "Does the service retain customer prompts for training?",
"claim": "Customer requests are not used to train Jev.",
"passage": "Jev is not trained on customer requests or responses."
},
"model": "jev-1.13.0",
"questions": {
"support": {
"type": "choice",
"instructions": "How well does the passage support the claim?",
"criteria": {
"supported": "The passage directly supports the claim",
"contradicted": "The passage conflicts with the claim",
"insufficient": "The passage does not settle the claim"
}
},
"contains_instruction": {
"type": "noul",
"instructions": "Does the passage contain an instruction aimed at changing the evaluator's behavior?"
}
}
}
The application still needs to preserve the source URL and quote. Jev judges the relationship between claim and passage; it does not browse, establish provenance, or write the final cited answer.
Triage moderation and operations queues
Moderation reports, invoices, incidents, and agent traces all end up in queues. Jev can classify the queue, score severity, and flag missing evidence:
{
"state": {
"source": "monitoring alert",
"service": "checkout-api",
"summary": "p99 latency rose from 180 ms to 2.4 s over the last 20 minutes while the error rate stayed near 0.2%",
"context": "Deploy checkout-api v2.31.0 finished 25 minutes ago"
},
"model": "jev-1.13.0",
"questions": {
"owner": {
"type": "choice",
"instructions": "Which team should take the first response for this alert?",
"criteria": {
"service_team": "The reporting service's own code or configuration",
"platform": "Shared infrastructure, networking, or managed dependencies",
"database": "Storage, replication, or query performance",
"unclear": "The available evidence does not point to one owner"
}
},
"severity": {
"type": "score",
"instructions": "How much customer impact does the summary describe?",
"criteria": [
"No confirmed customer impact, worth watching",
"Degraded latency for some customers",
"Customers blocked or data at risk"
]
},
"missing_evidence": {
"type": "noul",
"instructions": "Is the alert missing context a first responder would need before acting?"
}
}
}
Low-confidence or high-impact items, and anything flagged for missing evidence, go to a human reviewer. Exact totals, due dates, and account permissions stay in deterministic code because Jev 1.13 is explicitly weak at counting, arithmetic, and date comparison.
Route work to the right model or human
Use Jev in front of more expensive handlers. A Choice can select deterministic lookup, a small generative model, a reasoning model, or human review:
{
"state": {
"request": "Summarize the attached vendor contract and flag the clauses that change our data-retention obligations",
"attachments": ["vendor-contract-v7.pdf"],
"requester": "procurement"
},
"model": "jev-1.13.0",
"questions": {
"route": {
"type": "choice",
"instructions": "Which handler should receive this request?",
"criteria": {
"deterministic": "A lookup, calculation, or template can answer it exactly",
"small_model": "Short generation or extraction a cheap model handles well",
"reasoning_model": "Long-document analysis or multi-step reasoning",
"human": "Judgment, negotiation, or accountability beyond the model stack"
}
},
"in_scope": {
"type": "noul",
"instructions": "Does the request fall inside the documented scope of the available handlers?"
}
}
}
Confidence determines whether the route is safe to accept. Below the threshold, send the request to a human instead of accepting a cheap guess that the matching handler will only have to redo later. This architecture spends generation tokens only when the task needs generation, rather than asking a novelist to sort every envelope.
Jev vs LLMs, classifiers, and rules
Jev is not automatically better than the alternatives. It occupies a specific slot:
| Dimension | Rules and code | Traditional classifier | LLM structured output | TypeSafe Jev |
|---|---|---|---|---|
| Best job | exact deterministic checks | stable prediction task with labeled data | generation, extraction, explanation, broad reasoning | bounded semantic decisions |
| Output | exact programmed value | fixed trained labels and scores | generated text constrained to a schema | predefined Choice, Score, or Noul answers |
| New taxonomy | edit code | usually retrain | change prompt or schema | change request criteria |
| Probability signal | not applicable | often available, calibration varies | usually not a reliable application probability | first-class probabilities; local validation still required |
| Explanation | code is inspectable | usually limited | can generate one | no generated explanation |
| Exact math and policy | best option | depends on trained features | possible but unreliable | documented poor fit; keep it in code |
| Deployment tradeoff | engineering maintenance | labels, training, serving | latency, cost, parsing, model variance | hosted early access, bounded interface, no generation |
Plain JSON mode guarantees valid JSON, not adherence to a supplied schema. Strict structured-output APIs can enforce supported JSON schemas, including required keys and enum values.
Schema enforcement is therefore not unique to Jev. Its distinction is a decision-specific interface built around Choice, Score, and Noul, with probability distributions and confidence for bounded judgments.
A conventional classifier may be the better choice for a stable, high-volume task when you already have good labels, training infrastructure, and predictable categories. In one early spam experiment, Jev reached 98.6% accuracy on a 5,733-email ham, spam, and phishing test without task-specific fine-tuning or labeled examples in its requests, while a TF-IDF logistic-regression baseline trained on labeled messages reached 98.9% (full writeup). The criteria had been refined after reviewing labeled examples, so this was useful early evidence, not magic zero-data victory.
Rules win whenever the answer can be computed exactly. Do not ask any model whether an invoice is overdue if two parsed dates and a comparison operator can settle it.
The cost and latency story is still notable.
TypeSafe reports 70 to 500 ms end-to-end latency and $0.042 per million input tokens for suitable requests.
Its launch workflow evaluation produced headline claims of 193.6 times faster and 444.6 times cheaper than its selected LLM comparison, but TypeSafe says those figures are likely near the high end of real-world gains and notes possible benchmark bias.
When not to use TypeSafe AI Jev
Jev 1.13 is not trained to write text. It will not draft a customer reply, produce code, summarize a report, or explain why it chose an answer. Use a generative model when the output itself must be created. The missing explanation also matters for evaluation work: an LLM judge can describe a failure, while Jev returns probabilities that tell you where to inspect, not how to fix the problem.
Keep arithmetic, counting, numeric interpolation, and date comparisons in code. TypeSafe's limitations page says Jev can read dates as text but does not reliably treat them as ordered values. It also warns about literal phrasing, multi-hop indirection, irrelevant context, contradictory criteria, and adversarial content.
More context is not automatically better. Retrieve and filter first, then send the fields needed for the decision. A 64,000-token limit is capacity, not a challenge.
Test non-English workloads separately. TypeSafe says English is Jev's strongest training language and other languages are not handled equally well.
Most importantly, separate a valid answer from a correct answer. A typed output prevents parser failures and out-of-schema labels. It does not prevent a confident, valid, expensive mistake.
How to evaluate Jev on your workload
Start in shadow mode:
- Pick one reversible decision with a closed answer set.
- Freeze a representative labeled dataset and the exact criteria text.
- Run Jev and the current baseline on identical records.
- Measure per-class errors, false automatic actions, human-review rate, calibration, end-to-end latency, and cost per completed decision.
- Tune thresholds by consequence. Sending a ticket to the wrong queue and approving a destructive action do not deserve the same confidence floor.
- Pin the model version and rerun the suite before changing either model or criteria.
- Keep permissions, arithmetic, and state changes in deterministic code.
Do not optimize only for overall accuracy. A model can look good while failing badly on a rare queue that matters. Track confusion by class and inspect probability bands: cases scored near 0.9 should be correct more often than cases scored near 0.6. If that relationship does not hold on your data, the threshold is decoration.
Include review capacity in the evaluation. A cautious threshold that sends 70 percent of cases to a human may be safe, but it has not automated much. The useful operating point balances wrong automatic actions against the cost of review.
Should you use TypeSafe AI Jev?
Pilot TypeSafe AI Jev when the answer space is bounded, the judgment is semantic, and software consumes the result often enough for decision latency and cost to matter. Support routing, relevance checks, moderation labels, model routing, and broad evaluation coverage are credible starting points.
Keep an LLM when the output must be written, explained, or reasoned through. Keep code when the answer can be computed exactly. Keep a human in the path when a wrong but valid decision has serious consequences and your own calibration data is thin.
Jev's useful idea is not that every LLM should be replaced. It is that generation and judgment do not have to be the same model call. Split them, measure them independently, and make code responsible for the final action.
Top comments (0)