Jev is a model that doesn't write. You send it a piece of state and a set of typed questions, and it returns answers your code can use directly: a choice, a score, a yes/no probability, each with a confidence number. No tokens to stream, no JSON to parse, no retry when the model wraps its answer in prose.
TypeSafe AI launched it on 15th September 2026. The company calls it a System One model, after Kahneman's fast, intuitive thinking, as opposed to the slow deliberation that chat models perform.
| Maker | TypeSafe AI, San Francisco |
| Founders | Diogo Almeida (CEO, ex-OpenAI), Sasha Sheng (COO, ex-Meta FAIR), Erik Gafni (CTO) |
| Funding | $40M, per The Register |
| Price | $0.042 per MTok input ($42 per billion), output free |
| Latency | 70-500ms claimed, 150-350ms in tester reports |
| Model name | jev-latest |
| Access | Early access by waitlist, plus a browser playground |
What it actually does
One call carries the state (a message, a document, a data structure) and a dictionary of questions. Each question is one of 3 types:
- Choice - pick one option from a set. Returns the option, a probability per option, and a confidence.
- Score - rate against ordered levels. Returns the level, a probability per level, and a confidence.
- Noul - a yes/no claim. Returns the probability that it's true.
Questions run in parallel against a shared read of the state, so asking 50 costs about as much wall time as asking 1. That inverts the habit built around LLM classifiers, where each extra question muddies the answer and adds latency.
The model can't produce free text, which is what TypeSafe means when it says Jev can't hallucinate. It's a claim about types, not about correctness. Jev can still be wrong, and confidently so.
For business people
Plenty of production AI work is not writing. It's deciding: which team gets this ticket, is this reply angry, should the agent call a tool, is this answer good enough to send. Today those decisions go to a chat model that takes a few seconds and bills per token in both directions. The latency forces workarounds, like a crude rule that decides whether the expensive check is worth running.
Jev sells the decision as its own primitive, sitting between plain code and an LLM call. The pitch is price and speed: the launch post claims 20-200x faster and 40-400x cheaper than frontier models on decision work, with output tokens free.
What it costs in practice: a tester ran about 5,000 requests for around $2. Good Start Labs priced the same grading job at $160 per million answers against $33,000 for Claude Fable 5.1.
Where the risk sits:
- It's a new company with a new model. Early access, a waitlist, and no track record beyond 1 week.
- The headline benchmarks are the vendor's own. TypeSafe admits its evaluation workflows came from its own capabilities team.
- Confidence has to be earned. The value of a calibrated probability depends on 90% meaning 90%, and that needs testing on your own labelled data.
- It replaces nothing on its own. You still run an LLM for the writing. Jev goes before and after it.
Worth a test if you already pay for classification, routing or scoring calls at volume. Not worth a rebuild if you make a few hundred decisions a day, where the cost difference is noise.
For technical people
Call it
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "I was charged twice. Please fix this ASAP.",
"model": "jev-latest",
"questions": {
"is_urgent": {"type": "noul", "instructions": "The message conveys urgency"},
"department": {"type": "choice", "instructions": "Which team should handle this",
"criteria": {"billing": "Payment issues", "technical": "Bugs", "sales": "Pricing"}}
}
}'
The Python SDK wraps the same call:
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
with TypeSafeClient() as client:
response = client.system_one(
state={"document": ticket_text},
questions={
"billing": Noul(instructions="Is this ticket about billing?"),
"tone": Choice(
instructions="What is the customer's tone?",
criteria={"calm": None, "frustrated": None, "angry": None},
),
"urgency": Score(
instructions="How urgent is this ticket?",
criteria=["can wait", "this week", "today"],
),
},
)
print(response.nouls["billing"].noul)
print(response.choices["tone"].choice)
print(response.scores["urgency"].score)
Install with uv add typesafe-sdk or pip install typesafe-sdk, then set TYPESAFE_API_KEY. Both a sync and an async client ship.
Confidence is the control surface
Every Choice and Score answer carries probabilities plus a single confidence between 0 and 1. The documented pattern is 3 bands: act automatically when confidence is high, confirm or flag in the middle, route to a human at the bottom. Thresholds scale with the stakes of the action, and your code holds them, not the model.
action = response.choices["action"]
if action.confidence < 0.5:
route_to_human(user_message)
elif action.choice == "approve_transfer" and action.confidence < 0.9:
ask_user_to_confirm(account_id)
else:
execute(action.choice)
Training and shape
TypeSafe trains with RLCD (Reinforcement Learning for Calibrated Decisions) instead of RLHF, optimising for honest probabilities rather than human preference. The sampler produces all answers in one pass rather than token by token, which is where the latency goes.
⚠️ WARNING: the input wants structured program state, not a chat transcript. Choice cardinality caps at 255. Above that, TypeSafe documents a 2-stage pattern: score candidates independently, then choose.
Documented patterns worth reading before you design around it: speculative fan-out (ask everything you might need in one call), confidence-gated routing, composite scoring, and intent routing.
What early testers measured
- Michael Lee ran about 5,000 requests for ~$2 across classification, routing, intent and steering. He measured p50 ~150ms and p95 ~350ms, and called it "a new intelligent decision-making primitive, separate from deterministic code and LLM calls". His old setup used low-latency LLM classifiers averaging 4 seconds, which forced hand-written heuristics to decide when to run them. At 150ms you run the check every turn, before and after generation.
- Every put 777 judgments across 37 documents through it in under 0.7 seconds for about a quarter of a cent. On a writing-lint test Jev caught 6 of 7 planted defects at a median 0.35s per passage; Fable 5.1 caught 7 of 7 at 8.83s.
- Good Start Labs ran 6,003 rubric checks over 1,203 financial-research answers. Jev agreed with a 5-model panel 90% on average, in a range of 86% to 92%, at the $160 versus $33,000 cost noted above. Their own caveat is the honest one: "Agreement is evidence about a judge; it doesn't establish who is right."
- One early tester posted a confident error: Jev rated a benign sentence as attempted AI manipulation at 0.84 probability. His line is the one to remember: "type-safe" does not mean "can't be wrong".
What to check before trusting it
- Calibration on your data. Take 200 labelled examples from your own workflow and check whether the 0.9 bucket is right 90% of the time. Everything else follows from that number.
- Agreement is not truth. Both public tests measure agreement with other models, not ground truth.
- The founder claim. Almeida's post opens with "After co-inventing ChatGPT". The team page says RLHF and InstructGPT, which is the accurate version and still a strong credential. Some replies on X pushed back on the shorter phrasing.
- "Hallucination-free" is definitional. The Register made the same point: no natural language output doesn't preclude being incorrect.
Where I'd use it
Every sales tool I build makes small judgements before it makes a sentence: is this reply a real objection or an out-of-office, which account does this email belong to, is this call note worth pushing to the KB, does this draft break my own writing rules. Today those are LLM calls, and they are the slow part of every pipeline.
A decision primitive at 150ms and near-zero cost would let me run checks I currently skip, like scoring every draft before it reaches me instead of after. The catch is access: waitlist only, so it goes on the list to test rather than into a build.
Further Reading
