What Is Jev? TypeSafe’s System One Model for Typed AI Decisions

Jev is TypeSafe AI’s first System One model. You send it unstructured state — a ticket, a retrieved chunk, an agent trace — and it returns typed probabilistic decisions your code can branch on. It does not write the customer-facing reply.

Read this if you are wiring routing, triage, or guardrails and need a schema-bound decision instead of another generated paragraph. Guzli wrote this page; TypeSafe did not commission it. Guzli sells a chat-and-phone support agent and does not license, host, or resell Jev. This is a desk-research explainer of TypeSafe’s public docs, not an independent product review. There is no Guzli trial, demo, or plan picker on this page. It explains Jev’s typed primitives — not chatbot vs AI agent and not AI in customer service.

TypeSafe opened early access in mid-September 2026. Founder Diogo Almeida (TypeSafe; previously at OpenAI on instruction-following work that became the research behind ChatGPT) announced it in Introducing System One Models & Jev (15 September 2026). We read that post, docs.typesafe.ai, and the models page (checked 19 September 2026). We did not call the API or independently meter the 70–500ms / $0.042-per-million claims.

What a System One model does

TypeSafe defines System One models as models built for fast, structured decisions that software can consume directly. The official phrasing is unstructured state in, typed probabilistic decisions out. Jev is the first public model in that class.

TypeSafe named Jev after economist William Stanley Jevons. In the same announcement, TypeSafe says the class name draws on Daniel Kahneman’s distinction between fast System 1 judgments and slower System 2 reasoning. That is TypeSafe’s naming story, not a Kahneman trademark.

Jev currently accepts text: strings, JSON objects, and arrays of text. Images, audio, and video are not supported. It does not write replies, produce code, or generate explanations of its reasoning. You define the possible answers before the call.

How that differs from LLM structured outputs

The usual alternative is a generative model with JSON mode, a schema, or function calling: you still pay for tokens of prose (or constrained tokens that look like prose), then parse and validate. TypeSafe’s launch post is explicit that existing LLMs can emit type-safe values, but “to be used by software, responses need to be parsed + validated” and “there is also always some risk that the AI goes off the rails.”

TypeSafe also ships a System One LLM wrapper that constrains other models to the same decision API. The launch post says that wrapper is “the most accurate way to get decisions from LLMs,” and that it “tends to be slower and more expensive than giving decisions without probabilities.” Jev is the native model for that API: parallel answers, no string generation, probabilities on every question.

That is the useful contrast. Jev is not “JSON mode but cheaper.” It is a model that only answers questions you predefined. You still need an LLM when the user needs a paragraph. You still need code when the answer has to be right, not merely well-typed.

Choice, Score, and Noul

TypeSafe’s primitives docs describe three question types. You can mix them in one request. Docs say every question evaluates in parallel against the same state.

A Choice cannot emit a department that is not in your criteria. That is schema safety. The model can still pick billing when the ticket belongs on technical. TypeSafe’s primitives guidance is to add an other or none of the above option when the set might not cover every input — otherwise the model is forced into the closest listed option.

A Noul of 0.5 means yes and no are equally likely. It is not a “medium” amount of the thing you asked about. If you wanted a spectrum, use Score.

Ask one snap judgment per question. TypeSafe’s guidance is to split a compound call (“what should we do with this ticket?”) into independent questions — intent, urgency, refund requested — and combine the answers in code.

How you call Jev

The documented HTTP endpoint is POST https://api.typesafe.ai/v1/systemone with Authorization: Bearer <API_KEY>. The model id used in TypeSafe’s docs and SDK defaults is jev-latest (an alias; the models page currently points it at jev-1.13.0). If you tune thresholds on a version, TypeSafe says to pin that versioned id; aliases move when a release ships.

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payments, invoicing, refunds",
        "technical": "Bugs, outages, integrations",
        "sales": "Pricing, upgrades, new accounts"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "Does this convey urgency?"
    }
  }
}

TypeSafe’s API reference shows answers under the same ids. A Choice looks like this (their example, not a call we ran):

{
  "model": "jev-latest",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "probabilities": { "billing": 0.08, "technical": 0.85, "sales": 0.07 },
      "confidence": 0.82
    },
    "is_urgent": {
      "type": "noul",
      "noul": 0.92
    }
  }
}

The surrounding program owns thresholds, retries, and side effects. Docs list 401 (bad key), 422 (malformed question), 429 (rate limit), and 529 (overloaded). Models currently publish 1,200 requests per minute and 250,000 tokens per second, and say those limits can change without notice while they ramp access.

The models page also sets the token budget: 64k per request; 32k for state plus the longest question. English is the primary training language; TypeSafe says to test other languages on your own content.

Why one compound question is the wrong call

TypeSafe’s primitives guidance is to ask one snap judgment per question. Treat that as a routing contract, not a slogan.

A single Choice — “what should we do with this ticket?” — with criteria like auto_refund, page_oncall, and send_to_sales hides three decisions: intent, urgency, and action. Schema safety still holds. The model still cannot emit a fourth department. It can still pick auto_refund on a payouts outage that belongs on technical, because “payouts” sits next to billing in the criteria text.

Split it the way the sample does. department is a Choice. is_urgent is a Noul. Code then decides: if department.choice == "billing" and is_urgent.noul is above your threshold, page finance; if confidence on department is below your bar, assign a human. TypeSafe’s confidence docs treat that bar as yours. A 0.8 is not an industry SLA.

That is the difference between “Jev routed the ticket” and “our program routed the ticket using Jev’s typed fields.” The second is what the API is for. The first over-claims TypeSafe’s launch-post line that Jev is “optimized for structured outputs and can’t hallucinate.” That wording is about type errors, not about picking the right option (launch post).

Speed and price TypeSafe publishes

Treat the following as TypeSafe claims, not independent measurements.

On the launch post, TypeSafe says end-to-end response time is about 70–500ms, input is about $0.042 per million tokens, and output is free / “too cheap to meter.” TypeSafe also writes that it cannot prove the price is not subsidized, and that it expects the price to go down, not up. The models page lists the same input price for Jev 1.13.

For TypeSafe’s own workflow evals, read the launch post and the eval materials TypeSafe links from there. This article does not repeat third-party benchmark scores or the homepage Pareto multiples.

Schema-safe versus factually correct

TypeSafe’s launch post says Jev is “optimized for structured outputs and can’t hallucinate” and that type errors are mathematically impossible because outputs stay inside your schema. That is a claim about the shape of the answer.

The model can still pick the wrong option, score the wrong chunk, or miss a jailbreak. TypeSafe’s confidence docs treat confidence as a statistic derived from the probability distribution. You draw the thresholds in your own code, on your own data. A 0.8 on your refund Choice is not a published industry standard.

TypeSafe’s jev-1.13 jaggedness notes (reviewed 17 September 2026) add failure modes you should design around: literal reading of instructions, weak math and date arithmetic, extra hops of indirection, large state full of unrelated detail, and adversarial text in the state that can steer the answer. The same note shows a Noul and a yes/no Choice on the same refund question returning different numbers — do not carry a threshold tuned on one primitive onto the other. Keep arithmetic and date math in code. Send only the fields the question needs.

Documented TypeSafe patterns

These are TypeSafe patterns and cookbooks — workflows developers assemble — not claimed customers of any support product.

Support and email triage

TypeSafe’s intent-routing pattern puts a Choice in front of the expensive work. Classify the inbound email or ticket (order status, return, complaint, billing), score complexity or frustration, and ask a Noul for urgency. Code then sends the case to a lookup, a specialist LLM, or a human queue.

The same shape shows up in TypeSafe’s customer-support examples: issue type, product area, refund requested, churn-risk language. The model does not draft the reply. It picks the path.

Confidence-gated human escalation

Confidence-gated routing uses the answer as “what” and confidence as “whether to act.” High confidence on a low-stakes Choice (show order status) can run automatically. The same confidence on a refund or chargeback Choice should hit a higher bar, or a person.

TypeSafe’s docs use a three-path sketch: act, proceed with a confirm, or refuse to act. Where you draw those lines depends on the cost of being wrong. Start conservative and tune on labeled tickets.

Score retrieved passages before an LLM writes

Retrieval still produces candidates. Jev can score each passage against the question before a generative model writes. TypeSafe’s classifying RAG passages cookbook keeps chunks that answer the question, flags contradictions, and drops passages that look like a hidden instruction.

That split matters: the LLM writes from a shorter, scored context. Code decides which scores are high enough to enter the prompt. Schema safety does not mean the top-scored chunk is actually relevant; you still evaluate the rubric on your corpus.

Prompt-injection, personal data, and policy guardrails

TypeSafe’s LLM guardrails cookbook screens messages going into and out of an LLM. Typical questions: is this a jailbreak attempt, does the output expose personal data (often called PII), how severe is a policy violation. You threshold the probabilities and choose pass, review, block, or re-route.

Jev can miss a clever injection. TypeSafe’s jaggedness note is explicit that adversarial content in state can move the answer. Pair the model with tests on your own attack set, not a single Noul you never measure.

Agent continue-or-stop

An agent loop needs a cheap stop condition. TypeSafe’s cookbooks use Jev to decide whether a turn needs a skill at all, which closed-set tool to call, or whether to halt. Skill suggestion ranks candidate skills and can reject all of them. Function calling maps a natural-language request onto ordinary typed functions.

Code owns the loop: continue, call one tool, ask a person, or stop. Jev does not run the tool.

Model routing: an LLM writes, Jev scores, code acts

TypeSafe’s use-case map lists model routing and “harness engineering”: classify intent and difficulty, send only some prompts to an expensive LLM, then score the draft (citation support, policy, groundedness) before you ship it.

The useful sequence is write → score → act. Jev does not replace the writer. It sits beside it so your program can drop a bad draft, escalate, or pick a cheaper model for the next hop.

Batch classification

Because questions run in parallel and TypeSafe prices input tokens cheaply (its claim), the same primitives show up on corpora: ticket dumps, traces, listings, filings. TypeSafe describes this as map-reduce over large text: classify, detect, score, then let code aggregate.

Hierarchical classification walks a taxonomy with Choice probabilities. Parallel questions packs many independent judgments into one call. Batch work still needs a gold set. Schema-valid labels can be systematically wrong.

Real-time action selection

TypeSafe’s 70–500ms claim is the reason System One shows up in UIs and tight loops: pick the next action from a closed set while the user is still on the page. The launch post’s Doom demo is TypeSafe’s own real-time example (structured game state in, action Choice out), not a production customer case.

A generated sentence still needs an LLM. A closed set of eight next commands is the shape TypeSafe built Jev for.

When Jev is the wrong tool

Do not use Jev to draft the email, the chat bubble, or the knowledge article. You still need a generative model or a template for language.

Do not use Jev for images, audio, or video — TypeSafe says input is text only (strings, JSON, arrays of text).

Do not keep arithmetic, date math, or counting in the model. jev-1.13 jaggedness notes call those failure modes. Put them in code.

Do not treat schema safety as a correctness proof, or a jailbreak/PII Noul as a security control you never test. TypeSafe is explicit that adversarial text in state can steer the answer.

Access is early. TypeSafe says it is bringing developers off a waitlist. Input price is TypeSafe’s claim (~$0.042 per million tokens on the launch post and models page); TypeSafe writes that it cannot prove the price is not subsidized.

If you wanted a storefront widget and a store number, this is the wrong page.

FAQ

Does Jev write the customer-facing reply?+

No. You send unstructured state and get typed probabilistic decisions. It does not write replies, produce code, or generate explanations of its reasoning. You still need a generative model or a template for language.

Is a schema-safe answer the same as a correct answer?+

No. TypeSafe’s launch post says type errors are mathematically impossible because outputs stay inside your schema. The model can still pick the wrong option, score the wrong chunk, or miss a jailbreak. A 0.8 confidence is not a published industry standard — you draw the bar in your own code.

What is Noul, and is 0.5 a medium score?+

Noul is TypeSafe’s yes/no question. The answer is a probability from 0 to 1, with no separate confidence field. 0.5 means yes and no are equally likely. It is not a “medium” amount of the thing you asked about. If you wanted a spectrum, use Score.

Should I pin jev-latest?+

The documented default is the jev-latest alias, which the models page currently points at jev-1.13.0. If you tune thresholds on a version, TypeSafe says to pin that versioned id; aliases move when a release ships.

What to do next

Use Jev when you can name the options before the call and your code will branch on Choice, Score, or Noul. Stay on an LLM when the customer needs a paragraph, or when you only need structured JSON and already accept generative-model latency. Split compound questions. Draw confidence thresholds on your own labeled tickets, and pin jev-1.13.0 (or whatever you tuned) if those thresholds matter. Read TypeSafe’s jaggedness note before you put refunds or jailbreak checks in production.

Sources (checked 19 September 2026)

• Introducing System One Models & Jev — TypeSafe, 15 September 2026 (70–500ms and $0.042/M input are TypeSafe’s claims; LLM wrapper vs native Jev)
• TypeSafe docs — System One overview
• Primitives — Choice, Score, Noul; other option; Score can fall between levels
• API reference — POST /v1/systemone, Authorization: Bearer, answer shapes
• Models — jev-latest → jev-1.13.0; 64k / 32k budgets; $0.042/M
• Confidence — thresholds are yours
• jev-1.13 jaggedness — math, dates, adversarial state, Noul≠Choice