Jev explained: the AI model that returns decisions, not text.

Jev is an AI model from TypeSafe AI, launched on 15 September 2026. You give it some data and a few questions, each with its possible answers. It picks from those answers and gives you the probabilities. It writes no text at all. This post covers how it works, what the evidence says so far, where it breaks, and how to test it on your own data.

The if-statement you've already written

If you have shipped anything with an LLM, you have probably written something like this:

def is_urgent(ticket: str) -> bool:
    reply = llm.complete(
        "Is this support ticket urgent? Answer yes or no.\n\n" + ticket
    )
    # reply: "Yes, this looks urgent because the customer..."
    return "yes" in reply.lower()

The decision is a yes or a no. To get it, you asked a model built to write text, waited for it to write some, paid for every word, and then searched the words for "yes".

In production this grows a retry loop, a JSON parser and a validator. You will see that version below, next to the Jev one. Structured outputs fix most of the parsing. In my view they leave the harder problem alone: the model does not tell you how sure it is.

TypeSafe's launch post puts it plainly: "If a model can do a task 95% of the time but doesn't say when it's in the 5%, it can't automate that task." Asking the model for a confidence number does not fix this. When researchers asked LLMs how sure they were, the models overstated it. TypeSafe says the same: prompted for a confidence estimate, "models tend to be overconfident and inconsistent".

100 tickets, 95 answered correctly

Show the numbers

Group	Count of 100	Share
Answered tickets	100	100%

So someone still reviews every answer, and the task is not automated. That gap is what Jev claims to fix.

What Jev is: a form, not a reply

A request to Jev has two parts. The state is the data: a string, a JSON object or a list of texts. Text only, so no images, audio or video. The questions are what you want to know about it, each with its answers defined in the request.

Each question is one of three field types:

• Choice works like a dropdown. You list the options, and Jev picks one, with a probability for every option.
• Score works like a slider. You label the levels, and Jev places the answer on them. The score is the levels weighted by their probabilities.
• Noul is a checkbox. It returns the probability that a statement is true.

That is everything it can output. It does not write replies, produce code or explain its reasoning.

Isn't this a classifier? In part, yes. Classifiers have returned probabilities over labels for decades.

What TypeSafe says is new, is the mix: you write the labels in plain English with each request, and nothing is trained for your task. Its docs say Jev is "not fine-tuned or LoRA-adapted" and that "the same weights serve every account". My take: none of the parts are new, so judge it on how they fit together, and on the numbers.

The names come from psychology and economics. "System One" is Daniel Kahneman's term for fast, intuitive thinking. Jev is named after the economist W. S. Jevons.

One call, three questions

Here is the video's example: a billing complaint arrives in a support queue. The state is the message plus two account fields.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # reads TYPESAFE_API_KEY

ticket = {
    "message": "Second time I've been billed for the annual plan this "
               "month. Fix this today or I'm cancelling.",
    "plan": "annual",
    "charges_last_30_days": 2,
}

TEAMS = {
    "billing": "Charges, refunds, invoices",
    "technical": "Bugs, outages, integration problems",
    "account": "Login, profile, plan changes",
}
MOODS = [
    "Calm and matter-of-fact",
    "Annoyed but polite",
    "Angry or threatening to leave",
]

TEAM_Q = "Which team should own this message?"
ANGER_Q = "How upset is the customer?"
REFUND_Q = "The customer is asking for money back"

Then three questions go in one call:

1questions = {

21 "team": Choice(

32 instructions=TEAM_Q,

4 criteria=TEAMS),

53 "anger": Score(

6 instructions=ANGER_Q,

7 criteria=MOODS),

84 "wants_refund": Noul(

9 instructions=REFUND_Q),

10}

11result = client.system_one(

125 state=ticket,

13 questions=questions)

1. 1ChoicePick one of the listed teams, with a probability for each.
2. 2instructionsThe plain-English questions defined above. That is the whole prompt.
3. 3ScorePlace the answer on labelled levels: calm, annoyed, angry.
4. 4NoulThe probability that the statement is true: a yes or a no.
5. 5stateWhat Jev reads: the message and two account fields. Text or JSON, no images.

Three questions about one ticket, in one call. The questions are a form: each field says what shape its answer takes.

©LearnThatStack

The instructions and the options are plain English, and that is all the prompting there is. The same code works from JavaScript (@typesafe-ai/sdk) or over plain HTTP, and there are integrations for LangChain and the Vercel AI Gateway.

What comes back? TypeSafe's docs show a real response for a Score question about a bug report: "The export button crashes the settings page in Safari. It works in Chrome, but a few of our customers only use Safari."

{
  "model": "jev-1.13.0",
  "answers": {
    "bug_severity": {
      "type": "score",
      "score": 1.43,
      "confidence": 0.35,
      "legend": {
        "0": "Cosmetic; no impact to functionality",
        "1": "Broken or degraded feature, but workaround exists",
        "2": "Blocking issue; no workaround exists"
      },
      "probabilities": { "0": 0.0, "1": 0.57, "2": 0.43 }
    }
  },
  "usage": { "input_tokens": 332, "output_tokens": 18 }
}

That is a reasonable reading: there is a workaround, but not for everyone. Now look at the confidence. It is not the chance that the answer is right. TypeSafe computes it from how spread out the probabilities are, and here they split 57 to 43 between two levels. That low number is the useful part: it tells your code this answer is close to a coin toss.

Acting on the answers is ordinary code:

team = result.answers["team"]

if team.confidence < 0.5:
    send_to_human(ticket)
elif team.choice == "billing" and result.answers["wants_refund"].noul > 0.8:
    start_refund_review(ticket)
else:
    route(ticket, team.choice)

Jev's answers for a ticket

check 1Team confidence under 0.5?

yes

Send it to a personJev is unsure which team owns it

no

check 2Billing, and refund above 0.8?

yes

Start a refund reviewthe money path gets its own queue

no

elseRoute to the chosen teamthe everyday case

The routing code above, as the decisions it makes. Every branch is an if-statement on a number, not a parse of prose.

©LearnThatStack

Here is the same decision the old way, then with Jev:

An LLM makes the call

1for attempt in range(3):

21 reply = llm.complete(PROMPT + ticket)

3 try:

42 data = json.loads(reply)

5 if data["urgent"] in ("yes", "no"):

63 return data["urgent"] == "yes"

7 except (ValueError, KeyError):

8 continue

9raise ValueError("no answer after 3 tries")

Jev makes the call

1result = client.system_one(

2 state=ticket,

34 questions={"is_urgent": Noul(

4 instructions="The ticket needs a reply today")},

5)

6answer = result.answers["is_urgent"]

75urgent = answer.noul > 0.8

1. 1wait and payEvery token of the reply is generated, then billed as output.
2. 2parse and hopeThe answer arrives as prose or JSON you must check.
3. 3no idea how sureA yes is a yes. Nothing says which answers are shaky.
4. 4a question, not a promptThe answer can only be yes or no, with a probability.
5. 5a threshold you chooseThe decision is a comparison. The cut-off is yours to test.

The same decision twice. Structured outputs would already remove most of the parsing on the left. What Jev adds is the probability on the right: the number a threshold needs.

©LearnThatStack

Why it's fast: it writes no text

An LLM answers one token at a time, and a reasoning model writes its reasoning first. You wait for every token and pay for it as output. Jev skips generation. TypeSafe says it reads the state once, scores every question against it in parallel, and outputs probabilities over the options you listed.

LLM

read

reasoning tokens

answer tokens

Jev

one pass

Jev answers

LLM answers

• Jev one pass - reads the state once and scores every question together
• LLM reasoning tokens - a reasoning model writes these first
• LLM answer tokens - one token at a time, billed as output

Schematic, not to scale. An LLM writes its answer token by token. Jev reads the state once and scores each question over the options you gave it.

©LearnThatStack

TypeSafe's numbers follow from that design:

Jev's price and response time

Input price

$0.042

per million input tokens; output tokens are free

Response time

70 to 500 ms

end to end, plus your own network (servers are on the US West Coast)

For comparison, TypeSafe's launch post puts frontier models at 3 to 329 seconds end to end. With an LLM, output tokens cost about five times as much as input. Jev counts output tokens, 18 in the response above, but does not charge for them: the phishing benchmark's bill matched its input tokens alone. TypeSafe admits it "can't prove it isn't subsidized", and expects prices to "go down, not up".

Asking several questions in one call pays off twice. The questions are scored in parallel, so the call takes about as long as one question. And the state is sent once, so you pay for its input tokens once. TypeSafe's cookbook asks 13 questions about one long article, about 54,000 characters. The article is most of every request:

13 questions about one 54,000-character article

One call, all 13 questions

0.27 s

$0.000497

13 calls, one question each

2.71 s

$0.006090

That is about 10 times faster and 12 times cheaper, for the same answers. Most of the saving on the bill comes from sending the long article once, so with a short support ticket as the state it would be much smaller.

TypeSafe also shows Jev playing Doom at about 10 queries a second, for about $7 an hour. It reads the game state as text, not pixels, and TypeSafe notes that "a non-AI doom bot could play better". Treat it as a speed demo, not a skill test.

Calibration, the idea that makes it useful

A weather forecaster is calibrated if it rains on about 70% of the days they say "70% chance of rain".

Ten days forecast at "70% chance of rain"

Rained (7)Stayed dry (3)

Show the numbers

Group	Count of 10	Share
Rained	7	70%
Stayed dry	3	30%

TypeSafe trains Jev for that property. Its training method aims for "epistemically honest probabilities". If the probabilities are calibrated, then when Jev picks answers with a probability of 0.8, about 80% of them should be right.

100 answers whose chosen option had probability 0.8

Right (80)Wrong (20)

Show the numbers

Group	Count of 100	Share
Right	80	80%
Wrong	20	20%

Calibration is a statement about many answers, never about one. What it gives you is a number you can put a threshold on. Where you set the threshold decides what you automate and what goes to a person.

The confidence field is a different number. TypeSafe computes it from the shape of the probabilities: concentrated means confident, spread out means unsure. It is not the chance of being right: the Safari bug above had a top probability of 0.57 and a confidence of 0.35. What the launch post claims for it is an order: "higher confidence means higher accuracy".

Correction, 24 September 2026: the video goes from this calibration example straight to thresholds on confidence, which can make them sound like one number. They are different numbers: calibration is about the probabilities, and confidence only ranks answers.

Noul answers have no confidence field, since the probability is the answer. For the others, TypeSafe's docs suggest three ranges:

an answer and its confidence

check 1Above your high bar?

yes

Act automaticallythe common, clear-cut cases

no

check 2Above your low bar?

yes

Act, then flag or confirma person checks after the fact

no

elseDo not act: route it onto a person, or a bigger model

TypeSafe's suggested use of confidence. Where each bar sits depends on the cost of a mistake: showing a balance can act on less certainty than approving a transfer.

©LearnThatStack

The docs add: "Start with conservative thresholds, test with your own data." A confidence of 0.8 does not mean 80% right, so only your own data can show what a threshold buys you.

Update, 24 September 2026: two outside tests now touch calibration, and the larger one is unfavourable. On 2,000 synthetic phishing emails, the phishing benchmark found Jev's probabilities less calibrated than the probability Claude Haiku 4.5 wrote in its reply. The expected calibration error was 0.154 against 0.097, where lower is better. Jev was also worse at ranking phishing above safe email: an AUROC of 0.689 against 0.837, where 1 is perfect.

The smaller test is kinder. On 40 support tickets he wrote and labelled, Paweł Józefiak found accuracy rising with confidence, bucket by bucket. Jev's one routing mistake came with a confidence of 0.33, "the lowest score in the entire run". Neither test is a calibration study.

"Can't hallucinate" means the format, not the answer

The launch post says: "While Jev gives up string generation, it's optimized for structured outputs and can't hallucinate." Its charts of structured-output and tool-call error rates show Jev at 0%, and the notes under them explain why:

The first note says the LLM numbers came from OpenRouter, which may send harder queries to better models. The second says Jev's 0% was never measured: it is on the chart because the format is guaranteed.

So what is guaranteed is the format. Every answer is one of the options you listed, so Jev can't return broken output. Whether the answer is right is another matter, and a confidence of 1.0 can still be wrong. The format promise still helps, because nothing later in your pipeline breaks on a bad reply. But a wrong answer that is still a valid option gets through, and only testing on your own data shows how often that happens.

	LLM, structured output	Jev
format	matches your schema	one of your options
right answer	not guaranteed	not guaranteeda confidence of 1.0 can still be wrong
how sure	ask it, and it guessesself-reported confidence runs high	a probability per optioncalibration unproven
Rule of thumbOnly the format is guaranteed.

©LearnThatStack

TypeSafe's benchmarks: mid-pack accuracy, tiny cost

TypeSafe published four workflow evals: security incidents, agent traces, invoice processing and customer service. Each workflow splits a task into narrow questions, with code handling the logic. The LLMs ran through a probability adapter, which TypeSafe says tends to be slower and more expensive.

Read one line of the methods before any chart:

Accuracy here means agreeing with GPT-6 Astra and Claude Fable 5.1, not with people. TypeSafe's own team wrote the workflows and says "some bias could exist". The homepage's "193.6x faster, 444.6x cheaper" comes from this eval, and TypeSafe expects those gains to be "on the higher end" of what you will see.

On average Jev scores 67.8%, about the same as GPT-5.6 Terra and Claude Sonnet 5. The two best models, GPT-5.6 Sol and Claude Opus 5, score 74.1% and 73.1%. The gap in cost and time is much larger than the gap in accuracy:

Time and cost for one full workflow run

Linear scales, so Jev's bars are slivers

Show the numbers

Panel	Item	Value
Seconds per case	Jev	0.4 s
Seconds per case	GPT-5.6 Terra	10.1 s
Seconds per case	Claude Opus 5	37.8 s
Dollars per case	Jev	$0.0004
Dollars per case	GPT-5.6 Terra	$0.0304
Dollars per case	Claude Opus 5	$0.1761

Per case, Jev is roughly 100 times faster than Opus and 400 times cheaper. Against Terra, it is roughly 25 times faster and 75 times cheaper. The eval site rounds Jev's figures, so these ratios are approximate.

The average hides the spread. Here is each workflow:

Jev's accuracy in each workflow

Ranked against eight LLMs; the top model changes by workflow

Show the numbers

Panel	Item	Value
Security incidents	Claude Opus 5	66.2%
Security incidents	GPT-5.6 Sol	62.5%
Security incidents	Jev	61.7%
Security incidents	Claude Sonnet 5	60.8%
Security incidents	Claude Haiku 4.5	58.8%
Security incidents	GPT-5.6 Luna	52.1%
Security incidents	GPT-5.6 Terra	51.2%
Security incidents	DeepSeek V4 Pro	41.7%
Security incidents	DeepSeek V4 Flash	37.9%
Agent trace observability	GPT-5.6 Sol	76.6%
Agent trace observability	GPT-5.6 Luna	76.1%
Agent trace observability	Claude Opus 5	75.2%
Agent trace observability	DeepSeek V4 Flash	73.0%
Agent trace observability	GPT-5.6 Terra	73.0%
Agent trace observability	DeepSeek V4 Pro	71.6%
Agent trace observability	Jev	71.6%
Agent trace observability	Claude Sonnet 5	68.0%
Agent trace observability	Claude Haiku 4.5	57.2%
Invoice processing	GPT-5.6 Sol	79.1%
Invoice processing	Claude Opus 5	78.4%
Invoice processing	GPT-5.6 Terra	74.7%
Invoice processing	Claude Sonnet 5	72.9%
Invoice processing	DeepSeek V4 Pro	72.7%
Invoice processing	DeepSeek V4 Flash	69.8%
Invoice processing	GPT-5.6 Luna	67.8%
Invoice processing	Jev	61.8%
Invoice processing	Claude Haiku 4.5	42.9%
Customer service	GPT-5.6 Sol	78.3%
Customer service	DeepSeek V4 Flash	76.8%
Customer service	DeepSeek V4 Pro	76.1%
Customer service	Jev	76.0%
Customer service	GPT-5.6 Terra	72.7%
Customer service	Claude Opus 5	72.4%
Customer service	GPT-5.6 Luna	71.4%
Customer service	Claude Sonnet 5	69.3%
Customer service	Claude Haiku 4.5	55.4%

Jev ranks 3rd of 9 on security incidents and 4th on customer service. On agent traces it ties for 6th. On invoice processing it ranks 8th, at 61.8% against 79.1% for the best model.

TypeSafe does not explain that gap. The workflow already computes sums, dates, account numbers and statuses in code, so the gap is not down to simple arithmetic. It is the largest workflow by far, with eight kinds of documents and seven rounds of questions. Jev's cost per case there is $0.0011, against $0.0001 to $0.0003 in the other three. My guess: large inputs, questions that need several steps of reasoning, and some questions that still ask it to compare rates and prices.

Outside tests: speed holds, accuracy is mixed

Five outside tests are public so far. Every one that measured speed or cost found Jev far ahead on it. Accuracy is mixed.

In Mike Taylor's test for Every, Jev was 25 times faster than Claude Fable 5.1 and missed one planted defect that Fable caught. One passage proposed "a shared appointment calendar that parents and staff teach together." What would teaching a calendar mean? Fable flagged it. Jev missed it in all three runs.

The Vercel engineer's post attaches a card with his numbers. Keep in mind that Vercel is a partner: its CEO, Guillermo Rauch, wrote that Jev is "coming to @vercel AI Gateway and likely new default". And it is a post, not a benchmark with published data. Still, the numbers are specific:

The screenshot above cuts off before his numbers card, so here they are. Jev got 4 more right out of 210, and answered far faster, most of all in the slowest cases:

A safety classifier at Vercel: Jev against gpt-5.6-luna

210 decisions each; Jev got 207 right, gpt-5.6-luna 203

Show the numbers

Panel	Item	Value
Median response	Jev	312 ms
Median response	gpt-5.6-luna	1,458 ms
Slowest 5% (95th percentile)	Jev	374 ms
Slowest 5% (95th percentile)	gpt-5.6-luna	6,583 ms

Correction, 24 September 2026: the video says this benchmark was not published. His post on X does carry his numbers, shown above. It is still a post, not a full write-up with its data.

He also reports that Jev gave the same answer on all 3 runs for every case, while the LLM changed one answer. The phishing benchmark saw more change. When it ran the same 2,000 emails twice, 2.2% of Jev's verdicts flipped. Haiku's flipped 0.7% of the time, on a sample of 300.

Bryo AI's test ran the other way on accuracy, and found something more useful:

Jev was a little less accurate than two Gemini models, at a tenth of their cost or less. And 737 of its answers came with 99% or higher confidence, none of them wrong. That is the property you would set a threshold on.

The phishing benchmark is the most detailed of the five, and it caught Jev at its worst. When the author simply asked whether each email was phishing, Jev got 62.6% of 2,000 emails right, against 81.3% for Claude Haiku 4.5. The author then asked five narrow questions about warning signs, such as whether the link points to free hosting. A simple statistical model (a logistic regression), trained on half the emails, combined the answers:

Phishing: one broad question, then five narrow ones

Narrow questions lifted both models, and a rule with no AI came close

Show the numbers

Panel	Item	Value
Asked once, all 2,000 emails	Jev	62.6%
Asked once, all 2,000 emails	Claude Haiku 4.5	81.3%
Five questions, the held-out 1,000	Jev	95.0%
Five questions, the held-out 1,000	Claude Haiku 4.5	93.2%
Five questions, the held-out 1,000	URL rule, no AI	91.8%

On the emails it never saw, the combination of Jev's five answers scored 95.0%. Haiku, asked the same five questions, scored 93.2%, a gap the author finds not significant. And a two-line rule on the link, with no AI at all, scored 91.8%. The author wrote the questions after reading how the dataset was built, and says it "largely separates by construction". In other words, the way the emails were made keeps the two kinds easy to tell apart.

So this test does not show Jev beating an LLM. It shows what TypeSafe's evals show: narrow questions, with code combining the answers, lifted both models. Jev's edge is still the price: by the author's count, its five answers cost about 27 times less than Haiku's and came about 5 times faster.

Splitting the question helps every model

TypeSafe ran each LLM two ways: asked once in a single prompt, and split into a workflow of narrow questions with code doing the logic. Every model scored higher when split, usually by 5 to 15 points:

The gains ran from +5.1 to +14.9 points, and Claude Haiku 4.5 gained +35.5. Not every single run agreed: DeepSeek V4 Flash lost 6.7 points on security incidents, and DeepSeek V4 Pro lost 0.5 on agent traces.

One caution: this is one vendor's eval, and its reference answers came from two frontier models answering the workflow's own narrow questions. That setup favours the split runs. Still, the phishing benchmark found the same pattern independently, for Jev and for Haiku.

You can use this even if you never touch Jev. Narrow questions with the logic in code are easier for any model to get right, and easier for you to test.

Where it breaks, and the habits that help

TypeSafe keeps a page of known failure modes, with a fix for each. There are nine:

Three habits help with most of these. First, be literal. Jev answers the question you wrote, not the one you meant:

# Vague: Jev decides what "urgent" means
Noul(instructions="The ticket is urgent")

# Literal: the condition is spelled out
Noul(instructions="The service is down or they are losing money now")

Second, keep math and logic in code. If you already have the numbers, compare and count them yourself:

# Don't ask Jev: "Are more than three line items over $1,000?"
# You have the amounts. Compare and count in code:
over = sum(1 for item in invoice["lines"] if item["amount"] > 1000)
flag = over > 3

Third, ask each thing once. On the same ticket, TypeSafe's docs show "Is the customer asking for a refund?" at 0.72, and the negated question at 0.47:

Two questions that should add up to 1

Is the customer asking for a refund?

0.72

Is the customer not asking for a refund?

0.47

0.72 + 0.47 = 1.19

TypeSafe's warning: the two "may not be directly comparable". So ask one of them and derive the other:

refund = result.answers["wants_refund"].noul
not_refund = 1 - refund  # never ask the negated question separately

Before you build on it, know the limits (re-checked on 24 September 2026):

Should you try it: test on your own data

Many LLM calls in production are decisions: route this, flag that, is this spam. Those are the ones to try. If a person reads the output, or you can't list every possible answer, keep the LLM.

an LLM call you already make

check 1Does a person read the output?

yes

Keep the LLMwriting text is the job

no

check 2Can you list every answer?

no

Keep the LLMthe answer is open-ended

yes

check 3Is it math, dates or counting?

yes

Do it in codea known weak spot for Jev

no

elseA candidate for Jevnow test it on your own labelled data

Could the answer be a form field? Only calls that end in a decision from a list are worth testing.

©LearnThatStack

Where it fits, the design is always the same. Code prepares the data and does any math. Jev answers narrow questions. Your thresholds decide, and only the uncertain cases reach a person or a bigger model.

To find out whether it works for you, test it on data you trust:

1. Pick one decision your code already asks an LLM to make.
2. Collect a few hundred real examples, and label the right answer yourself.
3. Rewrite the call as narrow Jev questions, with any math in code.
4. Run both on your examples and compare accuracy.
5. Group Jev's answers by probability and check the accuracy in each group.
6. Set your thresholds from those groups, then pin the version with model="jev-1.13.0" so they stay valid.

Step 5 is where calibration either shows up or doesn't. This script does it for Choice and Noul questions. Save a CSV with your label, Jev's answer and the probability Jev gave that answer. For a Choice, that is answer.probabilities[answer.choice]. For a Noul, the answer is yes when noul is 0.5 or more, and its probability is max(noul, 1 - noul).

import csv
from collections import defaultdict

EDGES = [0.0, 0.5, 0.7, 0.8, 0.9, 0.95, 1.0]


def bucket(p):
    for low, high in zip(EDGES, EDGES[1:]):
        if p < high or high == 1.0:
            return f"{low:.2f}-{high:.2f}"


def accuracy_by_probability(path):
    counts = defaultdict(lambda: [0, 0])  # bucket -> [right, total]
    with open(path, newline="") as f:
        for row in csv.DictReader(f):
            b = bucket(float(row["probability"]))
            counts[b][0] += row["jev_answer"] == row["label"]
            counts[b][1] += 1
    for b in sorted(counts):
        right, total = counts[b]
        print(f"{b}  {total:4d} answers  {right / total:6.1%} right")


accuracy_by_probability("results.csv")

If the probabilities are calibrated on your data, each bucket's accuracy falls inside its range: between 80% and 90% right in the 0.80-0.90 bucket. If they are not, set your thresholds from the measured accuracy, not from the probabilities. The same script works on the confidence field, but then expect only a rise from bucket to bucket, not a match. Score answers need a different check, such as comparing the score with your own ratings.

Verdict: the right idea, not yet proven

My take: the premise is right. Many production LLM calls are decisions, and generating text is a slow, expensive way to make them. I'm less sure "System One" lasts as a category, and I would not trust the probabilities until I had measured them. The habits in this post carry over to any model you use.

Sources

Every claim above comes from these, checked on 24 September 2026:

• TypeSafe: launch post, docs, the Choice, Score and Noul pages, confidence, models, pricing and limits, known failure modes, parallel questions cookbook
• TypeSafe's evals: overview, security incidents, agent traces, invoice processing, customer service, LLM probability adapter
• Outside tests: Every, the Vercel engineer's post and Vercel's CEO on it, Bryo AI's post, phishing benchmark, Paweł Józefiak
• Coverage: TechCrunch
• Background: LLMs' stated confidence (Xiong et al., ICLR 2024)