Most LLM calls in a production system are not asking for prose. They are asking for a decision: which team gets this ticket, is this document relevant, does this message need moderation, should this agent step retry. We pay frontier-model prices and wait seconds for a model to write a sentence, then parse that sentence back into an enum.
TypeSafe AI launched Jev on September 15, 2026 to go after exactly that waste. It is the first of what they call System One Models: models that look at a state and return typed answers with probabilities, instead of generating tokens one by one. The company came out of two years in stealth with a $40M seed led by DCVC, and founder Diogo Almeida worked on the instruction-following research at OpenAI that fed into ChatGPT. So this is not a weekend project, and it is worth ten minutes of your time to understand where it fits.
What Jev actually returns
You give Jev a state (any JSON) and a set of questions. Each question has one of three types:
- Choice: pick one option from a fixed set (up to 255 options). You get the choice plus the full probability distribution.
- Score: place the state on a described scale of 2 to 10 levels. You get a weighted score plus probabilities.
- Noul: a yes/no judgment returned as a probability between 0 and 1.
All questions are answered in parallel, in one pass. There is no output text to generate, which is why output tokens are free and latency sits at 70 to 500ms end to end.
This is what a ticket triage call looks like with the Python SDK, based on the early-access docs:
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
response = client.system_one(
state={"ticket": "I was charged twice for order A-104"},
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={"billing": "Payment issues", "technical": "Bugs"},
),
"frustration": Score(
instructions="How frustrated is the customer",
criteria=["Calm", "Frustrated but civil", "Very angry"],
),
"refund_requested": Noul(
instructions="Customer explicitly asks for a refund",
),
},
)
dept = response.answers["department"]
print(dept.choice, dept.confidence, dept.probabilities)
Compare that to the usual pattern: a prompt that says “respond only with JSON”, a structured output schema, a retry loop for when parsing fails, and a guess about whether the model was sure. Jev removes the parsing problem completely and gives you the confidence number you were never getting before.
The numbers, and what is behind them
TypeSafe’s headline claims are 40x to 200x faster than frontier LLMs on comparable tasks and 444.6x cheaper on their workflow evals. One published example: Jev finished a task in 0.114 seconds for $0.000081, where GPT-5.6 Terra took 8.566 seconds for $0.013880. Input pricing is $0.042 per million tokens, against $0.20 to $10 per million for chat models.
Read the fine print before you put those numbers in a deck:
- The benchmarks are vendor-run. TypeSafe’s own team wrote the workflows.
- The reference answer is the average of GPT-6 Astra and Fable 5.1, so Jev is being scored on how closely it matches frontier models, not against human ground truth.
- TypeSafe says it expects these gains to sit at the high end of real-world use.
- TypeSafe also says it cannot prove the price is unsubsidized. Early-access pricing is not a contract.
None of this makes the launch less interesting. It means the right move is to run it on your own data, not to rewrite your pipeline because of a chart.
“No hallucinations” means something narrow
The launch post says Jev does not hallucinate. What that actually guarantees is that the output always matches your schema. You will never get an unparsable response or a department that does not exist.
It does not guarantee the answer is right. Jev can confidently pick the wrong option from a valid list. Format correctness and answer correctness are different problems, and only the first one is solved by construction. The second one is where calibration is supposed to help, and calibration has not been verified independently yet.
This matters for how you design around it. If your current failure mode is broken JSON and retry storms, Jev fixes that outright. If your failure mode is the model making the wrong call, Jev gives you a probability to act on, but you still need to measure whether that probability means what it says.
Where it fits, and where it does not
The simplest way to think about it: Jev picks a card from a deck you hand it. It does not name a card.
Good fits:
- Routing and triage: tickets, leads, alerts, inbound email.
- Relevance filtering before expensive work: screen retrieved chunks before they reach your RAG model, or filter documents before an agent reads them. This one is underrated. If you are sending 20 chunks to a frontier model and only 5 matter, a 100ms filter pays for itself on the first call. We wrote about why bad retrieval causes most RAG hallucinations, and a cheap relevance gate is one more layer against it.
- Moderation and policy checks at request time, where a 3 second LLM call was never acceptable.
- Agent step decisions: should this tool call run, retry, or escalate. Fast enough to sit inside the loop.
Bad fits, by TypeSafe’s own guidance and early testers:
- Anything that needs text: summaries, drafts, code, explanations. It has no rationale output, which is a real problem if your decisions need to be auditable.
- Arithmetic, counting and date comparisons.
- Multi-hop reasoning and indirection (“the customer from the previous ticket”).
- Literal negations and implied conditions.
- Inputs that contain adversarial or steering text. If users control the state, assume someone will try to push the decision.
There are also hard limits to design around: 255 options per Choice, about 64,000 tokens of shared context across all questions, and early-access rate limits of 1,200 requests per minute. If you need to pick from 10,000 products, you need a two-stage approach (narrow first, then score), and you lose some of the speed.
Use the confidence, or you are wasting the best part
The feature that changes system design is not speed. It is that every answer comes with a probability. With an LLM, you get an answer and no idea how sure it was. With Jev, you can build thresholds:
def route_ticket(ticket: dict) -> str:
r = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Charges, refunds, invoices",
"technical": "Bugs, errors, outages",
"account": "Login, access, profile changes",
},
),
},
)
dept = r.answers["department"]
if dept.confidence >= 0.9:
return dept.choice # automate
if dept.confidence >= 0.5:
return f"review:{dept.choice}" # suggested, human confirms
return "human_queue" # too unsure, don't guess
The thresholds above are a starting point, not a rule. The only way to set them properly is to log confidence alongside the actual outcome for a few thousand real cases and check that 0.9 confidence is right about 90% of the time. If it is right 70% of the time, your automation threshold needs to move, and you have learned something important about the model before it cost you anything.
How we would test it this week
If you have an LLM classification step in production today, this is a two day experiment:
- Pull 1,000 to 2,000 real inputs from that step, with the outcome you now know was correct.
- Run them through Jev and through your current model. Record answer, latency, cost and Jev’s confidence.
- Compare accuracy against your ground truth, not against the other model.
- Bucket Jev’s answers by confidence and check calibration per bucket.
- Look at the failures by hand. If they cluster around negations, dates or adversarial text, that tells you where Jev should not be making the call.
If accuracy holds and calibration is honest, you can move that step to Jev and keep the frontier model only for the low-confidence tail. That hybrid is where most of the cost saving is: the easy 80% of decisions go through a model that costs a fraction of a cent, and the hard 20% still get the expensive reasoning.
Do not migrate everything at once. Keep your current model behind a flag, because this is early access from a company that launched ten days ago, and pricing and limits can change.
Update, September 30: OpenAI’s Decisions API
On September 29 at DevDay, OpenAI announced a Decisions API that does the same job. It runs on a version of GPT-6 Luna, takes text or image context, and returns one of the answers you define along with a confidence score. OpenAI says it answers in about 150ms, roughly ten times faster than calling Luna through the regular API. It is in limited preview, with broad access promised in the coming days. OpenAI has not published a price or any accuracy numbers yet.
So there are now two System One style options, and neither has independent numbers. That makes the test above more useful, not less. Run the same 1,000 labelled cases through both and compare accuracy against your own ground truth, calibration per confidence bucket, P95 latency from your own region, and cost per 1,000 decisions once OpenAI publishes pricing.
For many teams the deciding factor will be simpler than the benchmark. If you already have an OpenAI contract and data processing terms, the Decisions API needs no new vendor review. If Jev wins clearly on your data, that review is worth doing.
Our take
Jev is the first serious attempt to split AI in production into two layers: fast, cheap, typed decisions, and slow, expensive reasoning and generation. That split was always there in how we used LLMs. We just paid for the expensive layer for everything.
The claims are vendor-run and the calibration story is unproven, so treat the numbers as a hypothesis. But the architecture is right. If your system makes thousands of small judgment calls a day through a chat model, you should have a test running against Jev by next week.
If you want help setting up that evaluation on your own data, talk to us.