Companion post to the video above. This is the deeper reference version — the request shapes, the exact limits, and the sources the video didn’t have time for. If you just want the mental model, watch the video first; come back here when you’re actually building. Model version: jev-1.13.0. Every performance figure here is TypeSafe’s own and is labelled as such.
Here is something most of us do every week. You have a support message and you need to know which team it belongs to, so you call an LLM: here is the message, here are five categories, reply with just the category name.
Look at what actually happens. The model doesn’t decide — it generates. It emits a token,
conditions on it, emits the next, and so on in sequence until somewhere in that stream is the word
billing, and then you write code to pull it back out. You are running a text generator to obtain
one word, and the thing that comes back has no room in it to tell you how sure it was.
TypeSafe shipped a model called Jev on 15 September 2026 that is built for exactly this job and does not generate text at all. They call the category a System One model. This post is what it is, what the request and response actually look like, and where the edges are.
Contents
- What a System One model is
- State
- The three primitives
- Parallel evaluation, and why you should decompose
- Probabilities and confidence are different things
- The numbers, and who measured them
- When not to use this
- Getting access
- Appendix: limits and rates
1. What a System One model is
The framing is Kahneman’s and TypeSafe borrow it openly. System 2 is slow, deliberate reasoning — working a problem through step by step. System 1 is the judgment you have already made before you noticed making it: is this person angry, is this in scope, which pile does it go on.
Most LLM calls in a production system are a System 2 engine doing System 1 work.
A System One model does the second thing only. You give it a state (the text to judge) and one or more questions, and it returns typed answers with probabilities. There is no generation step, so there is nothing to parse and nothing to retry. The shape of the answer is not requested in a prompt, it is defined in the request — the same way a function returning a boolean cannot hand you a paragraph.
The trained-for property is different too. TypeSafe call their post-training method RLCD,
reinforcement learning for calibrated decisions, and position it against RLHF (optimise for output
people prefer) and RLVR (optimise against mechanically checkable answers). Their stated objective
is that the probability attached to an answer should be honest — that outcomes assigned a
probability of 0.2 occur about 20% of the time. Their primer is worth reading in full;
it also names mode dropping, the narrowing of the output distribution under preference
optimisation, as the thing they are trying to avoid.
The architecture is undisclosed. There is no parameter count, no weights, no self-hosting. “A new architecture and a parallel sampler” is as specific as the public material gets.
2. State
state is whatever you want evaluated. It takes three shapes:
"My card was charged twice."
{ "message": "My card was charged twice.", "order_id": "A-104" }
["Hi", "customer 4471", "my card was charged twice"]
The docs recommend the object form for most cases, because named fields keep the relationships legible. Text only — images, audio and video are explicitly unsupported.
One state is evaluated against every question in the request, independently.
3. The three primitives
Three question types. Not three of twenty — three is the entire API surface.
Choice
A fixed set with no order between the options. Up to 255 options.
{
"state": { "message": "My card was charged twice." },
"model": "jev-latest",
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle this message?",
"criteria": {
"billing": "Payment, invoicing or charge problems",
"shipping": "Delivery, tracking or address problems",
"account": "Login, closure or profile problems"
}
}
}
}
The answer carries choice (the highest-probability option), probabilities across all of them
summing to 1.0, and confidence.
Two pieces of guidance from the docs that are easy to skip and shouldn’t be: include an explicit
other or none of the above for open-ended classification, and for hierarchical classification
chain questions level by level rather than committing to one greedy pick across a flattened set.
Where options are genuinely confusable, the criteria value can be an object with what, not_for
and examples fields instead of a bare string.
Score
An ordered spectrum. criteria is an array, 2 to 10 entries, lowest to highest, and each entry
gets an index starting at 0.
{
"type": "score",
"instructions": "How severe is this issue for the customer?",
"criteria": [
"No impact; cosmetic or informational",
"Minor annoyance; feature works",
"Broken or degraded feature, but a workaround exists",
"Blocked; the customer cannot complete their task"
]
}
And here is the part that makes Score a genuinely different primitive rather than an ordered
Choice: the answer is not one of your levels. score is a weighted position — each level’s
index multiplied by its probability, summed. Four levels can return 1.7: a point between two
levels you defined, which you never defined yourself.
That is only meaningful because the levels are ordered. There is no midpoint between billing and
shipping, but there is certainly one between “degraded” and “blocked”. Choice picks; Score
positions.
The response also carries a legend mapping indices back to your descriptions, plus
probabilities per level and confidence.
The docs are firm about how to write the levels: describe situations, not degrees. “Broken or degraded feature, but a workaround exists” works; “moderately severe” does not. Each level is judged independently against the state and never sees its neighbours or its own index, so a vague relative label has nothing to match against.
They are equally firm about not compressing multiple dimensions into one Score. If your severity really means impact and urgency, that is two Scores, combined in your own code with weights you chose and can explain.
Noul
TypeSafe’s word for a truth question. Is this statement true? You get a probability between 0 and 1.
{
"type": "noul",
"instructions": "The customer is asking for a refund."
}
4. Parallel evaluation, and why you should decompose
Every question in a request is evaluated against the same state, independently, at the same time. The docs state that adding questions barely changes response time and recommend batching them rather than making separate calls.
This inverts an instinct built up on LLMs. There, every call costs a round trip, so you cram — “classify the urgency and the topic and the sentiment and tell me whether it’s a complaint” — and get back one blob you hope parses.
Here the incentive runs the other way. Ask eight narrow questions instead of one wide one and combine them in your own code, where you set the weights, where you can log which factor drove the decision, and where the business logic is code rather than a paragraph of English embedded in a prompt. Two consequences worth naming:
- You can see the contributing factors. A composite score you assembled yourself is debuggable; a single number a model produced from a compound instruction is not.
- You can change the weighting without re-running anything. The weights live in your code.
The cost model helps here: input is billed, output is free, and the state is the bulk of the input. Several questions against one state is the cheap shape.
5. Probabilities and confidence are different things
Every answer returns both, and they are not the same statistic.
Probabilities is the distribution — how belief was spread across the options. Confidence is a separate 0–1 number describing the shape of that distribution: how concentrated it is.
Consider two Choice answers over three options:
| A | B | C | confidence | |
|---|---|---|---|---|
| Answer 1 | 0.90 | 0.06 | 0.04 | high |
| Answer 2 | 0.35 | 0.33 | 0.32 | low |
Both sum to 1.0. Both have the same winner. If all you consume is the top answer — which is all you can consume from a generated word — these are indistinguishable. They are not remotely the same event: in the first the model knows, in the second it is separating three near-identical options and handing you the winner anyway.
TypeSafe’s suggested structure is three tiers: above 0.9 act, 0.5–0.9 act with confirmation or review, below 0.5 abstain and route elsewhere. Their own caveat matters more than the numbers though — a confidence threshold is not one number. You set it per branch against the cost of being wrong in that branch. The bar for auto-tagging a ticket and the bar for issuing a refund are nowhere near each other, and the model cannot tell you where either belongs.
What this buys, structurally, is that abstaining becomes a first-class outcome — a branch your code can take, rather than something you bolt on by asking a text generator to rate its own certainty. The calibration question underneath it (whether that number can be trusted, and what that even means) deserves its own treatment and gets one shortly.
6. The numbers, and who measured them
Every figure in this section is TypeSafe’s own. I have not benchmarked this model and I am not aware of an independent benchmark as of publication.
| Claim | Figure |
|---|---|
| Input price | $0.042 / 1M tokens ($42 / 1B) |
| Output price | free |
| vs GPT-5.6 Terra | 193.6× faster, 444.6× cheaper |
| vs Claude Fable 5.1 | 238× lower input price |
| End-to-end latency | 70–500 ms |
| Accuracy, 4-workflow eval | Jev 67.8% · GPT-5.6 Terra 67.9% · Claude Opus 5 73.1% · GPT-5.6 Sol 74.1% |
| Cost per case, same eval | $0.0004 vs $0.03–$0.18 |
The credit due here is that the caveats come from TypeSafe themselves, in the launch post:
- their published evals are “generally run from our laptops on the West Coast”;
- the eval workflows were written by their own capabilities team;
- they expect the reported gains are “on the higher end of real world gains”;
- reference answers average GPT-6 Astra and Fable 5.1, which they note may underestimate other models’ relative performance;
- and they have said they cannot prove the pricing is unsubsidised.
Two readings follow. The latency figure is a best case measured next door to the datacentre, not a number to size capacity against. And the row that actually matters is the accuracy row, not the speed row: on the vendor’s own evaluation Jev is level with one frontier model and roughly six points behind the best two, at a fraction of a cent per decision. That is a strong trade. It is not “beats frontier models,” and whether those six points matter is a question about your workload that only you can answer.
Add to that: early access, undisclosed architecture, no published parameter count, and rate limits the docs say are “adjusting dynamically” as they scale. Price the volatility in.
7. When not to use this
TypeSafe publish a known-weaknesses page per model version — unusual, and the main reason
I would trust the rest of their documentation. The short version for jev-1.13:
- Counting and arithmetic. It does not count reliably, and the error grows with the size of the thing being counted.
- Numeric representations. Comparing hex codes, RGB triples or raw quantities is weak. It is a semantic model; give it meaning, not magnitudes.
- Dates and times. It reads a date as text, not as a position on an ordered line. “Did this happen in the last 30 days” is not a question it can answer — and it will not fail, it will return a clean boolean with a confidence score attached. Compute date arithmetic in your own code and pass the result in as state.
- Indirection. Double negatives and multi-step reasoning reduce accuracy.
- Large or noisy context. Irrelevant detail distracts it; context rot applies.
- Adversarial content. It can be steered by instructions embedded in the state it is reading — which matters directly if you are using it as a safety filter over untrusted text.
- No structural invariants. Complementary questions are not guaranteed to be consistent with each other. Each question is evaluated independently and nothing reconciles them afterwards, so you cannot treat a set of answers as a joint distribution.
That last one has the sharpest practical edge, and TypeSafe’s own example makes it concrete: asking
“is the customer asking for a refund?” as a Noul returned 0.22, and as a Choice returned
0.01 / 0.99. Same model, same text, two answers that contradict each other.
Note what did not happen there. The request succeeded. The values matched the schema. 0.22 on a
truth question is a reasonably confident no, so it would not trip a confidence threshold either.
Every check you would normally have, passed. The only reason anyone knows there is a problem is
that the question was asked twice and the answers compared — and in production you ask once.
So: “cannot hallucinate” is a guarantee about the shape of the answer. It is real and it is worth having — you will not write a retry loop for a malformed response again. It is not a guarantee about the answer being right, and TypeSafe do not claim it is.
And beyond the failure list, the structural limit: this returns a number, not a reason. If you work somewhere that has to explain a decision after the fact, “the model said 0.94” may not be an answer you are permitted to give.
8. Getting access
- TypeSafe console — sign in at console.typesafe.ai, keys at
/keys. Early access, waitlisted. - Cloudflare Workers AI — model
typesafe/jev, no TypeSafe waitlist. Note the context window is 32k here rather than 64k. Docs. - Vercel AI Gateway — reported available without the waitlist.
First request:
POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json
Model aliases jev-latest and jev-preview both currently resolve to jev-1.13.0. Python and
JavaScript SDKs are published.
One warning. There is a cluster of sites right now advertising “Jev API access without the waitlist” and free online playgrounds. They are affiliate pages built on the launch. Use the console or Cloudflare, and do not paste an API key into any of them.
Appendix: limits and rates
| Max context | 64k tokens per request (32k on Cloudflare) |
| State + longest question | 32k token budget |
| Token throughput | 250,000 tokens/sec |
| Request rate | 1,200 requests/min |
| Choice options | max 255 |
| Score levels | 2–10, ordered |
| Input types | text only |
| Language | English optimised; others supported, less reliable |
| Training on customer data | requests not retained for training |
Rate limits are documented as adjusting dynamically during scale-up; treat the table as a snapshot.
Sources: TypeSafe docs · System One concept · State · Choice · Score · Noul · ML primer · Confidence · Models and pricing · Quickstart · Known weaknesses · Launch post · Cloudflare Workers AI. All performance figures are vendor-reported.