Jev, Explained: The Decision Model That Can't Write a Sentence — And Why We'd Use It to Score 10,000 Landing Pages

There is a model that went from unknown to 35% of Vercel's paid teams in two weeks, and it cannot write a single sentence.

Jev, from a San Francisco company called TypeSafe AI, shipped in limited early access on September 15, 2026. By October 16, TechCrunch reported it as the fastest-adopted model in the first two weeks of any launch Vercel has tracked — roughly double the reach of the second-place model, Sonnet 5.5. Within the first 24 hours, nearly 13% of paid teams on Vercel's AI Gateway had tried it. The company briefly lost the ability to serve its own API because demand outran capacity. Three weeks after launch, OpenAI shipped a competing product that its own product lead admitted had not been on the roadmap four weeks earlier.

All of that for a model whose entire job is to answer questions you already know the possible answers to.

This post is the long version: what Jev actually is, the full API shape, the real numbers, the honest list of where it falls apart, and then the part most coverage skips — a concrete build. We run a landing page analysis product, so the worked example is a conversion-scoring pipeline. But the pattern generalizes to any judgment you make too rarely because it costs too much.

The Short Version

You send Jev two things: a state (a blob of text or JSON — a support ticket, a page's HTML, a product description) and a set of questions, each with a declared type. It sends back one structured answer per question, plus a probability distribution and a confidence number.

It does not send back prose. There is no "here's my reasoning." There is no stream of tokens. There is a typed value.

TypeSafe calls this a System One model, borrowing from Daniel Kahneman's System 1 — the fast, intuitive, low-deliberation half of human cognition. The framing is doing real work here. Everything the frontier labs have optimized for over the last three years is System 2: chain-of-thought, extended reasoning, agentic loops, test-time compute. Jev is a bet that an enormous share of production AI calls were never System 2 problems in the first place. They were classifications wearing a chat interface.

Where It Came From

TypeSafe AI was founded in 2024. The CEO is Diogo Almeida, who spent roughly four years at OpenAI working on RLHF, InstructGPT, ChatGPT and GPT-4 before leaving. His co-founders are Erik Gafni and Sasha Sheng. The Jev launch coincided with a $40 million seed round led by DCVC.

Almeida's framing of why he left is worth quoting, because it explains the product: "the main product of frontier labs is fear or hype. I would like our main product to be intelligence." His description of the company's core bet is less philosophical and more interesting: "We made an early bet that we will be making all of our data, and that has been one of the best bets I've ever made in my life — better than our launch, in my opinion, better than RLHF."

Jev is trained entirely on synthetic data, via a method TypeSafe calls Reinforcement Learning for Calibrated Decisions. The architecture is undisclosed — the company says "transformer-based" and has published no weights or papers. Outside observers suspect an open-weight LLM underneath with a modified head. Almeida has also been candid that the hard part wasn't capability: "Making the models reliable was so much harder than expected," taking two years rather than the week a naive version would suggest.

The name is the thesis. Jev is short for William Stanley Jevons, the 19th-century economist behind the Jevons paradox: make a resource more efficient and total consumption goes up, not down. Almeida's expectation is that radically cheaper machine judgment leads to far more of it — "there's just going to be smart software all over the place in a way that's emergent and distributed … much more like the early internet."

Hold onto that. It's the part that actually matters for anyone building a product, and I'll come back to it at the end.

The Four Primitives

Everything Jev does is one of four question types. This is the entire surface area of the model, which is unusual enough to be worth stating plainly.

Note the fourth one. Early coverage of Jev — including Fortune's October 8 piece — described it as text-only, and contrasted that with OpenAI's image-accepting competitor. The docs now carry an images page and a box primitive for localization, so that gap has at least partly closed. If you read a comparison written in September, re-check it.

The Actual API

This is the part worth internalizing, because the shape of the request is the design philosophy. One state, many questions, all evaluated in parallel and in isolation.

POST https://api.typesafe.ai/v1/systemone

{
  "state": "Our API integration started returning 500 errors...",
  "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:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 1.0,
      "probabilities": { "technical": 1.0, "billing": 0.0, "sales": 0.0 }
    },
    "frustration": {
      "type": "score",
      "score": 0.67,
      "confidence": 0.5,
      "probabilities": { "0": 0.33, "1": 0.67, "2": 0.0 }
    },
    "is_urgent": { "type": "noul", "noul": 0.99 }
  }
}

Two details in there that matter more than they look.

First: criteria is an object for choice and an array for score. For choice, the keys are the values you get back and the values are definitions. For score, the array order is the scale — index 0 is the bottom level. That's why score returns a fractional number (0.67 above): it's a probability-weighted average across levels, not a hard pick. You get the nuance of "somewhere between level 1 and level 2, closer to 1" for free.

Second: jev-latest is a trap in production. The response echoes the resolved version — jev-1.13.0 here. The alias can advance underneath you and change behavior between your evaluation run and your production traffic. Pin the version explicitly and re-run your evals before you move it. This is the single most common mistake I'd expect teams to make with it.

The SDKs are thin wrappers. TypeScript:

import { choice, noul, score, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient({ defaultModel: "jev-1.13.0" });

const response = await client.systemOne({
  state: ticket,
  questions: {
    department:  choice("Which team should handle this", { billing: "...", technical: "...", sales: "..." }),
    frustration: score("How frustrated the customer appears", ["Calm...", "Frustrated...", "Very angry..."]),
    is_urgent:   noul("The message conveys urgency or time-sensitivity"),
  },
});

The Numbers, With Their Caveats

Here's what's published, and what to discount.

On accuracy, TypeSafe reports 67.8% across four benchmark workflows at $0.0004 and 0.4 seconds per case, rising to 76.0% at $0.0001 on its best-performing workflow. For comparison on the same suite, GPT-5.6 Sol lands at 74.1% — at roughly two hundred times the cost.

Now the caveat, which TypeSafe states itself and which you should take seriously: the benchmark workflows were designed by TypeSafe's own model-capabilities team. The company acknowledges they "may be biased compared to real-world tasks." A 67.8% that the vendor constructed tells you very little about your 67.8%.

Independent signal is more useful. On JudgeBench — which is deliberately reasoning-heavy — Jev reportedly lands at 78.6% against GPT-6's 93.1%. That gap is the honest shape of the tradeoff: on bounded judgments it's competitive, and the further your task drifts toward novel reasoning the worse the deal gets.

Calibration is the other number worth knowing. A third-party review measured expected calibration error at 0.071 out of the box, improving to 0.025 after temperature fitting on the reviewer's own labels. That second figure is the actionable one: if you care about confidence thresholds, you need to fit them on your own labeled data. Vendor calibration is a starting point, not a setting.

What Practitioners Actually Reported

The early production stories are more informative than the benchmarks, because they're all comparisons against something the team was already paying for.

Vercel replaced GPT-6 Luna with Jev in the safety classifiers that screen harmful commands. Software engineer Pranit Sharma reported it ran 5 to 18 times faster with greater accuracy.

Bryo AI tested it against Gemini for business email classification. CTO Nikhil Mudholkar found Jev 10 to 20 times cheaper, with Gemini slightly more accurate — and then said the thing that explains the adoption curve better than any benchmark: "it is the only one that hands back a real probability which makes it ideal for automating workflows!!"

That's the actual product. Not speed, not price. A number you can threshold on.

An LLM asked to rate something 1–10 gives you a token that looks like a number. You have no idea whether "7" means 7.0 or "somewhere between 6 and 8 and I'm guessing." Jev gives you the distribution. Which means for the first time you can write the line of code everybody actually wants to write: if the model isn't sure, don't act — escalate.

Other reported production uses: spelling and grammar checking (Daily), environmental compliance (Atlensa), software change screening (Dext), ingredient classification (GlutenOrNot), plus a cluster of infrastructure uses — model routing, monitoring LLM agent traces for jailbreaks, and acting as a behavioral guardrail around a larger model.

The Real Unlock: Judgment You Could Never Afford

Here's the reframe that made this click for me.

Every product has a list of judgments it would love to make on every item but makes on a sample instead, or on nothing at all, because the per-item cost doesn't survive contact with the volume. You review 20 of 4,000 support tickets. You read 50 of 10,000 reviews. You A/B test 2 of 40 headline ideas because each test costs two weeks of traffic.

At $0.0004 a decision and 400ms, that constraint dissolves. Not "gets cheaper." Dissolves. 10,000 judgments costs four dollars.

And critically, because all questions in one request run in parallel and in isolation, asking more questions is nearly free in latency. TypeSafe's own guidance is explicit that adding questions "barely changes latency and does not create context-rot." The economics push you toward decomposition — which happens to also be what makes the output good.

Worked Example: A Conversion Scorer

We score landing pages across eight weighted dimensions at roast.page, using a frontier model with vision because the job genuinely needs System 2 — it has to write the critique, reference specific elements, and produce a prioritized fix list a human will act on. Jev can't do that and shouldn't try.

But that's the report. The scoring underneath it is a different shape of problem, and it's exactly the shape Jev is built for. So here's how I'd build a page scorer with it — the pattern TypeSafe documents as composite scoring: decompose the judgment into independent dimensions, score each one separately, then combine with weights you control in code.

Start with the state. The temptation is to throw the whole HTML document in. Don't. The docs are blunt that you should "include only the context relevant to the current questions," and the 32k state budget plus the real risk of context rot both argue for extraction first:

const state = {
  url: page.url,
  meta: { title: page.metaTitle, description: page.metaDescription },
  hero: { h1: page.headings.h1, subhead: page.firstParagraph },
  ctas: page.buttons,
  headings: page.headings.h2,
  trust: {
    testimonial_count: page.testimonialCount,
    logo_count: page.logoCount,
    has_named_attribution: page.hasNamedTestimonials,
  },
  body_text: page.extractedText.slice(0, 6000),
};

Then the questions. One per dimension, each with described levels rather than a bare 1–10 scale — the levels are what make scores comparable across pages:

const questions = {
  hero_clarity: score(
    "Can a first-time visitor state what this product does, from the hero alone",
    [
      "Cannot tell what is being sold",
      "Category is clear but the specific product is not",
      "Product is clear but the benefit is generic",
      "Product and specific outcome are both clear",
    ]
  ),

  copy_specificity: score(
    "How specific and concrete is the body copy",
    [
      "Pure abstraction and category language",
      "Mostly features described generically",
      "Some concrete outcomes, numbers, or named customers",
      "Consistently specific, quantified, falsifiable claims",
    ]
  ),

  cta_clarity: score(
    "Does the primary CTA make the next step and its cost obvious",
    [
      "No identifiable primary action",
      "Action exists but is vague ('Learn more', 'Get started')",
      "Action is clear but commitment level is ambiguous",
      "Action and commitment are both explicit",
    ]
  ),

  trust_evidence: score(
    "Strength of verifiable social proof",
    [
      "None",
      "Unattributed quotes or anonymous logos",
      "Named people or companies, no specifics",
      "Named sources with specific, checkable outcomes",
    ]
  ),

  // Binary checks — cheap, and they make great regression assertions
  has_jargon_headline: noul("The main headline relies on buzzwords or industry jargon"),
  states_pricing:      noul("The page states a price or explicit pricing information"),
  names_audience:      noul("The page explicitly names who it is for"),
  hero_has_proof:      noul("Social proof appears above the fold alongside the hero"),
};

One request. Eight judgments. Roughly 400 milliseconds. Then combine deterministically — in code, where you can read it, version it, and change your mind:

const a = response.answers;
const norm = (k: string) => a[k].score / 3;   // four levels → 0..1

let composite =
  0.30 * norm("hero_clarity") +
  0.30 * norm("copy_specificity") +
  0.20 * norm("cta_clarity") +
  0.20 * norm("trust_evidence");

// Binary signals as explicit, auditable adjustments
if (a.has_jargon_headline.noul > 0.7) composite -= 0.05;
if (a.names_audience.noul > 0.7)      composite += 0.03;
if (a.hero_has_proof.noul > 0.7)      composite += 0.03;

const score100 = Math.round(Math.max(0, Math.min(1, composite)) * 100);

// Confidence gate: only trust what the model was actually sure about
const weakest = Math.min(
  ...["hero_clarity", "copy_specificity", "cta_clarity", "trust_evidence"]
    .map((k) => a[k].confidence)
);
const needsReview = weakest < 0.5;

The thing I want to point at is that last block. The weights live in your source control, not in a prompt. When someone argues that trust should matter more than CTA clarity, that's a one-line diff with a git history — not a prompt rewrite that silently changes forty other behaviors. The model supplies judgment; your code supplies policy. TypeSafe's phrase for this is "keep code in control," and it's the correct instinct.

Five Things This Makes Newly Possible for Marketers

Beyond scoring a single page, these are the uses where the price change alters what's actually achievable.

1. Pre-screen variants before you spend traffic. Generate 40 headlines with an LLM, then score all 40 on clarity, specificity, and jargon with one Jev call. Test the top three. Your A/B testing bottleneck was never idea generation — it was that each test costs weeks of traffic. Scoring doesn't replace the test; it stops you from spending a test slot on an obvious loser. We've written about prioritizing which tests to run, and this slots directly into the top of that funnel.

2. A conversion regression gate in CI. This is my favorite. Run the scorer against your production page on every deploy; fail the build if composite score drops more than a few points, or if a binary assertion flips — states_pricing went false, hero_has_proof went false. Marketing pages decay by a thousand small edits nobody reviews. At $0.0004 a check, there is no reason not to have a test for it.

3. Competitive sweeps at full coverage. Score every competitor's landing pages on the same rubric, every month. Not a sample. All of them. The output is a comparable time series rather than a vibe, which is a different kind of input to a positioning conversation. Pair it with a proper teardown on the handful that move.

4. Review and UGC triage at volume. Classify every inbound review, support ticket, and sales-call note against the objection taxonomy you actually sell against. The output is a ranked list of what prospects don't believe — which is the single most useful input to landing page copy and the one most teams substitute with guessing.

5. Claim auditing. Run every marketing claim on your site through a noul question: "this statement is specific and verifiable." Sort ascending. You now have a prioritized list of the places your page is asking for trust it hasn't earned — the exact failure mode behind the trust gap.

Where Jev Breaks

This is the section the vendor pages leave out, and it's the one that will actually save you money.

It cannot explain itself. There is no reasoning trace. You get a probability and no way to audit why it landed there. This puts a hard ceiling on where you can deploy it — any decision a human may later need justified in writing is a bad fit. Mitigation is logging discipline: capture the exact state sent, the questions asked, the resolved model version, and the full probability distribution. Without that you cannot investigate a bad call at all.

It is bad at things that aren't judgments. Counting, arithmetic, and date comparison are documented weak spots. The guidance is to do that work in code before you call. If your question is "is this more than 30 days old," compute it and put the boolean in the state. Don't ask.

The state field is a prompt-injection surface, and type safety does not protect you. This deserves emphasis because the marketing invites the wrong conclusion. Schema constraints guarantee you get a well-formed value from your declared set. They say nothing about whether that value is right. TypeSafe's "0% hallucination" claim refers to schema conformance, not factual accuracy.

The reported numbers here are genuinely alarming. In one security review, a fake pre-approval note in the state dropped the probability of blocking a destructive command from 0.76 to 0.48 — and dropped confidence from 0.64 to 0.22. Community testing found a one-line override instruction collapsing accuracy from 96.5% to 26.5% on a Wikipedia deletion-discussion task. Simply swapping the order of rubric labels changed 32.5% of responses. If your state contains anything a user can write — and for a landing page scorer, the page itself is attacker-controlled if you're scoring other people's pages — you are exposed.

It carries measurable social bias. Researchers Nouar AlDahoul and Yasir Zaki at NYU Abu Dhabi ran forced-choice conjoint experiments on Jev 1.13's friend recommendations, randomizing gender, race, marital status, profession, and zodiac sign. The model showed systematic preferences: women as shopping partners, Asian candidates for trying international cuisine, Sagittarians as travel companions, Capricorns for career advice. The zodiac findings are the tell — there is no plausible signal there, so the correlations are arbitrary structure learned from synthetic data. If you are using Jev anywhere near a decision about people, test for this on your own data before you ship.

Confidence is not the probability of being correct. The docs say this directly and it's easy to forget. Calibration holds across groups of predictions, not within any individual answer. A confidently wrong answer sails straight through a confidence gate. Suggested starting points — 0.7 for yes and 0.3 for no on noul; below 0.5 route to review, above 0.9 for automatic high-stakes action — are starting points to be re-fit on your labels, not thresholds to adopt.

The savings can evaporate. If your current pipeline already uses aggressive prompt caching on a cheap model, Jev's cost advantage narrows considerably. Measure your real workload before migrating anything.

And it's closed. No weights, no paper, hosted-only, US-only hosting with no documented regional choice, and a retention policy that reads "as long as reasonably necessary" (zero retention is negotiable via sales). TypeSafe commits to not training on your prompts. Redact personal data before it goes in the state field, because the state is the entirety of what the vendor sees.

The Field Got Crowded in Three Weeks

Armin Ronacher predicted at launch that "competitors will spring up now that its utility is apparent." That took about twenty days.

OpenAI's product lead Nikunj Handa credited Jev with "inspiring this whole thing." DCVC's James Hardiman, naturally, argues that "in production, Jev will perform better." The honest read: the category is three weeks old, nobody's independent benchmarks are settled, and the open-weight options mean the floor price for this capability is already zero. Build against the pattern, not the vendor. Your weights, thresholds, and rubric are the durable asset; the model behind them is a config value.

What This Actually Means

The Jevons reference isn't cute branding. It's a prediction, and it's the part that should change how you plan.

When judgment costs $0.03 a call, you ration it. You sample. You build a dashboard and check it weekly. When it costs $0.0004 and returns in 400 milliseconds, rationing stops being the right design. You judge everything, continuously, and spend your actual intelligence budget on the small fraction that turns out to be uncertain or important.

For landing pages specifically, that means the end of the annual audit as a unit of work. Not "we reviewed the page in Q3." Every page, every deploy, scored on a rubric that lives in version control, with regressions failing the build like any other test. The reason nobody did this before wasn't that it was a bad idea. It was that it cost too much to be worth it.

That constraint is gone. Most teams haven't noticed yet.

How We Think About It at roast.page

To be straight about where this fits for us: Jev is not a replacement for what roast.page does. Our product writes a critique — it names the specific headline that's failing, explains why, and gives you an ordered list of fixes. That requires vision, reasoning, and prose. It's System 2 work and we use a frontier model with images for it, deliberately.

What a decision model changes is the layer underneath: continuous monitoring. A full analysis is something you run when you want to understand a page. A composite score is something you can run on every page you own, every day, and only read when it moves. Those are complementary jobs, and the useful mental model is that cheap judgment tells you where to look while expensive reasoning tells you what to do.

If you want to see what the System 2 version looks like on your own page, run it through roast.page — eight dimensions, a prioritized fix list, about 30 seconds, no signup. Then go build the cheap version that watches it.

For more on how AI is reshaping what landing pages need to do, see our guides on the AI optimization workflow, how AI is splitting A/B testing in two, and the agent traffic nobody's tracking.