Jev only judges at $0.042 per 1M input tokens, output free

33,561. The development firm FullStack filtered 33,561 companies by “does it build software, does it have its own engineering team, is it not a competitor” in 4 minutes, at a query cost of $1.13. The model that did the work is TypeSafe AI’s Jev, and the two key lines on its price list are these: input at $0.042 per 1M tokens, and output tokens free. Jev does not write prose. It is a judgment-only model that returns, for each question, a probability per option and a confidence value, so output charges rarely come into play. Around this model, though, figures such as 193.6x, 444.6x and 70 to 500 milliseconds keep circulating, and each was measured by a different party under different conditions. As of Oct 27 (dates in UTC), this piece picks those numbers up one by one and follows who measured what.

The $0.042 applies to input tokens only

A request to Jev is one state and several questions. Below is a request that asks three things about a single customer message, in the format of the official documentation.

curl --silent https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "model": "jev-latest",
  "state": {"message": "I was charged twice this month and nobody answers my emails."},
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this message",
      "criteria": {"billing": "Charges, invoices, refunds", "support": "Product help", "sales": "New purchases"}
    },
    "anger": {
      "type": "score",
      "instructions": "How upset the customer is",
      "criteria": ["Calm", "Annoyed", "Furious"]
    },
    "wants_refund": {"type": "noul", "instructions": "The customer wants money back"}
  }
}
JSON

There are three question types. Choice picks one of 1 to 255 options. Score returns a position on an ordered description of 2 to 10 levels as a probability-weighted average (which is why values between levels, such as 1.4, appear). Noul gives the probability of yes or no as a single number from 0 to 1. Version 1.14 also added Box, which returns a position inside an image as top, bottom, left and right ratios from 0 to 1, but it is a trial feature together with image support and is not meant for production. The response consists of an answer per question ID and the usage. The values are illustrative, following the documented format.

{
  "model": "jev-1.14.0",
  "answers": {
    "team": {"type": "choice", "choice": "billing", "confidence": 0.86,
             "probabilities": {"billing": 0.91, "support": 0.07, "sales": 0.02}},
    "anger": {"type": "score", "score": 1.4, "confidence": 0.31,
              "legend": {"0": "Calm", "1": "Annoyed", "2": "Furious"},
              "probabilities": {"0": 0.03, "1": 0.54, "2": 0.43}},
    "wants_refund": {"type": "noul", "noul": 0.88}
  },
  "usage": {"input_tokens": 312, "output_tokens": 58}
}

What gets billed is the 312 input tokens at the bottom, in usage. The 58 output tokens carry no charge. Multiplying this one request by the $0.042 rate gives the following.

This cost is the editorial team’s calculation of rate times token count, and as the state grows longer, input tokens and cost grow at the same ratio. The context is 64k per request and 32k per question. Sending the header TypeSafe-Danger-Zone-Long-Context: true extends it to 262k, but the documentation notes that this makes the model slower and less accurate. The current model IDs are jev-1.14.0 (released Oct 14) and jev-1.13.0, and the aliases jev-latest and jev-preview both point to 1.14.0. The model documentation lists nothing scheduled for deprecation, and no version newer than 1.14 has been posted. To start, create a key in the console (console.typesafe.ai/keys), put it in the environment variable TYPESAFE_API_KEY, and install typesafe-sdk for Python 3.10 or later or @typesafe-ai/sdk for Node.js 20 or later. To try it without code, paste the state and question JSON into the console playground.

Five vendors shipped the same format in one month

When it launched in early access on Sept 15, Jev was the first model to put forward the category of “judgment-only models” itself (the company calls them System One models). Within a month, models doing the same job followed one after another. Cloudflare put Clef and Clef-flash on Workers AI on Oct 1. The same day, Amazon released Strands Decider 2B, which runs on your own computer (based on Qwen3.5-2B, Apache 2.0). Perplexity released pplx-decider, OpenAI opened its Decisions API in public beta on Oct 6, and Liquid AI released d1. Around the same time, TypeSafe was reported to have raised a large round. Outlets citing one business daily said it was a Series A of about $870 million at a $7.5 billion valuation. The company claims about a third of the Fortune 500 use it but has not disclosed customer names.

Here are the four models for which both price and score were published. The horizontal axis is price per 1M input tokens (log scale), and the vertical axis is the Decision Index 0.3 score each provider reported.

Figure 1. Prices and scores are values the providers published themselves (Cloudflare for the Clef family, the model card for Perplexity, and the same scoreboard for Jev), and prices are those at launch

Jev sits in the middle left. Its price still belongs to the cheapest group, but on the same scoreboard Perplexity Decider v1.1 is cheaper ($0.02) and scored higher, and Clef scores 3.3 points higher at 5.7 times the price (0.24 ÷ 0.042, editorial calculation). The numbers on the scoreboard move when the evaluation set version changes. The same Perplexity model is listed at 61.56 against Jev’s 57.9 on the model card, and at 62.8 against 60.1 on the scoreboard, with the ranking in the same direction. By category, in Perplexity’s table Jev leads on Knowledge, 51.4 to 48.18, while on Tools it flips, with Jev at 75.1 and Perplexity at 78.88. A developer’s post that reproduces Cloudflare’s self-reported values is in the same vein: on BANKING77, a banking-question classification test, Clef leads by a wide margin, 94.2 to 79.7, while on GPQA Diamond, which is reasoning-heavy, Jev leads 78.3 to 48.0. One reading of those values is that short classification and routing are now matched by small, cheap models while judgments involving reasoning are still better handled by Jev. But all of these are provider self-reports, so you need to confirm with your own data.

OpenAI’s Decisions API (POST /v1/decisions, model GPT-6 Luna) costs $0.10 per 1M input tokens with free output and returns answers in three forms: Predicate, Choice and Score. OpenAI says it is about 10 times faster than calling the same model through the Responses API. The Clef family consists of open models based on Qwen (Apache 2.0), and their request and response format matches Jev’s. Launch prices are $0.24 for Clef and $0.09 for Clef-flash, and output is not billed.

What to read between 193.6x and 171x

The phrase on TypeSafe’s homepage is “193.6 times faster and 444.6 times cheaper”. The figure below puts that number and the multiples measured elsewhere for the same model (LLM value ÷ Jev value) on one axis, with the measuring party on the right.

Figure 2. Except for the two headline figures, the multiples are the editorial team’s division of published raw values

The longer the bar, the more the number was compiled by the company itself, and values measured by outsiders step down one level at a time. A single run of the homepage demo had Jev at $0.000081 in 0.114 seconds and the comparison LLM (GPT-6 Terra) at $0.013880 in 8.566 seconds, which is 171 times in cost and 75 times in time. The headline 444.6x and 193.6x did not come from this demo but from an evaluation of four workflows assembled by TypeSafe’s capabilities team, and that evaluation does not have humans grade the answers. It uses the average of the answers from two models, GPT-6 Astra and Fable 5.1, as the reference. The company itself wrote that this approach may favor those two companies’ models, and the IT outlet The Register pointed out that the comparison itself is not fair.

The caveats the company attached in the same post are also part of the multiples. It said the speed was measured on a laptop, that the current price may be subsidized, and that long-term sustainability is unproven. The demo inputs were short and information-dense, which favored Jev, and that query was open only to early-access users. The “0% hallucination” claim comes with an explanation that the schema guarantees it rather than evidence, which means the output always fits the specified format, not that the judgment is always right.

70 ms, 114 ms and 524 ms are different clocks

Latency figures call for even more care. Even if both are “milliseconds”, they differ in whether the time was measured inside the server, as a round trip to the hosted API, and over how many requests combined. The figure below puts eight values on one log scale. Blue is Jev, green is the Cloudflare Clef family, and orange is the LLM.

Figure 3. The horizontal axis is logarithmic, so each tick is 10 times. Dots are single values and bars are reported ranges

Jev’s 70 to 500 ms bar and the LLM’s 3 to 329 s bar are so far apart that they do not touch, yet Jev’s own dots span a 4.6x range: 114 ms (one demo run), 171 ms (median over FullStack’s 135 requests) and 524 ms (the community scoreboard’s round-trip median). The 39 ms for Clef-flash and 209 ms for Clef, measured by Cloudflare, overlap Jev’s dots on the same scale, so it is more accurate to read “a few hundred milliseconds” as the common territory of models in this field. What this figure really gives is the fact that the gap to LLMs is large, and a claim of being a few milliseconds ahead means nothing unless you measured it yourself on the same equipment and the same network.

What the 135-item test shows about cost

The only test run from outside is FullStack’s internal one. They gave Jev and Claude Opus 5.5 the same definitions and the same inputs and compared them, and they state that it is not a controlled benchmark. The first test classifies whether 135 LinkedIn posts by tech leaders are sales signals, and the 10 items on which the two models disagreed were judged by a person who could not see which model gave which answer.

Measure	Opus 5.5	Jev
Accuracy	129/135 (95.6%)	131/135 (97.0%)
Total cost	$0.615	$0.0034
Cost scaled to 1,000 posts	about $4.56	about $0.025
Total time	24.6 s	2.9 s
Nature of errors	All 6 were false positives, treating posts that merely mention “AI” or “engineering” as sales signals	All 4 were near the borderline, at probabilities of 0.41 to 0.55

The 1,000-post cost is the editorial team’s figure from scaling the 135-post cost by 7.4, and the cost ratio is about 181 times (the FullStack bar in Figure 2). FullStack itself said the 2-item accuracy gap is not evidence of superiority because the sample is small. What deserves attention is that all 4 of Jev’s errors cluster at probabilities of 0.41 to 0.55. The wrong answers were close to a coin flip rather than confidently wrong, which means that putting a threshold in place could have routed them to a person and filtered them out.

There is also one customer case. The talent-matching service Jack & Jill replaced Gemini 3.1 Flash Lite with Jev in its candidate screening step. According to the company’s report, the cost of screening 1,000 candidates fell 88%, from $0.755 to $0.092, and median processing time halved from 20.3 seconds to 10.3 seconds, while the recruiter retention rate of 94.6% versus 93.9% showed no statistical difference. All of these are company-compiled figures, and the multiples for this case in Figure 2 are the smallest, 8.2x and 2.0x, because the comparison target was not a frontier LLM but an already lightweight model.

Pouring 33,561 companies into the funnel

The second test is the 33,561 companies from the very beginning. It fed in only the company name, the homepage title and description, and a few pieces of company information, packed three questions into one request, and cost $1.13 over 4 minutes, with a total model cost of about $1.5. Split up by the editorial team, that is about $0.00003 per company. On the left is the volume of each verdict, and on the right is the accuracy on a sample reviewed blind.

Figure 4. In the funnel on the left, 68% of the 33,561 companies drop out as no. The dotted line on the right is a coin flip (50%)

The verdicts were yes for 8,461 companies (25.2%), review for 2,289 (6.8%) and no for 22,811 (68.0%). The amount filtered out is clear, but the validation differs left and right. Of 40 items picked as yes, 37 (93%) were right, while of 24 discarded as no, only 13 (54%) were right, and 11 were missed candidates. Among the 1,389 accounts already on the target list, 2.5 to 4.9% were wrongly dropped, which is about 35 to 68 companies by the editorial team’s calculation. FullStack analyzed that the definition it supplied was narrower than the real market, rather than the model applying the definition wrongly. This is why this kind of screening needs a person to open the no-side sample, not just check the yes accuracy, and the figure of 54% on the discarded side shows the reason.

How a confidence of 0.4 comes about

Confidence is not “the probability of being correct”. What the documentation defines is how concentrated the probability distribution is. For Choice with n options, it is (top probability − 1/n) ÷ (1 − 1/n), and because only the top one is considered, (0.6, 0.3, 0.1) and (0.6, 0.2, 0.2) both give 0.4. Even for the same top probability of 0.6, the confidence is 0.2 with two options, 0.4 with three and 0.5 with five. The curves below show that relationship.

Figure 5. Curves drawn by the editorial team from the documented Choice confidence formula. The fewer the options, the lower the confidence a given top probability yields

All the curves meet at (1, 1), and the lower left end is 0 at 1/n. So if you apply a confidence threshold of 0.6 to a two-option question, the top probability must reach 0.8 to pass, while on a ten-option question 0.64 passes. When question design changes, the meaning of the same threshold changes. Score discounts probability spread across adjacent levels less than across distant ones, so (0, 0.5, 0.5), split evenly between two neighboring levels, gives 0.25, and (0.5, 0, 0.5), split across the two ends, gives 0. The Score of 1.4 and confidence of 0.31 in the sample response result from probability spreading across Annoyed (0.54) and Furious (0.43). Noul has no confidence field, so if you need one you compute |2p − 1| yourself. The property the documentation calls calibration is measured across a whole set of predictions, not on an individual answer, so do not read it as “0.9 means 90% correct”. Measure the accuracy per band on your own data.

Policy sets the threshold numbers

The documentation’s cookbook has examples that hold the same probabilities against situation-specific thresholds to decide actions. All values are examples, and the documentation stresses that you should set them to fit your domain.

Situation	Question	Threshold	Action
Voice banking command	Intent (Choice)	Confidence below 0.6	Human agent
Voice banking command	Balance inquiry	0.6 or above	Show immediately
Voice banking command	Transfer approval	0.6 to 0.85 / above 0.85	User confirmation / auto-approval
One support ticket	5 questions at once	Severity above 1.5 and reproduction probability above 0.6	To engineering
One support ticket	Refund request (Noul)	Above 0.7	Flag refund to the billing team
Input/output guardrail	Risky-item Noul + severity Score	Strict: review 0.35, enforce 0.70, severity 2.0	Pass, review, block
Input/output guardrail	Same probability, relaxed policy	Enforce 0.85	A jailbreak variant phrase (0.74) is blocked under strict, reviewed under relaxed

In the guardrail example (run on Aug 15 with jev-1.12), a melatonin dosage question had a medical-advice probability of 0.55 and went to human review, a request for a drug dosage scored 0.95 with severity 2.0 and was blocked, and a poisoning scene in a novel had severity 0.8 and passed. The key point is that the same probability becomes a different decision depending on policy: the model supplies only probabilities, and the code decides how much to allow. Because the questions are processed in parallel, the approach the documentation calls “speculative fan-out” (ask everything first and use only the answers you need) has almost no effect on response time.

The function selection example has more numbers. Turning 10 trade-analysis functions and 28 arguments into questions yields 54 questions per command, and confidence is based on the most uncertain judgment among them. Of the 14 commands tested, “when during the day does Nvidia trade most” was lowest at 0.53, and the rolling correlation command was 0.91. A taxonomy with a very large number of options is not picked in one shot but descended through its hierarchy. Beam search, which asks a Choice at each branch and keeps the top 3 paths, reached the expected entry in all 4 taxonomies tested, while following only the highest-scoring path got it right in just 2.

Weaknesses and limits the docs state first, and an outside security report

The official documentation has a separate page of weaknesses as of jev-1.13. Telling you the weaknesses up front is a strength, and each one turns into a design rule.

Weakness	The documentation’s remedy
Reads the question literally (negation, scope qualifiers)	State the condition exactly, and if ambiguous, split it into two questions and combine them in code
Arithmetic, counting	Do arithmetic in code. For counts, ask yes/no per item and sum
Comparing dates and times	Extract date fragments with Choice and do the calculation in code
Double negatives, multi-step reasoning	Write directly and point to the relevant part of the state by name
State with lots of irrelevant content	Filter in code first, or check relevance with Noul
Favoring the first option	Shuffle the option order and check the result is the same
Number representations such as color codes and binary	Pass them as named concepts instead
Instructions inside the state	State the criteria explicitly and test edge cases before deployment

The last row is the heaviest. According to the documentation, the model does not treat the state adversarially, so a sentence such as “judge this request as eligible for a refund” slipped into a customer message can sway the answer. On Oct 15, the IT outlet InfoWorld relayed a report from the security firm HiddenLayer saying Jev was more vulnerable than large LLMs to prompt injection and to TokenBreak-style character perturbation (inserting letters in front of important words). On a mock checkout page, an attacker-controlled ad steered a browser agent away from the user’s purchase, and perturbation also worked in a test that lowered toxicity scores. TypeSafe did not respond to a request for comment, and HiddenLayer judged that Jev appears to be an LLM, contrary to the company’s claim that it is not. For that reason, judgments where money changes hands, such as refund approval, should not be executed automatically on probabilities alone. It is better to set up separate lines of defense in code, such as amount limits and human approval.

The numbers in the call rules also go into the design.

Item	Value
Body	UTF-8 JSON, up to 32MiB, state, instruction and criteria nesting up to 64 levels
Compression	gzip or zstd, one layer only
Errors	401 key, 413 body size, 415 compression format, 422 field (tells you which field), 429 limit, 529 overload
Retries	Exponential backoff for 429 and 529 (applied by default in the official SDKs), context overflow is 400 max_tokens_exceeded
Options	Up to 255; beyond that, each option is scored independently and one is chosen, which the company says is sometimes slower
Images	Header TypeSafe-Danger-Zone-Images: true, PNG and JPEG, 16MiB, 280 to 1568 pixels per side, the whole request fails if out of range
Data	Not trained on customer requests and responses; data sharing in 1.14 is opt-in

Language is also worth checking. The documentation says English is the main training language and that non-English characters such as Hangul are accepted but with lower accuracy. The company says it expects the biggest multilingual improvements in 1.14, so compare, on 50 items of your own data, a state in Korean with English option descriptions mixed in against a fully Korean one. The alias jev-latest changes where it points when a new release comes out, so in production pin a version ID such as jev-1.14.0 and log the model field of the response. The company promised deprecation notice of 60 days for 1.13 and 30 days for 1.14.

Numbers from derived tools

There are several ways to reach Jev besides calling it directly. It is listed on Vercel AI Gateway as typesafe-ai/jev and can be passed as the model to experimental_decide in the AI SDK. The data warehouse MotherDuck lets you call Jev per row with the SQL function prompt_jev. It works on the Lite and Business plans without a TypeSafe account or key, only input tokens are billed, the model is fixed to jev-latest, and the instructions and options must be constants.

SELECT prompt_jev(
    body,
    'Which team should handle this?',
    choice := ['billing', 'technical', 'sales']
).choice AS team
FROM support_messages;

To have a coding agent write the integration code, TypeSafe offers a skill (MIT). In Claude Code, install it with claude plugin marketplace add typesafe-ai/skills and claude plugin install typesafe@typesafe-ai, and for other agents with npx skills add typesafe-ai/skills –skill typesafe-ai. This skill is a guide that teaches the agent the API and patterns so it writes app code that calls Jev correctly, and it does not turn Jev into a coding model.

One tool that actually uses Jev is developer dzhng’s jevgrep (MIT, about 2,900 stars, npm @dzhng/jevgrep). It is a CLI that cuts the time and tokens a coding agent spends finding files in an unfamiliar repository: it has Jev judge relevance at the folder, file and declaration level, then prints excerpts of the original text. It requires Node.js 22 or later and a key for Vercel AI Gateway, TypeSafe, OpenRouter or similar.

npm install -g @dzhng/jevgrep
jg auth      # pick a provider and store the key
jg skill     # install the skill so the agent uses this tool (required)
jg "How are telemetry events recorded and sent?" ./my-project

The effects the repository reports should be read together with their conditions.

Test	Tasks solved	Cost change
Ten Python tasks, main comparison	Baseline 8, jevgrep 8	Agent side $7.62 → $5.44 (28.6% reduction, excluding Jev cost)
0.4.3, including Jev cost	8	Total cost down 25.8%
0.5.0	Stays at 8	Jev cost down about 59%, combined up 2 to 3%

The README itself states that this is an observation from running the ten tasks once each and does not guarantee statistical equivalence or a speed improvement. It also notes that some of the source used for search is sent to the chosen provider and that the sensitive-file filter is best-effort, not sanitization. The line saying that Jev cost fell 59% in 0.5.0 while the combined cost actually rose 2 to 3% shows that even if you shrink the cheap part further, the overall bill stays the same when the expensive model’s cost dominates. If you already know the file name or symbol, it is better to just read it or use rg.

What remains when the model changes is the call format

SemIf (formerly OpenJev, MIT, about 4,900 stars, latest changelog Sept 22), an independent project unrelated to TypeSafe, does not reproduce Jev’s closed model or training. It implements, with open models, “an interface pattern that reads a probability per option in a single computation”. It does not generate an answer; it reads the logits of the tokens corresponding to the options in a single forward pass, and when several questions share a state, it precomputes the state once and reuses it. It requires Python 3.10 or later and a CUDA GPU that can hold a 4B BF16 model, and also has MLX and MPS backends for Apple Silicon and a llama.cpp backend for CPU. The numbers are as follows.

Measurement (author, one RTX 3090)	Value
Qwen3.5-4B, 21 binary criteria: logit reading / JSON generation	1.023 s / 5.332 s (111 output tokens, 18/21 agreement)
21 criteria on the same state, 777 items: recompute every time / reuse state sequentially / in parallel	2.33 / 10.75 / 20.03 items per second (the two faster paths are experimental)
Balanced accuracy on the author’s test set: 4B / 27B	0.813 / 0.958
Agreement with Jev on the 102 selection rows TypeSafe published: SemIf 4B / Jev’s published value	0.845 / 0.883
Probability calibration error (ECE), WANLI set: before → after calibration	0.208 → 0.069

SemIf says it did not run the real Jev endpoint but compared against TypeSafe’s published records, and it urges calibrating and validating for tasks you entrust with decisions, because the returned probabilities are conditional values within the options you supplied. Its input format is SemIf’s own spec, different from Jev’s, so the options go in an options array.

{
  "id": "route-1",
  "state": "Customer cannot access an account after a password reset.",
  "question": "Which queue should handle this request?",
  "options": [
    {"id": "access", "description": "Account access support."},
    {"id": "billing", "description": "Billing support."}
  ]
}

Seen this far, the trends converge into one. Clef uses the same request and response format as Jev, so you only change the endpoint, the key and the model field. OpenAI offers the same three forms of answer at a different address, and SemIf reads the same idea on your own GPU. Being cheap was the advantage Jev showed first, but several models now sit in that seat, so the unit price has become the number that changes most easily. What lasts is the format of sending a state and a question and receiving a probability per option, and the thresholds you have set on those probabilities. So whichever model you start with, if you log the response’s model and the full probabilities, you can recalibrate the thresholds when you switch models, using the distribution the new model produces on the same inputs. A call site with accumulated material for recalibrating thresholds cuts switching costs more than a model that sells accuracy.