What Is TypeSafe AI in 2026?
TypeSafe AI is a company building what it calls System One models, and Jev is its flagship model and the first of that class. Instead of generating text, Jev takes some content you supply, called the state, plus a set of typed questions, and returns structured answers your code can act on directly: a chosen option, a score on a rubric you define, or a probability that a statement is true.
The framing TypeSafe uses in its own documentation is worth quoting because it explains the whole product. Large language models are designed to produce text for humans to read. When you need a model to make a judgment that your code will consume, that creates a mismatch: you are coercing a text generation system into outputting structured decisions, then parsing the results back into something your code can depend on. Jev removes that round trip. There is no text to parse, because there is no text.
Explain It Like I Am Five: What Does Jev Actually Do?
Think about a gymnastics competition. The gymnast finishes her routine. The judges do not write her a letter. They do not tell her a story about her routine. They hold up a card with a number on it.
A chatbot is the letter writer. You ask it something and it writes you paragraphs. That is lovely when a person is reading. It is annoying when a computer is reading, because the computer has to dig through the words to find the actual answer, and sometimes the words say something slightly different every time you ask.
Jev is the judge with the card. You show it something, like a customer email. You ask it a question, like "is this person angry?" It holds up a number. Not a paragraph. A number.
Jev can hold up three kinds of card. One card says which box to put something in, like "this email goes to the billing team". One card is a number on a scale you wrote yourself, like "anger: 1.4 out of 2". One card says how likely a yes is, like "0.95 yes, they want a refund".
And here is the best bit. Jev also tells you how sure it is. If it is confused, it says so, and your program can then go ask a real human instead of guessing. A helper who admits when it does not know is far more useful than one that always sounds certain.
Why Does TypeSafe Exist in 2026?
TypeSafe's bet, stated plainly in its AI primer, is that large scale automation will be dominated by AI to AI and AI to software interactions, so the machine interface matters more than the chat interface. The company estimates that large scale AI automation will be closer to 99 percent machine to machine interactions and 1 percent human interaction. It calls the goal Machine Native Intelligence: AI with software-like properties such as structure, reliability, observability, testability, speed, consistency, and low cost.
That shifts the design target. A chatbot is optimised for responses that feel good to read. A System One model is optimised for outputs that behave predictably inside software. TypeSafe summarises its own philosophy as "building prod, not God": it is not trying to build a model that does everything, it is built for production systems where code needs a narrow decision it can inspect and act on.
The training path is the concrete difference. TypeSafe describes three post-training approaches in 2026. RLHF, reinforcement learning from human feedback, turned pretrained models into chatbots by training them to produce responses people prefer. RLVR, reinforcement learning with verifiable rewards, created reasoning models that are strong at tasks such as mathematics but slower and more expensive. RLCD, reinforcement learning for calibrated decisions, is TypeSafe's path, and it trains the model to return decisions and calibrated probabilities instead of generated text.
TypeSafe also notes that RLHF was co-invented by Diogo Almeida, a cofounder of TypeSafe, and used to train InstructGPT and ChatGPT. The company's stated criticism of its own lineage is that preference optimisation can reward sycophancy and confident sounding hallucinations, and causes mode dropping, where the model learns to favour a particular style while reducing the probability of other possible outputs.
What Is a System One Model in 2026?
A System One model is a class of AI model built to make fast, structured decisions that software can use directly. It reads natural language like an LLM does, but it returns typed decisions and probabilities rather than generated text. TypeSafe states that System One models do not write replies, produce code, or generate explanations of their reasoning. You define the possible answers in advance.
The name is a nod to fast, intuitive judgment. TypeSafe describes the target as a gut-check determination: the kind of judgment a highly knowledgeable person could make in a few seconds given the right context. If a question would require extended reasoning or weighs several independent factors, the documented advice is to decompose it into separate questions and combine the results with logic in your code.
The properties that make this composable are listed in TypeSafe's own build guide and they read like a list of software virtues rather than model virtues.
| Property | What TypeSafe says about it | Why it matters in 2026 |
|---|---|---|
| Structured | Type-safe by construction; decisions and probabilities conform to the types and JSON schema your code expects | Your code never recovers a value from generated prose. |
| Parallel | Questions are evaluated independently and in parallel; one result does not become hidden context for another | You can add or remove questions without changing the other answers. |
| Comparable | Outputs are sortable and can drive if statements, thresholds, and comparisons | Ranking and routing become ordinary code. |
| Fast | Most queries complete in about 100 ms | Fast enough for a real-time request path or a user interface. |
| Calibrated confidence | RLCD communicates uncertainty through calibrated probabilities instead of tending toward overconfidence | Uncertainty becomes a value your code can branch on. |
| Self-consistent | Designed to return stable answers across repeated evaluations | The same input should not produce a different decision tomorrow. |
What Are the Three TypeSafe Primitives in 2026?
TypeSafe exposes three AI primitives, and every request is built from them. Each asks a different type of question and returns a different type of answer. All three can be mixed in a single API call, and every question is evaluated in parallel and in isolation against the same state.
| Primitive | The question it asks | What comes back | Example |
|---|---|---|---|
| Choice | Which of these options? | choice, probabilities, confidence | Which team should handle this ticket: billing, technical, or account? |
| Score | Which level on a rubric you define? | score, legend, probabilities, confidence | How frustrated is this customer, on a scale you wrote? |
| Noul | Is this statement true? | noul, a number from 0 to 1 | Does this message request a refund? |
Two properties of these answers make them composable, and TypeSafe states both explicitly. Every answer is constrained to the options you supplied, so the model returns a probability distribution over your options and never a value outside them. And every answer is independent, so one question's answer is not hidden context for another. Our deep dive on Choice, Score and Noul covers the configuration of each in detail.
How Does a TypeSafe Request Work in 2026?
Every call is a POST to a single endpoint with three fields: the state to evaluate, the model to use, and a map of questions whose keys you choose. The response returns one answer per question under the same keys you sent, plus the versioned model ID that answered and a token usage object. Here is the shape, taken from TypeSafe's own quick start.
POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json{
"state": "Hi, I've been trying to connect my Stripe account for 3 days
and the integration keeps failing. I'm losing sales.",
"model": "jev-latest",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this",
"criteria": {
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions"
}
},
"frustration": {
"type": "score",
"instructions": "How frustrated the customer appears",
"criteria": [
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language"
]
},
"is_urgent": {
"type": "noul",
"instructions": "The message conveys urgency or time-sensitivity"
}
}
}Three different question types, one request, one state sent once. TypeSafe's documented response to that exact request routes the ticket to technical at 0.85 probability and 0.78 confidence, scores frustration at 1.0 with confidence 1.0, and returns a noul of 1.0 for urgency, with usage of 392 input tokens and 65 output tokens.
The question IDs are yours and are never sent to the model. That detail matters more than it looks: it means you can name keys for your codebase's benefit without affecting the judgment. Our quick start tutorial walks through the same call in cURL, Python and JavaScript.
What Does Jev Cost and What Are Its Limits in 2026?
Jev 1.13 is priced per input token at 42 US dollars per billion tokens, which is 0.042 US dollars per million tokens, and output tokens are free. The published limits are 250,000 tokens per second and 1,200 requests per minute, with a 64k context window per request. TypeSafe warns that rate limits are adjusting dynamically and can change without notice.
| Attribute | Jev 1.13 (jev-1.13.0) |
|---|---|
| Price | 42 USD per Btok, 0.042 USD per Mtok, charged on input tokens only; output tokens free |
| Rate limits | 250,000 tokens per second and 1,200 requests per minute; over either returns 429 |
| Context length | 64k tokens per request; 32k for the state plus the longest single question |
| Input | Text only: string, JSON object, or array of text values. No image, audio or video input |
| Latency | Most queries complete in about 100 ms, per TypeSafe's build guide |
| Aliases | jev-latest and jev-preview, both currently pointing at jev-1.13.0 |
| Languages | English is the primary training language and where accuracy is currently best; other languages including CJK are handled but not equally well |
| Data handling | Not trained on customer requests or responses; zero data retention offered to enterprise customers |
The full arithmetic, the alias-versus-pinned-version decision and the 429 handling are covered in our pricing, limits and models guide.
How Does Jev Fit Into an Existing AI Stack in 2026?
TypeSafe positions Jev as a component inside software you already control, not as a replacement for your chat model or your coding agent. Its build guide contrasts three architectures: traditional software, where reliable primitives compose into a decision tree; LLM agents, where the model chooses its own next step and every loop is another chance to go off the rails; and AI-powered software, where code owns the control flow and the model appears only where the system needs programmable common sense.
In practice that puts Jev in four common positions in a 2026 stack.
- In front of an LLM as a router. Classify the request, then send it to deterministic code, a specialist model, or a person. TypeSafe's intent routing pattern is exactly this.
- Around an LLM as a guardrail. Screen every message going in and out with one request carrying several hazard questions, then threshold to pass, review, block or route.
- Inside a retrieval pipeline. Score or rerank candidate passages before the expensive answering model sees them.
- Replacing fragile parsing. Anywhere your code currently uses a brittle chain of string checks to infer meaning from text.
Note what Jev is explicitly not. TypeSafe states plainly that Jev is not a drop-in replacement for the LLM behind Claude Code, Cursor, opencode, Copilot or similar tools. There is no model setting that turns your coding agent into a Jev-powered agent. What you can do is install the official TypeSafe agent skill so your coding agent writes correct TypeSafe integrations for you.
What Is Jev Not Good At in 2026?
TypeSafe publishes a page it calls model jaggedness for Jev 1.13, listing nine known failure modes. That page is the most useful thing on the whole documentation site for anyone deciding whether to build on this, and reading it is the honest way to scope a first project. The summary is that Jev is fast, calibrated and good at common-sense judgment, but it can be quite literal, it struggles with numeric precision, and it does worse on tasks needing several layers of indirection.
| Documented failure mode | TypeSafe's recommended fix |
|---|---|
| Literal reading of your question | Write the exact condition; put boundary cases in the criteria |
| Math and counting | Keep the arithmetic in code |
| Date and time comparison | Extract the parts with the model, compare them in code |
| Indirection and double negatives | Reduce the hops; point the question at the relevant part of the state |
| Large state full of irrelevant detail | Filter first and send only what the question needs |
| Adversarial content in the state | Be explicit in the criteria and test edge cases before deploying |
| Contradictory instructions and criteria | Align the two with clear, precise language |
| Assumed structural invariants between questions | Do not carry a threshold from a Noul to a Choice, or expect arithmetic identities across questions |
| Text generation | Use a generative model; Jev is not trained for it |
One line from that page deserves repeating because it contradicts a habit many teams picked up from LLMs: Jev suffers from context rot, so unrelated material in the state costs you accuracy. Stuffing the context window is not a neutral act. Our state design guide covers this in full.
How Should You Start With TypeSafe in 2026?
The documented path is short, and it is deliberately ordered so that you learn the shape of an answer before you write any integration code. Signing in to the TypeSafe console is required for the playground and for an API key.
- Open the playground and paste real text as the state. Use something from your own product, not a sample, because you are testing whether the answers match your judgment.
- Add one Noul question. A yes or no question about that text. Read the number that comes back.
- Add a Choice and a Score in the same call. Watch that adding questions barely changes the response time. This is the single most important economic fact about the API.
- Get an API key and make the same call over HTTP. Then move to the Python or JavaScript SDK.
- Write down your thresholds in one file. TypeSafe's own advice on reviewing this kind of code is that the questions and threshold constants are what humans need to review, so keep them in a single place.
Where to Go Next: The Full TypeSafe Guide Series for 2026
This page is the overview. Each guide below goes deep on one part of the system, built from TypeSafe's official documentation.
- System One vs an LLM in 2026: why not just ask GPT for JSON, and what the two approaches actually differ on.
- TypeSafe AI quick start tutorial: your first call in cURL, Python and JavaScript, plus the first errors you will hit.
- Choice, Score and Noul explained: configuration, response fields, and how to pick the right one.
- Confidence and calibration: what calibration promises, what it does not, and how to set thresholds.
- Designing the state: shapes, the 64k and 32k budgets, and the context rot problem.
- The four architectural patterns: speculative fan-out, confidence-gated routing, composite scoring, intent routing.
- Pricing, limits and model versions: the cost arithmetic and the operational details.
- All 18 official cookbooks: what each one does and who should copy it.
- TypeSafe for marketing and growth teams: where this fits in a commercial workflow, and where it does not.
Glossary: TypeSafe Terms in 2026
| Term | What it means |
|---|---|
| System One model | A class of AI model built to make fast, structured decisions software can use directly. Jev is the first. |
| Jev | TypeSafe's flagship model. Current version jev-1.13.0. |
| State | The content you ask the model to evaluate, sent in the state field. |
| Question | One judgment to make about the state. Has an ID you choose, a type, instructions, and usually criteria. |
| Primitive | One of the three question types: Choice, Score, Noul. |
| Noul | A yes or no question type. Returns a single probability from 0 to 1 that the answer is yes. |
| Criteria | The possible answers: options for a Choice, ordered levels for a Score, optional true and false descriptions for a Noul. |
| Confidence | A 0 to 1 statistic derived from how peaked the probability distribution is. Present on Choice and Score, not on Noul. |
| Calibration | The property that a stated probability matches the real frequency of being right, measured across groups of predictions. |
| RLCD | Reinforcement learning for calibrated decisions, TypeSafe's post-training approach. |
| Btok and Mtok | A billion tokens and a million tokens, the units TypeSafe prices in. |
| Jaggedness | TypeSafe's own term for the published list of known failure modes for a model version. |
What Are the Common Mistakes With TypeSafe in 2026?
- Expecting it to write something. Jev returns decisions, not prose. If you need text, you still need a generative model.
- Asking one big question. "Analyse this message and determine the best course of action" is the documented example of a bad question. Decompose it.
- Filling the state because the window allows it. Accuracy falls as the state grows with content unrelated to the decision.
- Making several calls instead of one. Questions run in parallel in a single request. TypeSafe's own cookbook measured one batched call as 12.2 times cheaper and 10.0 times faster than 13 separate calls, with no change in the answers.
- Treating confidence as correctness. Calibration is a property of groups of predictions. A confident answer can still be wrong.
- Asking it to do arithmetic. Jev is not a calculator and does not count reliably. Keep the maths in code.
- Skipping the jaggedness page. Nine documented failure modes, each with a recommended fix. It is a 10 minute read that saves a week.
Key Takeaways for 2026
- TypeSafe AI builds System One models; Jev is the flagship and the first of the class, returning typed decisions instead of text.
- Three primitives: Choice for one of a set, Score for a level on your rubric, Noul for a yes or no probability. All three mix in one call and run in parallel.
- Every Choice and Score answer carries confidence derived from the probability distribution, so your code can act, ask, or escalate.
- Jev 1.13 costs 42 USD per billion input tokens with free output, has a 64k context window, and is text only.
- Most queries complete in about 100 ms, which puts it on a real-time request path.
- It is not a chat model, not a coding-agent model, not a calculator, and not a text generator. TypeSafe says all four plainly.
- Start in the playground with your own content, keep questions atomic, keep thresholds in one file, and read the jaggedness page first.
At Distk we work with teams across India and internationally on where a decision model belongs in a growth or operations stack, which judgments should stay in code, and where a human checkpoint earns its place. If you are scoping a first TypeSafe project in 2026, that mapping is where we start.