Jev and System One Models: Frontier Intelligence as a Function Call

On September 15, 2026, TypeSafe AI opened early access to Jev, its first System One Model, after two years in stealth. Jev does not generate strings. You send it an unstructured state plus a map of typed questions, and it returns typed probabilistic decisions: a probability of yes, a distribution over your options, a fractional position on your scale, each with a calibrated confidence. The company's one-line pitch: frontier intelligence as a function call.

This post collects what is actually useful from the launch essay, the official docs, the Workflow Evals site, the open-source reproduction OpenJev, and the day-of community discussion: what Jev is, how to call it, how to ask well, how confidence becomes system behavior, how to read the eval numbers with their discounts included, what the bill looks like, the eight jagged edges TypeSafe admits to, and a local implementation of the same idea you can run today.

What a System One Model is, and the two names inside the name

"System One" comes from Kahneman's fast, intuitive System 1 in Thinking, Fast and Slow. "Jev" comes from William Stanley Jevons, of Jevons paradox: when steam engines got more efficient, coal demand went up, not down. TypeSafe is betting the same happens to intelligence, one order of magnitude of cost at a time. Founder Diogo Almeida previously worked at OpenAI on the instruction-following and dialogue training methods that ended up behind ChatGPT.

The official definition is deliberately narrow: a frontier model built for fast, structured decisions that software can consume directly. It is neither a small model nor a distilled LLM. Training uses RLCD (reinforcement learning for calibrated decisions), on a new architecture with a hardware-aware parallel sampler, on fully self-made training data. There are no public benchmark scores by design, a stance the team calls antibenchmaxxing: standard benchmarks do not measure the task this model is built for.

Dimension	Existing LLMs	Jev (System One Model)
Training objective	RLHF (human preference) + RLVR (verifiable rewards)	RLCD: calibrated decisions, epistemically honest probabilities
Input	Unstructured text, emphasis on sequential messages	Unstructured text or structured program state
Output	Strings: flexible but must be parsed and validated, can go off the rails	Type-safe structured values; type errors are impossible
Sampling	Sequential autoregression, one token at a time	Parallel: one query produces every answer
Price	USD 0.20 to 10 per Mtok input, output about 5x input	USD 0.042 per Mtok input, output free
End-to-end latency	3 to 329 seconds	70 to 500 ms
Confidence	Tends to be overconfident and inconsistent	Calibrated per output: higher confidence means higher accuracy
Best at	Human-in-the-loop chat, copilots, coding agents; verifiable problems	Intelligent if-statements: classify, route, score, extract, guard; PB-scale map-reduce; realtime UX

The decisive difference is output shape. A string can be anything, including a hallucination. Jev's answers are constrained to the option set you provide, so its failure mode is "picked the wrong option among yours", never "emitted a value that does not exist". Your pipeline cannot crash on a parse error, which is the advantage; but the error looks perfectly normal and no parser will raise the alarm, which is the risk. We come back to that below.

Three primitives and one real request

Jev has exactly three question types, distinguished by the shape of the answer. Noul is yes/no: it returns the probability of yes, with no separate confidence field, because the probability is the answer. Near 0.5 means yes and no are even, not "moderately". Choice picks one option from your set and returns the pick, a probability per option summing to 1, and a confidence. Score places the state on your written levels and returns a possibly fractional score (1.3 means mostly level 1 with some level 2), a legend mapping level numbers to descriptions, per-level probabilities, and confidence.

One request can mix all three. Every question is evaluated against the same state, in parallel; adding questions costs almost no latency, only a few input tokens. There is a single HTTP endpoint:

POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": { "type": "noul", "instructions": "Does this convey urgency?" }
  }
}

Each question id comes back as a typed answer, plus usage. A Choice answer looks like this:

{
  "model": "jev-latest",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "probabilities": { "billing": 0.08, "technical": 0.85, "sales": 0.07 },
      "confidence": 0.82
    }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

The Python SDK (pip install typesafe-sdk, Python 3.10+) writes the same request as objects; the client reads TYPESAFE_API_KEY from the environment and defaults to jev-latest:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
ticket = "Hi, I've been trying to connect my Stripe account for 3 days..."

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(instructions="The message conveys urgency or time-sensitivity"),
    },
)

print(response.answers["department"].choice)   # "billing"
print(response.answers["frustration"].score)   # 1.035
print(response.answers["is_urgent"].noul)      # 0.999

The current version is jev-1.13.0; the aliases jev-latest and jev-preview both resolve to it. Official warning: aliases move with releases, so if you have tuned confidence thresholds against a version, pin the versioned id in the model field and migrate on your own schedule. Rate limits are 250,000 tokens per second and 1,200 requests per minute, and TypeSafe says plainly that limits will shift dynamically while early access demand is this large.

Asking well: the craft matters more than the model

One rule governs everything: each question should contain a single judgment that a knowledgeable person could answer at a glance. "Analyze this message and determine the best action" is a bad question; it needs slow thinking, and the fix is decomposition. Multi-factor judgments become atomic questions combined with weights in your code. The official resume-screening example scores four dimensions independently, then composes per role:

py      = response.answers["python_depth"].score / 4
lead    = response.answers["team_leadership"].score / 4
arch    = response.answers["system_design"].score / 4
general = response.answers["generalist"].score / 4

# Senior IC
ic_score = (0.40 * py) + (0.10 * lead) + (0.40 * arch) + (0.10 * general)
# Engineering Manager
em_score = (0.15 * py) + (0.40 * lead) + (0.20 * arch) + (0.25 * general)

The payoff is not only accuracy. When priorities change you edit coefficients in code instead of rewriting prompts, and the final ranking is fully inspectable.

The remaining rules come straight from the docs and cookbooks:

• When state is JSON, point at fields by dot path, e.g. "does ticket.messages[0].text request a refund?", so the model knows which slice to read instead of hunting through the whole state.
• Write levels as situations, not degrees. "Broken but a workaround exists" matches a state; "moderately severe" does not. On the same bug report, levels written as the bare numbers 0/1/2 produced a score of 0.57 at confidence 0.35; written as concrete situations, the judgment stabilized. Levels are judged independently and the model never sees the numbering, so relative phrasing like "worse than the previous level" is meaningless.
• Leave an "other / none of the above" option in Choice, or the model is forced to pick among wrong options.
• Use Score for grades, never Noul. A Noul of 0.5 means yes and no are even, not "medium".
• Ask every question at once, including speculative ones. Classify the ticket and score bug severity in the same call; if it is not a bug report, your code ignores the severity answer and you saved a round trip.

Parallelism is the economics

Jev ingests the whole state first, then processes all questions in parallel, so its context budget reads differently from other models: 64k tokens total for state plus all questions, and 32k for state plus the longest single question. The efficient usage is to pack the call. The official parallel-questions cookbook runs 13 questions (8 Noul, 2 Choice, 3 Score) over a pinned revision of the GDPR Wikipedia article: batching them into one call is about 12.2x cheaper and 10.0x faster than 13 separate calls, with identical answers. The quickstart page cites 11.5x and 9.6x for the same experiment, so "roughly 10 to 12x" is the honest summary.

Cardinality caps at 255 options. Beyond that, Jev switches to a two-stage scheme: score candidates independently, then choose explicitly, which is slower. The Wikiracing demo is the compounding case for non-hallucination at high cardinality, choosing among hundreds to thousands of links per step.

Confidence: turning uncertainty into system behavior

Confidence on Choice and Score is a statistic derived from the shape of the probability distribution: peaked means confident, spread means uncertain. TypeSafe calls this a default definition that is good enough for most cases and hands you the full distribution so you can define your own. They also note that if all you want is the best option, take the highest-probability one; thresholds are for risk policy, and real statistical algorithms should use probabilities rather than confidence.

The recommended shape is three bands: high confidence executes automatically; medium confidence proceeds with a confirmation, a review flag, or extra information; low confidence does not execute and routes to a human or an alternate path. The crucial sentence is that the threshold is not one number, it is layered by risk. The official voice-banking example:

action = response.answers["intent"]

if action.confidence < 0.6:
    route_to_support_agent(account_id)          # any action: below 0.6 goes to a human
elif action.choice == "check_balance":
    show_balance(account_id)                    # low stakes: 0.6 is enough
elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        approve_transfer(account_id)            # high stakes + high confidence: act
    else:
        ask_user_to_confirm("Just to confirm...")  # high stakes + medium: verify first
else:
    route_to_support_agent(account_id)

flowchart TD
  Q[Jev returns intent Choice with confidence] --> F{confidence below 0.6}
  F -- yes --> H[Route to human support]
  F -- no --> C{Action type}
  C -- check_balance --> B[Read the balance: low stakes]
  C -- approve_transfer --> G{confidence above 0.85}
  G -- yes --> A[Approve the transfer automatically]
  G -- no --> K[Ask the user to confirm first]
  C -- other --> H

A wrong balance read-out costs the user one more listen; a wrong transfer approval costs real money. Risk tolerance lives in your code, not in the model. The warning that follows is worth printing: where the threshold belongs depends on your domain and on how the model behaves on your task. Start conservative and measure on your own data.

Why that warning matters: on an open parallel-constrained-decoding model with the same calibrated-probability mechanism, we ran 30 gold-labeled decision evals and measured mean confidence 0.82 against accuracy 0.70; the subset at confidence 0.95 or above was only 72.7% correct. Jev is trained explicitly for calibration and should do much better, but copying someone else's thresholds is unreliable on any model.

Reading the evals: Pareto frontier and methodological discounts

TypeSafe built a new kind of eval. Instead of optimizing a labeled classification, and instead of letting harness and model vary together (which rewards harness overfitting), they assume a correct computation graph exists: the task is decomposed into Noul / Choice / Score questions plus code rules, and reference labels are the mean of the two strongest models available, GPT-6 Astra and Fable 5.1, both at high thinking, answering every question in the harness. Jev's numbers on the four workflows:

Workflow	Jev accuracy	Cost per case (USD)	Time per case
Security incidents	61.7%	0.0001	0.3 s
Agent trace observability	71.6%	0.0003	0.5 s
Invoice processing	61.8%	0.0011	0.5 s
Customer service next action	76.0%	0.0001	0.4 s
Four-workflow mean	67.8%	0.0004	0.4 s

For comparison: opus 5 in workflow form reaches 73.1% at USD 0.1761 and 37.8 s per case; sol 74.1% at USD 0.0836 and 23.3 s; terra 67.9% at USD 0.0304 and 10.1 s; luna 66.8% at USD 0.0033 and 12.9 s. Haiku 4.5 in workflow form manages 53.6%, and the same policy written as a single prompt collapses to 18.1% (58.8% versus 17.1% on the security workflow). Structure is always better holds for every model here, not just Jev.

TypeSafe labels its own biases: reference labels favor OpenAI and Anthropic and may understate Jev versus the DeepSeek family; the four workflows are outside Jev's training distribution but were authored by members of TypeSafe's capability team; LLM baselines run through TypeSafe's own System One wrapper, which constrains them into compatible structured decisions and is more accurate but slower and pricier than free-form output. The homepage claim of 193.6x faster and 444.6x cheaper comes from this eval, and the company concedes it is the optimistic end of real-world gains. Read the numbers with those discounts included.

The 0% column deserves a second look. It is not an empirical result; type safety holds by construction, which is why TypeSafe dares print zero. For decisions embedded in code, that property matters more than accuracy. One hallucinated tool call inside an agent is an inconvenience; buried under latency guarantees and several layers of dependencies, it is a disaster.

The bill: what intelligence costs per hour

Pricing is USD 0.042 per million input tokens (USD 42 per billion), output free, which TypeSafe describes as too cheap to meter. That is 238x cheaper input than Claude Fable 5.1. The concrete price feel comes from the Doom demo: ten queries per second works out to roughly USD 7 per hour. The engineer who built it was the one worried about the bill; the rest of the team concluded it was cheaper than expected.

Batching buys another order of magnitude: 13 questions in one call is roughly a 12x difference on the invoice. For a routing layer running a million judgments a day, that is the gap between "production" and "demo". TypeSafe is also candid that it cannot prove the pricing is unsubsidized; sustainability is a claim about the future, and they expect prices to fall rather than rise.

Eight jagged edges, self-reported (jev-1.13, reviewed 2026-09-16)

#	Failure mode	Official mitigation
1	Literal reading: answers the question you wrote, not the one you meant	State the exact condition in instructions, boundary cases in criteria; the explanation you give for a wrong answer is the missing half of the instruction
2	Math and counting: unreliable, error grows with size	Keep arithmetic in code; count by looping one Noul per item and summing yourself
3	Date and time comparison: dates are text, not ordered quantities	Let the model extract components (months, days, years are small closed sets, so use Choice with an explicit "not stated"), and let code own ordering, duration, offsets
4	Indirection: properties of properties, multi-hop questions lose accuracy	Write instructions directly; name the relevant slice of state
5	Large state full of irrelevant detail: distractors degrade accuracy	Retrieve and filter in code first; send only the fields the question needs, or filter with a Noul for relevance
6	Adversarial content: state is data and is not treated as hostile	Be explicit in criteria; test edge cases before deploying
7	Contradictory instructions and criteria	Treat criteria as an extension of the instruction and align the two; a Noul whose true maps to no performs measurably worse
8	Generation: it does not generate text	Use a generative model, or enumerate the generation space as a Choice

The code sample for edge 2 is worth copying verbatim: ask one "is this a fruit" Noul per list item and sum the thresholded answers in code, so counting never touches the model. And do not use Score expectations to interpolate exact magnitudes between levels; the numeric calibration of levels is weak, and the expectation is only good for threshold checks.

OpenJev: walking the same path on your own machine

While the waitlist moves, the same idea is runnable locally. OpenJev (MIT) fine-tunes Qwen3.5-4B into an NLI cross-encoder: given a premise and a hypothesis it returns probabilities for entailment, contradiction, neutral. That single primitive is enough to rerank answers, grade them against a reference, guard content, and play games in realtime: feed the game state plus a few statements about it, and the argmax entailment is the move. Doom is played zero-shot, first from text state and then straight from pixels through the Qwen3.5 vision tower; Flappy Bird likewise. Nothing is trained per task.

from modeling_openjev import OpenJevCrossEncoder
jev = OpenJevCrossEncoder("AlexWortega/openjev", subfolder="qwen3.5-4b-nli")

jev.predict([("The bird is 0.05 below the centre of the gap.",
              "The bird is below the centre of the gap.")])
# -> probabilities over [contradiction, entailment, neutral]

jev.rerank("Which gas do plants absorb during photosynthesis?",
           ["oxygen", "carbon dioxide", "nitrogen"])
# -> index of the option with the highest entailment

It is not Jev: no calibration training, no parallel sampler, and cardinality and latency in a different league. But it is currently the only open implementation where the full loop, decision primitives plus a realtime control loop, closes on local hardware, which is enough to validate interface shape, harness structure, and your own threshold policy.

What this means for agent and robotics harnesses

Placed back into agent engineering, Jev is not competing for the LLM's job. It competes for the slots in the harness where calling a frontier model every time is too slow and too expensive: should this trajectory get human review, is this tool result compliant, does the perceived state satisfy a precondition, which discrete action applies to this frame. Those judgments share a shape: input already available, options enumerable, latency sensitive, volume enormous. That is exactly the System One target.

Robotics feels this most. Semantic judgments inside control loops, such as "is the object stably grasped", "does the instruction ask for placement", "is this scene hazardous", were previously either brittle hand rules or a VLM call costing hundreds of milliseconds at best. Models like Jev offer a third path: write the judgment as atomic questions, feed probabilities into code, layer thresholds by risk, and let the execution layer see only typed values. OpenJev's Doom and Flappy Bird runs show the loop closing zero-shot; what remains is calibration and latency.

Equally important is what it does not do. Long-chain reasoning is not its job, generation is not its job, counting and date arithmetic are not its job. It is System 1; slow thinking still belongs to System 2. The official composition is intent routing: Jev stands in front as a fast classifier and dispatches each request to deterministic logic, a specialist LLM, or a human.

Pre-launch checklist

1. One atomic judgment per question; decompose multi-factor calls and combine with weights in code, kept in one reviewable file.
2. Levels as situations, not degrees; an "other" option in every Choice; Score for grades, never Noul.
3. Pack all questions, including speculative ones, into a single call; filter state before sending.
4. Counting, dates, and arithmetic stay in code; the model only extracts and judges.
5. Layer confidence thresholds by action risk; start conservative and measure on your own gold data before relaxing.
6. Pin the versioned model id when tuning thresholds; use aliases only for experiments.
7. Monitor for the silent failure class, wrong option among yours: type safety means no parser will alert for you.

Compiled from the TypeSafe AI launch essay and official docs, the Workflow Evals site, the OpenJev model card, and yibie's day-of measurements on X; all cost and latency figures are quoted from those primary sources.

• Launch essay: Introducing System One Models and Jev
• Docs: docs.typesafe.ai (primitives / api / confidence / patterns / model-jaggedness)
• Workflow Evals: evals.typesafe.ai
• Open-source adapter: typesafe-ai/system-one-adapter-python; agent skill: typesafe-ai/skills
• OpenJev: huggingface.co/AlexWortega/openjev
• Day-of discussion and measurements: yibie on X