TypeSafe and Jev: how typed AI judgments are changing the way we use AI

Over the last six articles we have met the great AI chatbots — ChatGPT, Claude, Gemini, Copilot, DeepSeek. All of them are built to talk. But a huge share of what software actually needs from AI isn’t conversation at all. It’s tiny decisions: is this email urgent? Which team should get this ticket? Does this review mention a crash? How angry is this customer?

TypeSafe is a company built around that observation, and Jev is its model. Jev doesn’t write a single word. You give it some text and a list of typed questions, and it returns typed answers — a choice from your list, a probability, a position on a scale — with calibrated confidence, in about a tenth of a second, for a tiny fraction of a cent. This article explains why that is a genuinely different way of engaging AI, and how to build with it, from the first idea to production patterns.

The professor and the checkbox

Using a big chatbot for every small decision is like hiring a professor to tick checkboxes. It works — the professor is brilliant — but it’s slow, expensive, and sometimes, instead of a tick, you get an essay in the margin. Software then has to read that essay and hope to find a tick inside it. Developers call this pattern prompt-and-parse, and anyone who has built with it knows the pain.

The idea TypeSafe summarises in one sentence: let plain code do the steps, let Jev make the quick common-sense calls, and call a big AI only when you truly need writing or deep thinking.

How software talks to AI: a short history

For fifty years, the way programs use “intelligence” has swung between two poles: typed and reliable but narrow, or flexible and general but messy. System One models are an attempt to get both.

Classical machine learning — the spam filter in your inbox — already returned typed, calibrated answers, but every new task needed its own labelled dataset and model. Large language models removed that cost: describe any task in words and it works. System One models keep that flexibility while returning to typed, calibrated outputs.

System 1 and System 2

The name comes from psychology. In Thinking, Fast and Slow, Nobel laureate Daniel Kahneman described two modes of the mind: System 1, fast and intuitive — you recognise a friend’s face instantly — and System 2, slow and deliberate — you work out 17 × 24. TypeSafe’s documentation puts it simply: System One models are “a class of AI models built to make fast, structured decisions that software can use directly.”

How Jev works

Everything happens through one endpoint, POST https://api.typesafe.ai/v1/systemone. You send two things: the state — the text or JSON to judge — and questions, a map of named, typed questions. Jev reads the state once and answers every question in parallel; the questions can’t see each other’s answers.

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "Help! My payouts have been failing for 3 days.",
    "questions": {
      "is_urgent": { "type": "noul", "instructions": "Does this convey urgency?" },
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing":   "Payments, invoicing, refunds",
          "technical": "Bugs, outages, integrations",
          "sales":     "Pricing, upgrades, new accounts"
        }
      }
    }
  }'

Three details matter. The question IDs (is_urgent, department) are for your code only and are never sent to the model, so the instructions must carry the full meaning. You pay only for input tokens — at the time of writing $0.042 per million, with output free. And the model version comes back in every response, so you can log exactly which model made each decision.

Choice, Noul and Score

Every question is one of three types — TypeSafe calls them primitives — and you choose by what the answer means:

• Choice — pick one from up to 255 options. Returns the choice, the probability of every option, and a confidence. Always include an “other” or “none” option when nothing may fit.
• Noul — the probability that a condition is true, from 0 to 1. Crucially, 0.5 means “can’t tell”, not “somewhat”. When several labels can apply at once, ask one Noul per label.
• Score — a position on 2 to 10 ordered levels, each describing a concrete situation. The answer is a probability-weighted position, so 1.4 means “between frustrated and furious, leaning frustrated”.

Calibration and confidence

The probabilities are the point. Jev is trained to be calibrated: across many predictions, things it gives 0.8 to happen about 80% of the time. That turns uncertainty into something code can act on — which a chatbot’s confident tone never can.

For Choice and Score answers, Jev also returns a confidence: how concentrated the probability distribution is. For a three-option Choice, TypeSafe’s docs give it as:

A practical way to use it is a traffic light: green, act automatically; amber, act but log; red, send to a person or a bigger model. Where to put the lines depends on what a mistake costs — a refund needs a higher bar than a folder label. Try it:

RLCD: training for trust, not charm

How do you train a model to be calibrated? TypeSafe calls its method RLCD — reinforcement learning for calibrated decisions — and positions it as a third kind of post-training, alongside the two behind today’s chatbots.

TypeSafe’s argument, from its machine-learning primer: RLHF — a technique its co-founder Diogo Almeida helped pioneer, according to TypeSafe — optimises for answers people prefer, and that can reward confident-sounding answers over honest uncertainty. In the primer’s words: “An output can be compelling to a person without being reliable enough for unattended automation. Human preference and machine trustworthiness are different optimization targets.”

Your first app, step by step

Let’s build what the guide builds: a support-ticket sorter that reads a customer message and decides the team, the urgency, whether a refund is requested, and how frustrated the customer is — in one call.

1. Sign up at console.typesafe.ai with Google or email.
2. Play first. In the Playground, paste a sample message as the state, add questions, and look at the answers. It is the cheapest place to get your wording right.

3. Create an API key at console.typesafe.ai/keys and save it permanently in your shell profile:

echo 'export TYPESAFE_API_KEY="paste-your-key-here"' >> ~/.zshrc
source ~/.zshrc

python3 -m venv .venv          # a private Python for this project
source .venv/bin/activate
pip install typesafe-sdk

Your first raw call returns something like this — a real run from the guide:

$ bash examples/first_call.sh | jq .
{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.99 },
    "department": {
      "type": "choice", "choice": "technical", "confidence": 0.78,
      "probabilities": { "sales": 0.0, "technical": 0.85, "billing": 0.15 }
    }
  },
  "usage": { "input_tokens": 376, "output_tokens": 57 }
}
# 376 input tokens × $0.042 per million ≈ $0.000016 — output is free

4. Ask every question in one call with the Python SDK:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

TICKET = "I was charged twice for my Pro plan this month. Refund one today please!!"

with TypeSafeClient() as client:            # reads TYPESAFE_API_KEY
    r = client.system_one(
        state={"ticket": TICKET},
        questions={
            "team": Choice(
                instructions="Which team should handle this ticket?",
                criteria={
                    "billing":   "Payment or subscription issues",
                    "technical": "Bugs or integration problems",
                    "sales":     "Pricing or account questions",
                    "other":     "None of the above",
                },
            ),
            "urgent": Noul(instructions="The ticket conveys urgency or time-sensitivity"),
            "refund": Noul(instructions="The customer asks for a refund"),
            "frustration": Score(
                instructions="How frustrated does the customer appear?",
                criteria=["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"],
            ),
        },
        model="jev-latest",   # pin a versioned ID once you have tuned thresholds
    )

5. Let code decide. Jev supplies judgments; your code owns the rules, in plain sight:

team = r.choices["team"]
urgent = r.nouls["urgent"].noul
frustration = r.scores["frustration"].score

queue = team.choice if team.confidence >= 0.5 else "human-review"
priority = "P1" if urgent > 0.8 or frustration >= 1.5 else "P2"
refund_flag = r.nouls["refund"].noul > 0.7

print(f"queue={queue} priority={priority} refund_flag={refund_flag}")
# queue=billing priority=P1 refund_flag=True   (sample output)

6. Test and tune. Run 20 to 50 real messages. Where answers are wrong, sharpen the wording or add a missing option. Set thresholds from your own results, then pin a versioned model ID so answers don’t shift under you.

Batching and cost

The guide explains the economics with a pizza: ordering thirteen toppings in thirteen separate deliveries means thirteen delivery fees. The document is the fee; the questions are the toppings. Since you pay for input, sending the document once with every question is far cheaper:

TypeSafe measured it: 13 questions about the ~54,000-character Wikipedia article on the GDPR came out 12.2× cheaper and 10× faster batched than as separate calls, with the same answers. Play with the numbers:

Six levers keep costs low, per the guide:

• 📦 Batch every independent question into one call, including speculative ones for branches you might take.
• ✂️ Trim the state to named fields — less to pay for, and less to distract the model.
• 💻 Code first: maths, dates, counting, regex and lookups cost nothing and never get it wrong.
• 👉 Select: code finds candidates, a Choice picks one — short, and no invented values.
• 💾 Store raw scores: change weights and thresholds later without paying again.
• 🪜 Cascade: cheap model first, Jev checks, the expensive model only when flagged.

The layered blueprint

Put it together and a well-designed AI application looks like layers, each doing what it is best and cheapest at:

For any single step, one question tells you which layer it belongs to:

Big LLMs still have a job. The guide pictures Jev as the receptionist who sorts every visitor in a tenth of a second, and the LLM as the specialist called only when someone needs a written reply. A “needs a written reply?” Noul decides; the LLM gets a focused prompt with Jev’s decisions already in it; and Jev can check the draft against policy before a person approves it. Because most traffic never reaches the specialist, even a rate-limited free LLM tier can go a long way.

Patterns that compose

TypeSafe’s docs describe these as “units of AI intelligence usable like programming primitives”. The interesting part is how they combine:

Real applications the guide lists include a smart inbox (folder, urgent, spam), app-review analysis (a sentiment Score plus one Noul per topic), search re-ranking (a relevance Score per result), invoice extraction (code finds candidate amounts, a Choice picks the total), fact-checking an LLM’s citations, guardrails on chatbot input and output, and résumé screening with a Score per skill weighted in code.

The Claude Code skill

You don’t have to design all of this by hand. TypeSafe publishes a skill for coding agents: a briefing that teaches the agent TypeSafe’s design rules and points it at the live documentation before it plans or writes any code. In Claude Code (see our Claude guide):

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

# other coding agents
npx skills add typesafe-ai/skills --skill typesafe-ai

Then invoke it with what you want. Prompts from the guide:

• /typesafe:typesafe-ai explore this project and find fragile parsing or if/else logic that a judgment could replace
• /typesafe:typesafe-ai build an App Store review analyzer: sentiment score + one noul per topic
• /typesafe:typesafe-ai check whether any cookbook matches my code and refactor it

Limits and mistakes to avoid

TypeSafe publishes a candid “jaggedness” page for each model version, listing where it is weak. Knowing these is what separates a demo from a system:

And the most common design mistakes:

• One call per question instead of batching.
• Reading a Noul of 0.5 as “medium” — it means “can’t tell”; use a Score for degree.
• Treating confidence as “chance it’s right” — it measures concentration; validate on your own data.
• Forgetting a “none of these” option, forcing a wrong pick.
• Copying thresholds from examples instead of tuning on real data.
• Using jev-latest in production — pin the version you tuned against.
• Putting the API key in front-end code — call Jev from a server only.

If these ideas seem familiar, they should: the prompting advice in our ChatGPT guide — be specific, give context, check the answer — still applies. TypeSafe’s twist is to make the answer itself something software can check.

Your 30-day path

From your first Playground run to a production pattern.

Quick quiz

Tap a question to check your answer.

Chatbots taught the world to talk to AI. Typed judgments teach software to use it — quickly, cheaply and with its uncertainty out in the open. Let code do the steps, let Jev make the calls, and save the big models for the work that truly needs them. ⚡

TypeSafe and Jev are products of TypeSafe AI; Claude Code is a product of Anthropic. This article is independent and not affiliated with or endorsed by either. It is based on the unofficial TypeSafe Easy Guide; model facts, prices, API and SDK shapes, the confidence formula, RLCD and the batching benchmark follow docs.typesafe.ai as of 24 September 2026. Claims about TypeSafe’s history are attributed to TypeSafe. The threshold data and big-LLM prices in the playgrounds are illustrative; screens are illustrations. Spotted something out of date? Tell us.