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.
• Vercel added Jev to AI Gateway on September 16, callable from AI SDK 7's new evaluate method with no waitlist.
• The use cases that hold up are the ones next to an LLM, not instead of one: reranking, citation checks, judging tool calls, routing, and verification.

A coding agent is about to run db:reset. If you asked it to reset the database, that command is exactly right. If you asked it to add a column, it's a disaster. A regex blocklist can't tell the difference.

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.

This is the problem pi-warden solves, and it solves it 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.

That's the shape of problem the Jev model was built for: a judgment your software needs to make, fast, thousands of times, where the answer is a decision rather than a paragraph. This post covers what Jev is, how it works, what the numbers do and don't prove, what people are building with it, and six places it fits into a developer's stack.

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 that decisions cheap enough to make ten times a second will get made ten times a second.

The label comes from Daniel Kahneman's Thinking, Fast and Slow, which divides cognition into two modes: System 1 is the fast, automatic judgment you reach without stopping to deliberate, and System 2 is the slow, effortful reasoning you save for the hard problems. An LLM grinding through a chain of thought, one token after the next, is doing System 2 work. Jev is built for the other half, the snap decision.

For a developer the psychology matters less than the interface it implies. A System One model asks you to bound the answer before you ever make the call. You write the question and the finite set of values it can come back with, and your own code decides what to do with the result. Jev returns a typed decision (which team should own this, how severe it is, whether a statement holds), and the application keeps hold of the policy that acts on it.

That is the practical break from a chat model. Instead of open-ended prose you have to parse, trust, and defend against, you get an answer that already fits a shape your program was written to expect.

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 the important line under it is this: every question is evaluated in parallel and in isolation against the same state, so adding a question barely changes response time.

Here is the quickstart example, 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 }
}

Notice 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: the answer says what, confidence says 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's why output tokens are free: there is no autoregressive loop to pay for.

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 are explicit that this is the whole point of training a separate model rather than wrapping an LLM.

TypeSafe's chart puts Jev at 0% hallucination, and the launch post admits in the fine print that the number is not empirical: schema matching is guaranteed, so they wrote 0. The model cannot return an option that isn't in your list.

It can absolutely return the wrong option from your list. The most-replied comment on Hacker News, from jacobgold, put it plainly: it can't emit an invalid type, but it can still emit a wrong valid value. The Register made the same point. Treat "type-safe" as a property of the output format, not a promise about accuracy.

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 did not accept the framing quietly. 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. That's 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 result is the honest summary. 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.

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.

The community did not wait for those releases, and neither did Vercel: 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.

• 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: 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, not 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 are worth reading too. 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, not 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. Some upstream step produces state. Jev makes a judgment about it. 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 shape, not as tested output.

Web search returns ten results. Three 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. The agent then reads three pages instead of ten. 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. Some of those citations are wrong: 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 nobody does at 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 interesting verdict is contradicted. A quote can be accurate and the claim built on it still wrong, and that's the failure neither a string match nor a "does this page mention X" check will find. Run this on every citation before an answer ships and you get a hallucinated-source rate you can measure instead of guess at. It's the missing verification step in most grounded generation pipelines, 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 clearly: 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, not a security boundary. A page scoring 0.6 still reaches the prompt. 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. No waitlist, and a zero-data-retention option through the gateway.

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,
  });
}

Two details from the docs are worth copying. 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 is the other half of routing that 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 are blunt 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.

The r/codex thread had the cleanest one-line summary: it's a classifier model, incredibly useful, and not a replacement for an LLM. An early-access user on HN said the same from experience: it works in concert with LLMs, not as a replacement.

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.

There are two ways in. Direct access is by waitlist at typesafe.ai, and Reddit reports it arriving within hours for some and a day or more for others. Or skip the line: Jev is on Vercel AI Gateway as typesafe-ai/jev, callable from AI SDK 7's evaluate with a gateway key.

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 good calibration for expectations: slightly less accurate, dramatically cheaper, fast enough to run on every input rather than a sample.

The larger question Jev raises is whether most of what software needs from AI is a decision rather than an explanation. If that's true, a lot of the LLM calls in production pipelines today are paying for text nobody reads. The community's first 48 hours suggest plenty of developers already suspected as much.