Jev for SQL: 5 Data Use Cases, and What We Measured vs. What TypeSafe Claims

Key Findings

• Jev is a decision model, not a text model. TypeSafe AI's Jev returns a yes/no probability, a choice from a list, or a rubric score. It cannot write SQL or any other text.
• Jev latency: 296 ms median per call on a reused HTTPS connection (measured from Turkey, September 2026), inside TypeSafe's claimed 70–500 ms range.
• Jev throughput: 290 calls of about 1,300 tokens each, 100 concurrent, finished in 2.5 seconds with zero errors.
• Jev cost: those 290 calls used 372,480 input tokens and cost $0.0156, matching the published price of $0.042 per million input tokens.
• Jev confidence is meaningful: when Jev was at least 80% sure, it was right 97% of the time against an independent GitHub record (119 of 123 cases).
• Jev is stable, and shows no option-order bias: across 12 classification tasks, the answer was identical in 5 of 5 repeat calls and in 4 different option orderings. Probabilities drift by about 0.02 either way, so reordering options changes nothing beyond ordinary noise.
• Stable is not correct: Jev identified a QUALIFY clause as SQL Server every time, in every order. QUALIFY does not exist in SQL Server.
• Best SQL uses for Jev: filtering rows by meaning, ranking which tables a text-to-SQL question needs, gating agent-written queries, and verifying generated SQL.
• For schema pruning, one Choice beats many Nouls: on a 56-table schema, a single 56-option Choice ranked every required table in the top 4. The same job as 56 independent yes/no questions buried required tables as deep as rank 46, at ten times the token cost.
• Biggest pitfall: asking two things in one question. A compound question mislabeled 25 of 28 comment-free items in our first run.

What Jev Is (and Isn't), in 60 Seconds

Jev is the first “System One” model from TypeSafe AI. The name borrows from Kahneman: System Two is slow, deliberate reasoning, which is what large language models do token by token. System One is the fast, intuitive judgment. Jev is built only for that second kind.

In practice that means Jev never produces a sentence. You send it a state (any text) and a set of typed questions, and it answers with one of three primitives:

• Noul: a probability between 0 and 1 that a statement is true.
• Choice: one option from a list you define, with a probability for every option.
• Score: a position on an ordered rubric you define (2 to 10 levels).

A complete request looks like this:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Cancelled in March, still getting billed every month.",
    "model": "jev-latest",
    "questions": {
      "billing": {
        "type": "noul",
        "instructions": "The customer is complaining about billing or charges."
      }
    }
  }'

The response is a number your code can put straight into an if: {"billing": {"type": "noul", "noul": 0.99}}. There is nothing to parse and no prose to strip.

Claimed vs. Measured

Most of what is written about Jev so far repeats the launch post. Before building anything on it we wanted our own numbers. Our main test: we pulled 290 open, unassigned “good first issue” threads from 119 popular GitHub repositories and asked Jev seven typed questions about each one (is someone already working on it, does a linked pull request address it, how clearly is it scoped, and so on). Each call carried roughly 1,300 input tokens.

The latency row deserves a note, because we got it wrong at first. Our first script opened a new HTTPS connection for every call and we saw about 720 ms. Of that, 434 ms was TCP and TLS setup. On a kept-alive connection the same call took 296 ms. If you benchmark Jev, reuse your connections, or you will mostly be measuring your own network handshake.

Does the confidence mean anything?

In our first pass Jev only saw issue comments. Separately, and without any model, we pulled GitHub's timeline API to see which issues had a pull request linked to them. That gave us an independent check on the question “someone is actively working on this”:

When Jev was very sure, it was right 97% of the time. The bottom rows look bad until you read them correctly: those pull requests were never mentioned in the comments, so Jev could not have known about them. That was a gap in what we fed it, not a wrong answer. It is also a useful warning. A linked PR is a strong signal but not a perfect ground truth, so treat this table as evidence, not a benchmark.

For the record, the experiment's headline result: of 290 issues GitHub lists as unassigned, 73% already had an open PR or someone working on them, 4% were already fixed, 8% only had a “can I take this?” comment, and 15% were actually free.

Is it deterministic? Is it order-biased?

Two questions come up constantly about any model you want to put in a control path, and neither is answered by the launch material. We tested both on SQL dialect detection: twelve snippets, a Choice with six dialects, some of them genuinely ambiguous.

Determinism. Five identical calls per snippet. The chosen dialect was the same all five times in 12 of 12 cases. The probabilities were not bit-identical, though: the winning option's probability moved by 0.02 at the median and 0.09 at most between runs. So the decision is stable while the numbers underneath it drift slightly. If your logic sits on a threshold, an item sitting within about 0.05 of that threshold can flip between runs. Ours did: two runs of the 290-issue experiment differed by one issue.

Option-order bias. Large language models are well known to favour options by position. We ran each snippet with the six dialects in four different orders: original, reversed, rotated and shuffled. The pick was identical in 12 of 12 cases, and the probability moved by 0.015 at the median and 0.08 at most. That is the same magnitude as the drift between two identical calls above, which is the point: reordering the options produced nothing distinguishable from ordinary run-to-run noise. If you have been shuffling options to defend against position bias, you can stop.

Stability is not accuracy, and it is worth seeing the difference. Asked about SELECT ... QUALIFY ROW_NUMBER() OVER (...) = 1, Jev answered “SQL Server” every single time, in every option order, with no hesitation in the probabilities. QUALIFY does not exist in SQL Server; it is Snowflake, BigQuery, Teradata and DuckDB syntax. This is the honest reading of “no hallucination”: Jev cannot invent a dialect that is not in your list, and it will not waver — but it can be confidently, repeatably wrong. Consistency makes errors easier to find in testing. It does not make them errors any less.

Use Case 1: A WHERE Clause That Filters by Meaning

LIKE matches characters. It cannot know that “charged twice” and “still getting billed” are both billing complaints. A Noul question can, and because Jev returns a number, it drops into SQL as an ordinary function. Here it is as a SQLite user-defined function, using only the Python standard library:

import json, os, sqlite3, urllib.request

def jev(text, statement):
    body = {"state": text, "model": "jev-latest",
            "questions": {"q": {"type": "noul", "instructions": statement}}}
    req = urllib.request.Request(
        "https://api.typesafe.ai/v1/systemone",
        data=json.dumps(body).encode(),
        headers={"Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}",
                 "Content-Type": "application/json"})
    with urllib.request.urlopen(req) as r:
        return json.loads(r.read())["answers"]["q"]["noul"]

db = sqlite3.connect("app.db")
db.create_function("jev", 2, jev)

SELECT id, body
FROM reviews
WHERE jev(body, 'The customer is complaining about billing or charges.') > 0.5;

We ran this on a 12-row table of app reviews. WHERE body LIKE '%billing%' returned zero rows, because none of the reviews contains that word. The jev() version returned all six billing complaints:

0.99  I was charged twice this month and nobody answers my emails.
0.99  Cancelled in March, still getting billed every month. Want my money back.
0.99  Free trial turned into a yearly charge, I never agreed to that.
0.97  Why do I have to pay again after reinstalling? I already bought premium.
0.96  The subscription price doubled without any warning.
0.86  Refund request ignored for three weeks now.
0.04  Best scanner app I have used, worth every penny.
0.02  Sync is slow but it works.
0.01  App crashes every time I open the camera.

Note the 0.04 on “worth every penny”: a money word, but not a complaint. The gap between 0.86 and 0.04 is wide enough that the threshold hardly matters.

The catch: a SQLite UDF runs one row at a time. Our 12 rows took 8.5 seconds. For a real table, do not call Jev from inside the query. Read the text column, score all rows in parallel (100 concurrent requests worked fine for us), write the scores to a column, then filter with plain SQL. That is a 12-row toy, not a benchmark; we have not yet run this on a large table.

This idea is not new. Snowflake Cortex, BigQuery and MotherDuck all offer LLM-backed SQL functions that do the same job. The difference is cost and speed: at roughly 300 input tokens per short row, 100,000 rows comes to about $1.26 with Jev.

Use Case 2: Schema Pruning for Text-to-SQL

The hardest part of text-to-SQL on a real database is not writing the query. It is deciding which 4 of 300 tables matter. Send the whole schema to an LLM and you pay for a huge prompt and give the model more chances to pick the wrong table.

The obvious design is one Noul per table, asked in parallel: “does answering this question require reading this table?” On a 12-table schema that works, and it is what we built first. On a realistic schema it falls apart, and the way it falls apart is worth more than the technique itself.

We grew an e-commerce schema to 56 tables by adding the kind of names real databases accumulate — sandbox_orders, purchase_orders, invoices_legacy, billing_plans_v1 — and asked three questions with known answers. The measure that matters for pruning is the worst rank of a table you actually need: if a required table lands 22nd and you keep the top 10, the LLM can no longer write the query. Three questions, two runs each:

Asked in isolation, “does this revenue question need sandbox_orders?” is a reasonable yes. Jev scored it 0.86, above the real orders table, because nothing in that request revealed that a better orders table existed. Independent questions cannot rank; they can only judge. Give the same Noul the list of every table in the database and the failure disappears entirely (22.5 → 3).

So the rule is not “Choice beats Noul.” It is that a comparative question needs comparative context. A Choice supplies it by construction, because its probabilities are normalized across every option in one pass:

QUESTION = "What was our monthly revenue by customer country last year?"

question = {
    "type": "choice",
    "instructions": "Which table is most essential to answer the question with SQL?",
    "criteria": {name: f"columns: {cols}" for name, cols in TABLES.items()},  # up to 255
}
# One call. probabilities comes back for every table, so you get a full ranking.
ranked = sorted(ask(f"Question: {QUESTION}", {"table": question})["table"]["probabilities"].items(),
                key=lambda kv: -kv[1])

0.36  orders          0.00  warehouses
0.35  customers       0.00  order_items
0.29  payments        0.00  user_settings

One call instead of 56, about a tenth of the tokens, roughly a second, and the three tables you need on top. Two caveats still apply. Keep top-k, not a threshold: the winning tables sit near 0.3 because the probability mass is split among them, so a 0.5 cutoff would discard all three. And a Choice caps at 255 options, so a 300-table warehouse needs a cheap first pass — by schema, by name match — before Jev sees it.

We have not measured the effect on end-to-end text-to-SQL accuracy on a standard benchmark such as Spider or BIRD. That is the next thing we want to test.

Use Case 3: A Safety Gate for AI Agents That Run SQL

Agents now run queries against real databases, often through MCP servers. A gate that checks every query before it executes has to be fast, or nobody will leave it on. A few hundred milliseconds is acceptable. Several seconds is not.

We gave Jev the user's question and the SQL an agent wanted to run, and asked two things:

answers=0.82  personal_data=0.02   "How many orders did we ship last week?"
                                   SELECT COUNT(*) FROM shipments WHERE shipped_at >= ...

answers=0.01  personal_data=0.98   "How many orders did we ship last week?"
                                   SELECT name, email, country FROM customers

answers=0.84  personal_data=0.03   "Which product category sells best?"
                                   SELECT c.name, SUM(oi.quantity) FROM order_items ...

answers=0.01  personal_data=0.95   "Which product category sells best?"
                                   SELECT email FROM customers WHERE country = 'DE'

A query that wanders off the question and starts pulling emails is exactly what you want to stop, and the separation here is clean. Four examples prove nothing about adversarial cases, though, and Pydantic's own documentation for the Jev integration lists adversarial text as a weak spot.

So split the work. Hard facts belong in code: does the statement contain DROP, is there a DELETE without a WHERE, which tables does it touch. A SQL parser answers those with certainty. Give Jev only the fuzzy part: does this match what the user asked, does it look like bulk extraction of personal data. We learned this the hard way (see the mistakes below).

Use Case 4: Verifying Generated SQL

The answers question above is also a cheap verifier for a text-to-SQL pipeline. After the LLM writes a query, ask Jev whether it answers the question, whether it applies the date range the user mentioned, whether it groups by what was asked. If a score comes back low, regenerate before the user ever sees the query. At around 300 tokens a check, this costs a fraction of a cent per thousand queries.

Use Case 5: Classifying and Routing Queries at Scale

Anything you currently do with “return only JSON” prompts is a candidate: tagging a query log by intent (reporting, debugging, export), guessing the SQL dialect of a pasted snippet with a Choice, scoring how complex a request is with a Score so you can route hard ones to a bigger model. These are the jobs where a Choice with explicit criteria beats parsing free text.

Using Jev Through Pydantic AI

If you already use Pydantic AI, there is a first-party integration. You describe the decision as a Pydantic model and Jev fills it in:

from pydantic import BaseModel, Field
from pydantic_ai import Agent

class QueryCheck(BaseModel):
    """Review a SQL query an agent wants to run."""
    answers_question: bool = Field(description="Does the SQL answer the user's question?")
    reads_personal_data: bool = Field(description="Does it return names, emails or addresses?")

agent = Agent("typesafe:jev-latest", output_type=QueryCheck)

Install with pip install "pydantic-ai-slim[typesafe]". We took this example shape from their docs and have not run it ourselves; our tests used the REST API directly. The same docs list limits worth knowing: only bounded types are supported (bool, enums, literals, floats from 0 to 1), a question can have at most 255 options, and Jev is weak at arithmetic, counting and date logic.

Three Mistakes We Made (So You Don't)

1. We asked two things in one question

Our first version asked: “Someone asked to be assigned, but there is no sign that work started.” On issues with zero comments, the second half is true, so Jev leaned yes. It marked 25 of 28 comment-free issues as “someone asked for this,” on threads where nobody had written a word. Splitting it into two single-fact questions and moving the AND into our own code fixed it. TypeSafe's docs say each question should ask one specific thing. They mean it.

2. We asked the model things we already knew

We had each pull request's state (open, merged, closed) from the API, and still asked Jev to judge whether an “open or merged” PR addressed the issue. It hedged at 0.63 on issues whose only PRs were closed and abandoned, and our 0.5 threshold called them taken. The fix was to filter PRs by state in code and ask Jev only the part that needs judgment: does this PR actually address this issue, or just mention it.

3. We fed it too little

With comments alone, almost half the issues Jev called “free” turned out to have an open PR. GitHub stores PR links as timeline events, not comments, so the model never saw them. Adding that one section to the input moved the “already taken” rate from 57% to 73%. A decision model is only as good as the state you hand it.

When Not to Use Jev

• Writing SQL, or writing anything. It produces no text. Use an LLM, or a schema-aware SQL generator.
• Explanations. You get a probability, not a reason.
• Arithmetic, counting and date logic. Listed as weak spots in the integration docs. Compute those in code.
• Anything you can determine exactly. If a parser or a column can answer it, do not ask a model.
• When “unsure” is not acceptable. On about one issue in four, at least one of our status answers landed between 0.35 and 0.65. Plan for a middle band: send those cases to a human or a slower model.

We also have not compared Jev's accuracy against an LLM on the same task. We can say it is fast and cheap. We cannot say it is more accurate.

Pricing and Cost Math

Input tokens cost $0.042 per million. Output is free. In our runs, a short text with one question used about 300 input tokens per call (32 calls, 9,709 tokens), and a long GitHub thread with seven questions used about 1,300.

These are projections from our per-call token counts, not measured runs at that scale. We also do not know Jev's rate limits: nothing in the response headers states them, and 100 concurrent requests was the most we tried. Adding more questions to a call is cheap, because the text is sent once. Adding more options to a Choice is nearly free.

Frequently Asked Questions

What is Jev?

Jev is the first System One model from TypeSafe AI. It does not write text. You send it some text plus a set of typed questions, and it returns a yes/no probability (Noul), a pick from a fixed list (Choice), or a position on a rubric (Score), each with probabilities your code can act on.

Can Jev write SQL?

No. Jev cannot generate text, so it cannot write a query. It is useful around SQL generation: picking which tables are relevant to a question, checking whether a generated query answers the question, flagging queries that read personal data, and filtering rows by meaning.

How fast is Jev in practice?

In our tests from Turkey, a single call on a reused HTTPS connection took 296 ms at the median (253 ms best). Opening a new connection per call added about 430 ms of TCP and TLS setup. With 100 concurrent requests, 290 calls of roughly 1,300 tokens each finished in 2.5 seconds with zero errors.

How much does Jev cost?

TypeSafe charges $0.042 per million input tokens and nothing for output. In our runs a short one-question call used about 300 input tokens, so classifying 10,000 short rows costs roughly $0.13. Our 290-call GitHub experiment used 372,480 tokens and cost $0.0156.

Is there a waitlist for Jev?

Not anymore. Jev launched in early access with a waitlist, but TypeSafe announced on September 21, 2026 that it is open to everyone. You can create an API key at console.typesafe.ai.

Is Jev deterministic?

In our test the decision was stable but the probabilities were not exactly repeatable. Across 12 classification tasks called 5 times each with identical input, the chosen option was the same every time in 12 of 12 cases, while the winning option's probability moved by about 0.02 at the median and 0.09 at most. Items sitting within roughly 0.05 of a threshold can therefore flip between runs.

Does Jev have option-order bias?

We found none. Running 12 Choice questions with their six options in four different orders (original, reversed, rotated, shuffled), the chosen option was identical in 12 of 12 cases and probabilities moved by 0.015 at the median. That is the same magnitude as the drift between two identical calls, so reordering produced no effect distinguishable from ordinary run-to-run noise.

Should I use Jev or an LLM for classification?

Use Jev when the answer is a label, a yes/no or a score, you have many items, and latency or cost matters. Use an LLM when you need an explanation, free-form extraction, arithmetic, date logic, or any generated text. We have not run a head-to-head accuracy comparison, so we only claim Jev is faster and cheaper, not more accurate.