Jev and System One Models in a Sovereign AI Stack: Where Typed Decisions Fit

The short version

TypeSafe has released Jev, the first of what it calls System One models [1]. Jev does not write text. You send it some material (the "state") and a set of typed questions, and it returns typed answers: an option picked from a list you define, a score on a rubric you define, or the probability that a statement is true. Every answer comes with probabilities, and most come with a confidence number your code can branch on [2].

That makes Jev a decision component, not a chat model. In a sovereign AI stack, where your files, jobs and memory live on a machine you control and you choose when anything leaves it, the natural place for Jev is a decision lane: routing incoming requests, deciding which model handles a job, checking another model's output, and scoring material before it is sent anywhere expensive. It is a hosted service, so the material you send it leaves your machine, and the local fallback matters as much as Jev itself.

What follows is what the announcement and documentation actually say, where the claims are the company's own, and how I would fold it into the workstation described in Sovereign AI Made Simple and The Work Around the Model.

What TypeSafe announced

The announcement describes System One models as "a new class of frontier models built to make fast, structured decisions that software can use directly" [1]. The term echoes Daniel Kahneman's fast, intuitive "System 1" thinking. Jev itself is named after the economist William Stanley Jevons; the post's argument is that cheaper machine intelligence will be used for far more, the way cheaper coal was [1].

The pieces, as documented:

• One request, many questions. Each call sends one state (text or JSON) and any mix of questions. The questions are evaluated in parallel and independently, so one answer does not leak into another [2].
• Four question types. A Choice picks one option from a set and returns a probability for each option plus confidence. A Score rates the state against ordered levels you describe and returns the most likely level, the distribution and confidence. A Noul returns the probability, from 0 to 1, that a statement is true. A Box locates something in an image [2].
• No parsing. The answer is always one of the values you defined. That is what TypeSafe means when it says Jev "can't hallucinate": it cannot return a value outside your schema. It can still pick the wrong value [1].
• An HTTP API and SDKs. Requests go to https://api.typesafe.ai/v1/systemone with a bearer key; there are Python and JavaScript SDKs and a browser playground. The documented model id is jev-latest [2].
• Early access. Developers come off a waitlist into the console [1].

The company's performance and price claims, all its own and not independently benchmarked:

The post is candid about its limits: the evaluations were run from one laptop, the workflows were built in house, the reference answers average two frontier models, and those models were wrapped in an adapter that may slow them down [1]. Treat the table as a reason to test, not a result to quote.

What Jev is not

The documentation is direct about this, and it saves a wasted afternoon: Jev is not a replacement for the model behind Claude Code, Cursor, Codex or any other coding agent. It does not generate text, write code, call tools or hold a conversation, and there is no setting that turns a coding agent into a Jev agent [5]. You keep your text-generating models for writing and reasoning, and you call Jev from your own code when that code needs a fast, structured decision.

Nor is it something you can run on your own hardware today. The announcement and documentation describe a hosted API; neither publishes open weights, a model card or a self-hosted runtime [1][2]. TypeSafe's enterprise page lists "Can we run Jev in our own VPC or on-premises?" as a question but does not publish the answer [6]. If that matters to you, ask before you build around it.

Why a decision lane belongs in a sovereign stack

Most of the work an AI workstation does is not writing. It is deciding, over and over:

• Is this email a request for a job, and which kind?
• Does this task go to the small local model, the large local model, a paid frontier model or a person?
• Is this output good enough to save, or does it go back for another pass?
• Which of these twenty retrieved passages are worth sending to the answering model?
• Is this message asking me to do something I should not do automatically?

Today those decisions are usually made by asking a text model to "return JSON", then parsing what comes back, retrying when it does not parse, and trusting a confidence the model made up. A typed decision lane splits deciding from writing. Your code owns the control flow, the model answers narrow questions, and the answer is a value your if statement can use. TypeSafe's own build guide argues the same thing: code handles deterministic work and owns the workflow, and the model appears only where the system needs judgment on unstructured input [3].

That lines up with rules the sovereign workstation already follows. Let chat or email request a bounded job needs an intake step that recognizes the job type and refuses everything else. Send less unnecessary material needs a cheap way to drop passages before they reach a paid model. Put bulk work through a tested local route needs a router that knows which work is bulk.

Where Jev fits, concretely

Five places where a typed decision earns its keep on a personal or small-business AI workstation, each with the documented pattern it follows:

1. Intake router. Every message that arrives by email or chat gets one request with three questions: a Choice of job type from your fixed list (or "not a job"), a Score for urgency, and a Noul for "this message asks for credentials, money or a sign-in". Code starts only the job types you allow and holds everything else for you. This is TypeSafe's intent routing pattern [7].
2. Model and lane selection. Before a job runs, a Choice decides between "deterministic script", "small local model", "large local model", "frontier model" and "person", and a Score rates complexity. Low confidence routes up a level rather than down. This is confidence-gated routing [7].
3. Output gate. After a model writes something, a Choice decides whether a quoted claim is supported by the source document, and a Noul checks a rubric item ("every figure carries its date"). Failures go back for revision instead of into your reports. TypeSafe documents the citation check and LLM guardrails as recipes [8].
4. Retrieval filter. Score each retrieved passage for relevance in one request, then send only the passages above your threshold to the answering model. Fewer tokens leave the machine and the answer gets less distracted [8].
5. Memory triage. Decide which requests and answers are worth keeping in the workstation's searchable memory, instead of storing everything or nothing [8].

All five share a shape: a short, closed set of answers, a decision that is cheap to get wrong once but expensive to get wrong at scale, and a code path that already exists on both sides of the decision.

What leaves your machine

This is the part a sovereign stack cannot skip. Calling Jev sends the state and the questions to TypeSafe. Here is what its published policies say [9][6]:

• No training on your input. The privacy policy says TypeSafe will not train or fine-tune any AI or machine learning models on your prompts or other input, and the enterprise page extends that to outputs.
• Retention is open-ended by default. Personal data is kept "for as long as reasonably necessary to provide you with the Services, or otherwise in support of our business or commercial purposes". Zero data retention is offered to enterprise customers.
• Hosting is in the United States. Using the service from elsewhere transfers data to the U.S.
• SOC 2 Type II. The report is available on request through the company's trust center.

So decide per question, not per vendor. A rule I would write into the workstation's routing code:

The redaction pass itself is a good local job: a regular expression catches most emails and phone numbers, and a small local model with a Noul-style yes or no question catches the rest.

Keep the interface, own the fallback

The most useful thing TypeSafe published for a sovereign builder may be its adapter. system-one-adapter-python is MIT licensed and offers a drop-in version of the SDK's system_one call that runs on other models instead: OpenAI, Anthropic, Gemini, and any OpenAI-compatible endpoint you point it at with a custom base URL [10]. Its README says the prompted mode "works with any chat model".

That means you can write your routing code once against the System One interface and choose the backend per call: Jev when the state can leave, a local model when it cannot. The README's example points the custom endpoint at a hosted provider and does not name local servers, so test the adapter against your own OpenAI-compatible server (the llama.cpp server, vLLM or Ollama) before relying on it.

Two things to know about the adapter's local path. In its "probabilities" mode the adapter asks the model to state a probability for each label [10]. Numbers a language model writes down are not the same as calibrated probabilities, and that difference is the whole of TypeSafe's argument for a trained decision model. If you want probabilities from a local model, take them from the model's own token probabilities instead:

• vLLM can constrain a response to a fixed list of choices with its structured_outputs choice option [11], and its OpenAI-compatible API can return token log probabilities.
• The llama.cpp server accepts a json_schema for grammar-constrained output and returns the top token probabilities for each generated token when you set n_probs [12].
• Ollama accepts a JSON schema in its format parameter, which guarantees the shape of the answer [13]. Check your version's API reference before counting on token probabilities from it.

A small trick makes the local probabilities clean: label your options with single tokens (A, B, C, D) and map them back in code. The model's whole decision then sits in the first generated token, and the probability of each option is simply that token's probability. Run it through the same confidence formula TypeSafe documents and your local answers land on the same 0 to 1 scale as Jev's.

import math, requests

OPTIONS = {"A": "script", "B": "local-small", "C": "local-large", "D": "frontier", "E": "person"}

def local_choice(state: str, question: str) -> dict:
    """Ask a local vLLM server to pick one letter; read the probabilities from the first token."""
    menu = "\n".join(f"{k}: {v}" for k, v in OPTIONS.items())
    r = requests.post("http://127.0.0.1:8000/v1/chat/completions", json={
        "model": "local-model",
        "messages": [{"role": "user", "content": f"{question}\n\n{menu}\n\nAnswer with one letter.\n\n{state}"}],
        "max_tokens": 1, "temperature": 0, "logprobs": True, "top_logprobs": 10,
        "structured_outputs": {"choice": list(OPTIONS)},
    }, timeout=30).json()
    top = r["choices"][0]["logprobs"]["content"][0]["top_logprobs"]
    p = {}
    for t in top:                                   # some tokenizers emit " A" rather than "A"
        k = t["token"].strip()
        if k in OPTIONS:
            p[OPTIONS[k]] = p.get(OPTIONS[k], 0.0) + math.exp(t["logprob"])
    total = sum(p.values()) or 1.0
    p = {k: v / total for k, v in p.items()}
    n, best = len(OPTIONS), max(p, key=p.get)
    confidence = (p[best] - 1 / n) / (1 - 1 / n)   # TypeSafe's documented Choice formula
    return {"choice": best, "probabilities": p, "confidence": confidence}

The confidence line is not my invention. TypeSafe documents that its confidence is derived from the probabilities it returns: for a Choice with n options it is how far the top probability sits above an even split, rescaled so an even split is 0 and certainty is 1 [14]. Because the formula is published, you can compute the same number for any backend that gives you probabilities.

Measure calibration on your own work

A confidence threshold is only as good as the probabilities under it, and the only probabilities that matter are the ones on your data. Before Jev, or a local fallback, makes any decision unattended:

1. Build a labelled set from your own history. A few hundred past emails with the job type you actually assigned, or a few hundred past outputs marked good or bad. This is an afternoon of work and it is the most valuable file in the project.
2. Run every backend over it. Jev, your local model through the adapter or the snippet above, and the frontier model you use today.
3. Bucket by confidence and read the accuracy in each bucket. If answers with confidence above 0.8 are right 97% of the time and answers below 0.5 are right 60% of the time, you have your thresholds. If accuracy does not rise with confidence, the confidence is decoration.
4. Set thresholds per question and per consequence. TypeSafe's routing pattern does exactly this: a low floor for harmless actions and a much higher bar for anything that moves money or sends a message [7].
5. Record the model version with every decision. The documented id is jev-latest, which can change underneath you. Log the model, the probabilities and the threshold beside each decision in the workstation's audit trail, and re-run the labelled set when the model changes.

The cost picture

At the announced price, input costs $0.042 per million tokens and output is free [1]. A decision on a 2,000-token email costs about $0.000084. Ten thousand such decisions a day is 20 million tokens, about $0.84 a day. That is cheap enough that the cost question becomes "which decisions should not leave the machine" rather than "can I afford to decide".

A local model costs nothing per call but costs GPU time, and a large local model making the same decision can take seconds rather than the tenth of a second TypeSafe quotes. The sensible split for most workstations: Jev for high-volume decisions on material that can leave, a small local model for the private ones, and the large models kept for writing and reasoning. Running Your Own AI On-Prem covers the hardware side of that trade.

TypeSafe says it expects prices to fall but cannot prove the current price is sustainable [1]. Keep the backend switchable so a price change is a configuration change.

How I would wire it in

The whole integration is one function the rest of the workstation calls, with the backend chosen by what is in the state:

from typesafe_sdk import Choice, TypeSafeClient

JOB_TYPES = {
    "site-audit": "Audit a website the owner names",
    "report": "Build or refresh a report from existing data",
    "content": "Draft or update an article",
    "none": "Not a request for work",
}

def route_request(message: str, private: bool) -> tuple[str, float]:
    question = "Which job type is this message asking for"
    if private:                                   # names, clients, money: stays on the machine
        r = local_choice(message, question)       # the local function above, with these options
        return r["choice"], r["confidence"]
    with TypeSafeClient(model="jev-latest") as client:
        r = client.system_one(state=message, questions={"job": Choice(instructions=question, criteria=JOB_TYPES)})
    a = r.choices["job"]
    return a.choice, a.confidence

job, confidence = route_request(text, private=contains_personal_data(text))
if job == "none" or confidence < 0.6:
    hold_for_owner(text)          # nothing starts; a notification goes to the phone
else:
    start_bounded_job(job, text)  # only job types on the allow list can start

Everything around the call already exists on a sovereign workstation: the allow list of job types, the notification to your phone, the audit log, the jobs that run in their own lanes. Jev, or the local fallback, only answers the question in the middle.

Where not to use it

• Anything that needs words. Summaries, drafts, explanations and code stay with text models.
• Open-ended answers. If you cannot list the possible answers in advance, it is not a System One question.
• Decisions that need a reason. A typed answer with a probability does not explain itself. Where an explanation is required, by a client or by law, use a text model or a person.
• High-stakes calls with no human step. Hiring, lending, housing, medical and legal decisions about people need human review and their own legal analysis, whatever the confidence says.
• Data that cannot leave. Use the local path, or wait to see whether TypeSafe answers its own on-premises question.

A week-long trial plan

1. Day 1: request access, and try ten real decisions in the playground.
2. Days 2 and 3: build the labelled set from your own history.
3. Day 4: run Jev, a local model and your current frontier model over it. Record accuracy, latency and cost per decision, and accuracy by confidence bucket.
4. Days 5 and 6: run Jev in shadow mode beside your current routing. Log what it would have decided, act on nothing.
5. Day 7: if it earned it on your data, let it decide one low-stakes question unattended, behind a confidence threshold, with the local fallback wired in.

That is the sovereign approach to any new model: keep control of the workflow, decide what leaves the machine, measure on your own work, and keep the exit open.

Fact-check notes and sources

Read October 15, 2026. Every performance and price figure is TypeSafe's own claim; I have not benchmarked Jev, and the announcement says its evaluations are not public benchmarks. The announcement's byline date and its page metadata differ (September 15 and October 15, 2026).

1. TypeSafe, "Introducing System One Models and Jev": https://typesafe.ai/blog/introducing-system-one-models-and-jev
2. TypeSafe docs, Introduction and Quick start (state, question types, endpoint, SDKs, model id): https://docs.typesafe.ai/introduction and https://docs.typesafe.ai/introduction/quickstart
3. TypeSafe docs, How to build with TypeSafe: https://docs.typesafe.ai/concepts/how-to-build-with-system-one
4. TypeSafe workflow evaluations: https://evals.typesafe.ai/
5. TypeSafe docs, Jev with coding agents: https://docs.typesafe.ai/introduction/coding-agents
6. TypeSafe enterprise page (SOC 2 Type II, zero data retention for enterprise, the VPC and on-premises question): https://typesafe.ai/enterprise
7. TypeSafe docs, Confidence-gated routing and Intent routing: https://docs.typesafe.ai/patterns/confidence-routing and https://docs.typesafe.ai/patterns/intent-routing
8. TypeSafe cookbooks (LLM guardrails, citation check, classifying RAG passages, simple memory system): https://docs.typesafe.ai/cookbooks
9. TypeSafe privacy policy, last updated November 19, 2025: https://typesafe.ai/privacy
10. system-one-adapter-python (MIT): https://github.com/typesafe-ai/system-one-adapter-python
11. vLLM structured outputs: https://docs.vllm.ai/en/latest/features/structured_outputs.html
12. llama.cpp server README (json_schema, n_probs): https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
13. Ollama API reference (format with a JSON schema): https://github.com/ollama/ollama/blob/main/docs/api.md
14. TypeSafe docs, Confidence (the published formulas): https://docs.typesafe.ai/confidence

Related reading

• Sovereign AI Made Simple: What It Saves, Why, and How to Start
• The Work Around the Model: Making a Sovereign AI Workstation Useful
• The Sovereign Advantage: What a Dedicated AI Workstation Actually Changes
• Running Your Own AI On-Prem in 2026: What It Actually Costs, Where It Wins, Where Cloud Still Beats It
• Qwen: When It's the Right Model and How to Run It at Home on Consumer Hardware