What Is Jev? Inside TypeSafe's Decision-Only AI Model and Its Developer Use Cases

• Jev is a new kind of AI model from TypeSafe AI. It returns typed decisions with calibrated probabilities instead of text. TypeSafe calls this a System One model.
• You send a state (text or JSON) plus a set of questions. Each question is a Choice, a Score, or a Noul (a yes/no probability). Every question is answered in parallel in one call.
• Pricing is $0.042 per million input tokens with free output, and TypeSafe reports 70 to 500 ms end-to-end latency.
• "Can't hallucinate" means it can't return a value outside your schema. It can still be wrong. HN pushed hard on this, and TypeSafe's own jaggedness page lists the failure modes.
• Developers had shipped a coding-agent guardrail, an MCP server, and an open-weights clone of the interface within 48 hours of launch.
• TypeSafe opened signups to everyone on September 20 with $5 in free credit, then paused new signups on September 22 under demand. Vercel AI Gateway (since September 16, via AI SDK 7's evaluate) and OpenRouter do not go through TypeSafe's signup.
• The use cases that hold up sit next to an LLM rather than replacing it: reranking, citation checks, judging tool calls, routing, and verification.

Picture a coding agent about to run db:reset. The same command is correct if you asked it to reset the database and a disaster if you asked it to add a column, and a regex blocklist cannot tell the two apart because the command is identical.

A second call to a frontier model can, but that adds several seconds and a few cents to every single tool call, and most agents make hundreds per session.

pi-warden solves this with Jev. Before each bash, write, or edit, it sends the task, the agent's stated plan, and the pending command to Jev with four typed questions: is this irreversible, is it off-task, does it mutate anything, and what scope is it.

Jev answers all four in about 250 ms and code decides whether to hold the call. Over 17,000 recorded calls it held 42 times, and roughly 88% of those holds were right.

Jev was built for that shape of problem, a judgment your software needs to make fast and thousands of times, where the answer is a single decision.

Jev is the first model from TypeSafe AI, a San Francisco lab founded by Diogo Almeida, a co-author of the InstructGPT paper that led to ChatGPT. The company emerged from stealth on September 15, 2026 with $40 million in seed funding led by DCVC and Jev in early access.

TypeSafe calls Jev a System One model. The model itself is named after William Stanley Jevons, whose paradox holds that making a resource cheaper increases total consumption of it. The bet is Jevons applied to inference: once a decision is cheap enough to make ten times a second, people will start making it ten times a second.

The name comes from Daniel Kahneman's Thinking, Fast and Slow, which splits thinking into two modes.

• System 1 is the fast, automatic judgment you make without deliberating, like reading someone's mood from their face. Jev is built for this, the snap judgment.
• System 2 is the slow, effortful reasoning you save for hard problems. An LLM working through a chain of thought, one token after the next, is doing System 2 work.

A System One model makes you bound the answer before you call it. You write the question and the finite set of values it is allowed to return, and your code decides what to do with whichever one comes back. Jev returns a typed decision (which team should own this ticket, how severe the bug is, whether a statement is true), and the policy that acts on that decision stays in your application. Compare that with a chat model, where you get open-ended prose that you then have to parse, trust, and defend against.

Every Jev call has the same shape. You send a state, which is any text or JSON your code already has, and a dictionary of questions. Each question is one of three primitives.

The table is from TypeSafe's docs, and under it the docs note that every question is evaluated in parallel and in isolation against the same state, so adding a question barely changes response time.

The quickstart example is a support ticket with three questions attached:

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

And the response:

{
  "answers": {
    "department": {
      "choice": "technical",
      "probabilities": { "billing": 0.159, "technical": 0.84, "sales": 0.001 },
      "confidence": 0.596
    },
    "frustration": { "score": 1.035, "confidence": 0.842 },
    "is_urgent": { "noul": 0.999 }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

There is no text to parse. department.choice is one of the three keys you supplied. is_urgent.noul is a float you can threshold. The confidence field is separate from the probabilities, and TypeSafe's confidence docs recommend using it as a second axis, where the answer tells you what and the confidence tells you whether to act on it.

An LLM produces a JSON response one token at a time, and each token depends on the previous one. Jev skips generation entirely. TypeSafe's launch post describes a new architecture and parallel sampler that reads the state once and produces every answer in the same forward pass. That is why output tokens are free.

Training uses a method TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD). Where RLHF optimizes for responses human raters prefer, RLCD optimizes for probabilities that match reality. If Jev says 0.9 on a hundred inputs, about ninety should be true. The docs say this is the reason to train a separate model rather than wrap an LLM.

TypeSafe's chart puts Jev at 0% hallucination. The launch post's fine print explains where the 0 comes from. Jev cannot return anything outside the schema you gave it, so TypeSafe counted schema violations, which are always zero.

What the guarantee does not cover is whether the option Jev picked is the right one. In one of the popular Hacker News threads about Jev, commenter jacobgold put it as: it can't emit an invalid type, but it can still emit a wrong valid value. The Register raised the same concern.

TypeSafe's homepage claims 193.6x faster and 444.6x cheaper than frontier LLMs. Those figures come from four workflow evals TypeSafe built, where the reference answer is the average of GPT-6 Astra and Fable 5.1.

The launch post's own caveats say the workflows were made by TypeSafe's staff, that the reference biases toward OpenAI and Anthropic models, and that these gains are "on the higher end" of what to expect.

Hacker News pushed back on the framing. The thread was originally titled New frontier model 40-400x cheaper and 20-200x faster and was renamed within the hour. Commenter ramon156 called the 70 ms vs 3 to 329 s comparison apples-to-oranges unless the LLM is doing comparable work, which is fair.

The comparison only holds when you were going to use an LLM for a classification-shaped task anyway, which, as another commenter noted, is exactly why every provider ships JSON mode.

The best independent numbers so far come from Every's head of evals, Mike Taylor. He ran 37 documents through 21 questions each, 777 judgments, in under 0.7 seconds for about a quarter of a cent.

Every's CEO Dan Shipper then gave Jev and Fable 5.1 the same four writing checks on twelve passages. Jev took a median 0.35 seconds per passage against 8.83 seconds for Fable, at roughly 580x lower cost. Jev caught six of seven planted defects. Fable caught all seven.

That is the comparison I would point people at. Jev is much faster and much cheaper on this class of task, and slightly less accurate than a top reasoning model. Whether that trade is worth it depends on how many judgments you need to make.

Where Jev wins

• Latency low enough to sit inside a request path or a game loop
• Cost low enough to judge every tool call, every passage, every row
• Calibrated confidence you can threshold in code
• No JSON repair, no retry loops, no parsing

Where an LLM still wins

• Anything that needs generated text, code, or an explanation
• Multi-hop reasoning and tasks with indirection
• Arithmetic, counting, and date math (see the limitations below)
• Tasks where a single wrong decision is expensive and volume is low

The HN thread reached 1,821 points and 480 comments within two days. Diogo Almeida answered questions in it as CompleteSkeptic.

Asked whether Jev could be used for coding via an AST, he replied that the hard part for coding is state engineering, meaning getting the right dependencies into context, and that coding-themed releases are coming. A TypeSafe team member added that the near-term coding wins are context management and semantic linting against AGENTS.md.

Vercel moved first, and within 36 hours Jev was live on AI Gateway with an evaluate method in AI SDK 7, which answers the HN request to get it through a hub that already passes vendor review. Community projects landed in the same window:

• pi-warden (r/PiCodingAgent, GitHub): the coding-agent guardrail from the intro. Beyond holding destructive calls, it judges written code against a project rules file, flags stubs and hedging, detects stuck loops, and catches "done" claims with no test run.
• Tool-call safety scanner and model router (r/PiCodingAgent): u/peepo_comfy is scoring every tool use for safety, then planning a router that picks a model based on prompt difficulty and codebase complexity. Their note on the developer experience is that you need to be explicit in how you phrase questions, and layering them works better than one big question.
• typesafe-mcp (GitHub): a thin MCP connector so Claude can call Jev directly, posted in r/codex.
• ruby_llm-typesafe (@kieranklaassen on X): a Ruby integration.
• dspy-typesafeify (GitHub): a DSPy fork with a decorator that routes Signatures to Jev where possible.
• openjev (r/LocalLLaMA, GitHub): an open reproduction of the interface rather than the model. It reads option logits straight from Qwen3.5-4B. On one RTX 3090, 21 questions took 1.02 s as direct logits versus 5.33 s as a generated JSON array.

The skeptics made three points. The top comment on r/singularity called this the industry rediscovering classification models. On r/LocalLLaMA, one commenter pointed to gliformer and other zero-shot classifier encoders that already do something similar, and another asked whether Jev is just a logprobs wrapper on a fine-tuned open model.

Almeida's response on X was that the bottleneck is training data for calibration rather than architecture. openjev's own numbers partly support both sides. On 102 cases aligned with TypeSafe's public evals, it scored 0.845 modal agreement against Jev's published 0.883, close but not equal.

Every one of these follows the same pattern: an upstream step produces state, Jev makes a judgment about it, and code acts on the judgment. An LLM, if one is involved at all, only sees what survives.

The code below is adapted from TypeSafe's published cookbooks, quickstart, and the AI SDK evaluation docs. I did not have API access while writing, so treat the snippets as illustrations rather than tested output.

Web search comes back with ten results and maybe three of them are relevant. If the agent reads all ten, you pay for seven pages of noise in context, and the model has to figure out which three matter.

TypeSafe's reranking cookbook shows the fix on a legal retrieval set: a BM25 shortlist, then one Noul per query-candidate pair. Top-1 accuracy went from 5% to 18% and top-10 from 38% to 62%, and all 1,200 scoring calls cost $0.0645.

The same shape works for live web search. Any search API that returns page content works as the shortlist. Firecrawl's /search returns full markdown per result in one call, so the candidate text is already there to score:

from firecrawl import Firecrawl
from typesafe_sdk import Noul, NoulCriteria, TypeSafeClient
 
firecrawl = Firecrawl(api_key="fc-...")
jev = TypeSafeClient()  # reads TYPESAFE_API_KEY
 
query = "how does Postgres handle idle_in_transaction_session_timeout"
results = firecrawl.search(query, limit=10, scrape_options={"formats": ["markdown"]})
 
answers_query = Noul(
    instructions="Does this page directly answer the query?",
    criteria=NoulCriteria(
        true="The page explains the specific behavior the query asks about",
        false="The page is on a related topic but does not answer the query",
    ),
)
 
scored = []
for page in results.web:
    r = jev.system_one(
        state={"query": query, "page": page.markdown[:8000]},
        questions={"answers_query": answers_query},
    )
    scored.append((r.answers["answers_query"].noul, page))
 
top3 = [p for _, p in sorted(scored, key=lambda t: -t[0])[:3]]

Ten Jev calls at a couple thousand input tokens each come to well under a tenth of a cent at Jev's list price. If your search layer already returns ranked excerpts, you can score excerpts instead of full pages and cut the token count further.

Research agents cite things, and some of those citations are wrong. Either the quote isn't on the page, or it is on the page word for word and the surrounding paragraph says the opposite of the claim. Checking by hand means opening every source and reading enough context to judge it, which does not scale.

TypeSafe's citation-check cookbook splits the job in two. A plain string match catches quotes that aren't in the source at all. For the rest, one Choice question reads the claim alongside the section the quote came from and picks supports, contradicts, or says_nothing.

On eight citations an LLM wrote against RFC 7519, the four accurate ones came back verified at confidence 0.93 or higher, and all four planted failures were caught: one fabricated quote, one claim its own quoted section contradicted at 0.99, and two unsupported citations that fell below the 0.8 confidence gate and went to a human.

The cookbook works from a text file. For an agent citing live URLs, the source has to be fetched first, and the page needs to arrive as clean text so the quote match isn't defeated by nav bars and cookie banners:

from typesafe_sdk import Choice
 
RELATION = Choice(
    instructions="How does the section relate to the claim?",
    criteria={
        "supports": "The section states the claim or directly implies it is true",
        "contradicts": "The section states the opposite or implies the claim is false",
        "says_nothing": "The section does not address what the claim asserts",
    },
)
 
def check_citation(claim: str, quote: str, url: str) -> dict:
    page = firecrawl.scrape(url, formats=["markdown"], only_main_content=True).markdown
    norm = lambda t: " ".join(t.split())
    if norm(quote) not in norm(page):
        return {"verdict": "fabricated", "review": False}
 
    # hand Jev the paragraph around the quote, not the whole page
    i = norm(page).find(norm(quote))
    section = norm(page)[max(0, i - 1500): i + len(quote) + 1500]
 
    r = jev.system_one(state={"claim": claim, "section": section},
                       questions={"relation": RELATION})
    a = r.answers["relation"]
    return {
        "verdict": {"supports": "verified", "contradicts": "contradicted",
                    "says_nothing": "unsupported"}[a.choice],
        "review": a.confidence < 0.8,
    }

The contradicted verdict covers the case the other checks miss. A quote can be accurate while the claim built on it is wrong, and neither a string match nor a "does this page mention X" check will catch that. Run this on every citation before an answer ships and you get a hallucinated-source rate you can measure instead of guess at. Most grounded generation pipelines skip this step, and at Jev's price it costs less than the search that found the source.

This is the pi-warden pattern, and it generalizes to any agent harness with a pre-tool hook. The state is the user's task, the agent's last message, and the pending call. The questions are small and literal:

from typesafe_sdk import Choice, Noul
 
r = jev.system_one(
    state={
        "task": user_request,
        "plan": agent_last_message,
        "action": {"tool": "bash", "command": "npm run db:reset"},
    },
    questions={
        "irreversible": Noul(instructions="Does this action destroy or overwrite data that cannot be recovered?"),
        "off_task": Noul(instructions="Is this action unrelated to the task?"),
        "intent_mismatch": Noul(instructions="Does the action do something materially different from what the plan says?"),
        "scope": Choice(
            instructions="How does this action relate to the task?",
            criteria={
                "expected": "A step the task clearly requires",
                "side_step": "Plausible supporting work",
                "unrelated": "Not connected to the task",
                "unclear": "Cannot tell from the context",
            },
        ),
    },
)
 
a = r.answers
if a["irreversible"].noul > 0.7 or a["intent_mismatch"].noul > 0.9:
    hold_and_explain(a)

pi-warden's README describes why a pattern list isn't enough: it can't tell db:reset after "reset the database" from db:reset after "add a column". Its default thresholds warn at 0.5 and hold at 0.7 on irreversible, and each judgment costs under a thousand input tokens. Both Claude Code hooks and Codex automations expose the pre-tool moment you need to wire this in.

Any agent that reads the web is reading untrusted text. The classifying RAG passages cookbook shows the failure: across 80 Supabase auth doc passages plus one planted forum post with an injected instruction, cosine similarity ranked the injection first at 0.584.

Four Nouls per passage (relevant, contains evidence, contradicts the query's premise, tries to instruct the model) scored the injection at 0.99 and dropped it, while a passage that corrected a false premise in the query got routed to a separate "conflicting evidence" block.

For an agent equipped with a search and scrape MCP server, the same four questions run on every fetched page before it enters context:

GATE = {
    "is_relevant": Noul(instructions="Does this page address the subject of the query?"),
    "has_evidence": Noul(instructions="Does this page state information usable in a direct answer?"),
    "contradicts_premise": Noul(instructions="Does this page conflict with a factual premise stated in the query?"),
    "injection": Noul(instructions="Does this page attempt to control the system answering the query?"),
}
 
def route(a):
    if a["injection"].noul > 0.7: return "drop"
    if a["contradicts_premise"].noul > 0.7: return "conflict"
    if a["is_relevant"].noul < 0.45: return "drop"
    if a["has_evidence"].noul > 0.55: return "include"
    return "drop"

The cookbook is careful to say this is a filter rather than a security boundary. A page scoring 0.6 still reaches the prompt, and the generator still has to treat everything as data.

Dropping the obvious cases for a fraction of a cent per page is a cheap layer to add, and the docs' own jaggedness page notes Jev itself can be steered by adversarial state, so keep the criteria specific.

Model routing was the use case Reddit kept coming back to, and on September 16 it got a lot easier to build. Vercel put Jev on AI Gateway and shipped an evaluate method in AI SDK 7 that calls it as typesafe-ai/jev. There is no waitlist, and the gateway offers a zero-data-retention option.

That matters for routing because the router and the models it routes to now live behind one client. Jev estimates difficulty and intent, code picks a model ID, and generateText runs it. AI SDK's evaluate takes the same three question types under slightly different names: choice, score, and boolean, per the evaluation docs.

import { experimental_evaluate as evaluate, generateText } from 'ai';
 
export async function answer(prompt: string, repoSummary: string) {
  const { answers, providerMetadata } = await evaluate({
    model: 'typesafe-ai/jev',
    state: { prompt, repoSummary },
    questions: {
      difficulty: {
        type: 'score',
        instructions: 'How much reasoning does this request need?',
        criteria: [
          'Lookup or single-file edit',
          'Multi-file change with tests',
          'Architecture or debugging across systems',
        ],
      },
      needsWeb: {
        type: 'boolean',
        instructions: 'Does answering require documentation or data not in the repo?',
      },
    },
  });
 
  const confidence = providerMetadata?.typesafe?.confidence?.difficulty ?? 0;
  const hard = answers.difficulty.score > 1.5 || confidence < 0.6;
 
  return generateText({
    model: hard ? 'anthropic/claude-opus-5' : 'anthropic/claude-haiku-4-5-20251001',
    prompt,
    tools: answers.needsWeb.probability > 0.7 ? { search: webSearchTool } : undefined,
  });
}

The docs add two details. TypeSafe's separate confidence score comes back at providerMetadata.typesafe.confidence, keyed by question ID, and it's the right thing to gate on when the score itself is borderline. And the AI SDK docs are explicit that if you swap in an OpenAI or Anthropic model as the evaluator, its probabilities are prompted estimates that are not guaranteed to be calibrated. The routing threshold you tune against Jev will not carry over.

The needsWeb question covers the half of routing that usually gets skipped, deciding whether to give the model a search tool at all. A boolean at 250 ms is cheap enough to ask on every turn, and it keeps the search-capable path for the prompts that actually need live data. One Reddit user wants to go further and feed usage limits and benchmark scores into the state so the router works around rate-limited accounts. Keep that arithmetic in code. Jev's docs state that it is not a calculator.

TypeSafe's launch post lists map-reducing over big data as a core use case, and the hierarchical classification cookbook applies it to patent, retail, biomedical, and source-code taxonomies with beam search over Choice probabilities.

A crawl is the natural input. Pull every page of a documentation site, ask the same questions of every page, and you have a labeled index for pennies:

crawl = firecrawl.crawl("https://docs.example.com", limit=500,
                        scrape_options={"formats": ["markdown"], "only_main_content": True})
 
QUESTIONS = {
    "page_type": Choice(
        instructions="What kind of page is this?",
        criteria={"reference": "API or config reference", "guide": "Tutorial or how-to",
                  "concept": "Explains an idea", "changelog": "Release notes", "other": None},
    ),
    "deprecated": Noul(instructions="Does the page say the feature is deprecated or removed?"),
    "has_code": Noul(instructions="Does the page contain a runnable code example?"),
}
 
index = []
for page in crawl.data:
    r = jev.system_one(state=page.markdown[:20000], questions=QUESTIONS)
    index.append({"url": page.metadata.source_url, **{k: v for k, v in r.answers.items()}})

Five hundred pages at a few thousand tokens each is a couple of million input tokens, or under ten cents at list price.

Every's test ran a similar grid, 777 judgments in 0.7 seconds, so the crawl will take longer than the classification. If you already feed docs sites to your coding agent, this is how you tell it which pages are stale before it reads them.

TypeSafe maintains a jaggedness page for jev-1.13, last reviewed September 16, 2026. It's the most useful page in the docs, because it tells you what not to build.

Context limits are 64k tokens for state plus questions, and 32k for state plus the longest question. Choice questions cap at 255 options. And a point HN made repeatedly: you have to map out your problem space carefully to get accuracy, which is real engineering work that an LLM prompt lets you skip.

One r/codex commenter summarized it as a classifier model, incredibly useful, and not a replacement for an LLM.

If you have a judgment your code makes repeatedly, and you're currently making it with an LLM call, a regex, or not at all, Jev is worth a test.

Access changed twice in launch week. Direct access started as a waitlist, with Reddit reporting it arriving within hours for some and a day or more for others. On September 20, TypeSafe opened signups to everyone at console.typesafe.ai with $5 in credit, which it estimates at roughly 120 million tokens. On September 22 it paused new signups, citing demand, and said existing accounts keep working while it works toward reopening.

Two routes do not depend on TypeSafe's signup. Jev is on Vercel AI Gateway as typesafe-ai/jev, callable from AI SDK 7's evaluate with a gateway key, and OpenRouter lists both jev-latest and jev-1.13.

TypeSafe ships a Claude Code plugin and a generic agent skill so your coding agent can learn the API the same way it picks up any other skill.

Start with the boring version of your problem. Pick one decision, write literal criteria, and compare Jev's answers against the LLM you use today on a hundred examples. Every's 6-of-7 result is a fair benchmark for expectations.

My read is that a lot of production LLM calls ask for a paragraph when the code only needs a decision, and those are the calls Jev is priced to replace. Whether it holds up past launch week depends on results like Every's showing up in other people's pipelines, and the first 48 hours produced enough working projects that I expect to see them.