Jev: The AI That Can't Write a Single Word (and Why That's the Point) and How to Set It Up

Sorted Pixels，From the desk of Tommaso Nervegna, an ongoing exploration of design, technology, and human creativity.关注

Every tool I’ve covered on Sorted Pixels has one thing in common: it talks. Usually too much. You ask for a yes or a no and you get three paragraphs, a bulleted summary and a polite offer to elaborate.

So when a model shows up whose entire selling point is that it refuses to write a single sentence, I pay attention.

It’s called Jev. It comes from a company called TypeSafe AI. And this week it went from “niche API launch” to “everyone on my feed is building something with it” in about four days. Newsletters dedicated whole issues to it. LangChain shipped an official integration and a tutorial. Vercel put it on their AI Gateway.

I’ll say it straight: Jev is not a better chatbot. You can’t even chat with it. What it does is make small decisions, thousands of them, and I think that’s a piece product people, PMs and designers alike, have been missing for a while.

Sorted Pixels is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

What it actually is

You give Jev a situation (they call it a state) and one or more closed questions about it. It gives you back typed answers with probabilities. No prose, no reasoning trace, and mercifully no “Great question!”.

There are three shapes of question:

  • Noul. A yes/no judgment. You get back the probability that the statement is true. 0.97 is a strong yes, 0.5 is a shrug.
  • Choice. Pick one from a closed list. You get the probability of every option plus an overall confidence value.
  • Score. Rate something along ordered levels, like low, medium, high. You get a continuous score, the distribution behind it, and a confidence value.

You can stack many questions in one request about the same state, and they get evaluated in parallel. Ten questions cost roughly the same time as one. TypeSafe’s own cookbook reports that batching 13 questions into a single call came out about 12x cheaper and 10x faster than asking them one by one, with identical answers.

One message, three questions, three typed answers. Image: LangChain / TypeSafe AI.

The founder, Diogo Almeida, was one of the primary authors of the InstructGPT paper and worked on GPT-4. The launch material calls him a “co-creator of ChatGPT”, which is generous given how many people built that thing. Still, I like the irony: one of the people who taught models to chat is now betting on a model that won’t.

TypeSafe calls this category “System One”, as in Kahneman. The fast, gut-feeling part of thinking. Your big LLM stays System Two, the slow one that overthinks everything.

If you want to see the difference before reading on, TypeSafe’s launch post has a side-by-side recording of Jev and a frontier LLM answering the same set of questions. One fills in all the answers at once while the other is still typing. It sold me more than any benchmark.

Why product managers and designers should care

After a couple of years designing agentic products, the thing that surprised me most is how little of the work is text. It’s mostly decisions.

Which tool next? Is this request simple or complex? Retry or stop? Is this output good enough to show the user, or does a human need to look first? Is this action safe to run?

Today we solve every one of those by asking a chatty model for JSON and hoping it behaves. Every tiny decision costs a full LLM call. It’s slow, it’s expensive, and the “confidence” you get back, if you ask for one, is just more generated text. The model writes a number. It doesn’t measure anything.

With Jev the probability is the actual output, and it’s calibrated (or so they claim, more on that later). For a designer that number is something you can work with.

At 0.95 the agent acts silently. At 0.7 it asks for confirmation. Below 0.5 it hands the case to a person. Whoever picks those three numbers is deciding how much the product trusts itself, and how much it bothers the user. I’d rather that be someone who knows the user than a default left in a config file.

If you’re a PM, there’s a second reason to care, and it’s on the invoice. When every small decision costs a full LLM call, you ration them: fewer checks, fewer guardrails, fewer moments where the product stops to verify itself. When a decision costs a fraction of a cent, that constraint goes away and the roadmap changes. Things you cut for cost or latency, like checking every output before the user sees it, are suddenly back on the table. And the thresholds above are product policy as much as UX: how much risk you accept, when you involve a human, what that costs per task. Those are your numbers to own, together with design. TypeSafe’s own docs say it plainly: use higher thresholds for anything costly, destructive, financial or hard to undo.

I’ve been boring people with “orchestration, not decoration” for a while now. This is the first time I can point at an API and say: that.

What a decision layer looks like on paper: many small questions, thresholds and branches in code. This is the simplest of TypeSafe’s four published workflows. Image: TypeSafe AI.

Two patterns you can steal

LangChain’s official tutorial shows two patterns. You can ignore the Python, the ideas are what matter.

One. Model routing. Not every request deserves your most expensive model. A lookup and a gnarly architectural question should not cost the same. With routing, Jev reads the incoming request and picks the model based on criteria you write in plain language: cheap and fast for direct lookups, the heavy one for high-stakes work. The part I like: the routing policy is a sentence in plain English. You don’t need an engineer to write it or to argue about it.

Two. Auto Mode. This is the one I find more interesting. Coding harnesses like Claude Code, Codex and Cursor all ship some kind of classifier that flags dangerous actions before they run. It’s a big part of why we’ve slowly learned to trust them. But that layer has always been locked inside the closed part of the product. With a cheap, fast classifier, the same pattern is available to any agent: Jev checks each tool call for risk and blocks it before execution.

So the safety layer we could only admire from outside in Claude Code or Cursor is now something you can build into your own product. What counts as risky, how sure the system has to be, what the user sees when something gets blocked: those are now your calls.

There’s talk in the LangChain community that Jev is bringing back the “graph engineering” phase of agent design: explicit nodes, explicit branches. I hope so. Graphs are a thing designers are actually good at.

The trust layer: more freedom without blind trust

Layton Gott published a long list of places where Jev fits inside an agent, and his starting observation is the right one: agents burn an absurd amount of frontier intelligence on tiny questions. Should I retry? Did this actually finish? Is this risky? Most of his list is engineering. Four items are really experience design, and those are the ones I’m stealing.

The irreversible action gate. Before an agent sends, deletes, merges, refunds or publishes, ask a handful of closed questions about the consequences. Can this be undone? Does it touch another person? Money? Private data? Is it clearly authorized? Then map the answers to behavior: confident and reversible means go, uncertain but reversible means go and log, irreversible means review, unauthorized means block. If you’ve ever drawn a service blueprint, you already know how to do this.

Permissions that expire with the task. Today we hand agents permanent keys to Gmail, Stripe and the database, which is like giving a contractor your house keys for life. The alternative: generate a permission set for the job at hand. Fixing a failed payment? Read access to billing, yes. Refunds, ask me first, capped at a small amount. Sending email, no. When the task ends, the permissions disappear. We’ve been designing consent flows for years. This is one.

The human queue, redesigned. Nobody can supervise a fleet of agents by approving every action. So don’t. Surface only the weird ones: low confidence, high cost, high consequence, or simply new. Everything else stays automated. One operator can watch far more workflows without becoming the bottleneck. Anyone who has designed a moderation console or a back-office tool knows how hard that screen is to get right.

The spend firewall. Same logic applied to money: approve, review or deny, with deterministic code owning the actual payment and the hard limits.

One more lesson from the same list, about question writing. When qualifying a lead, fit and intent must be two separate questions. A perfect customer may have zero interest today. Someone begging for a demo may be completely outside your market. Collapse them into one question and you get a plausible number that means nothing. I keep finding traps like this every time I break a decision down.

Three apps you can build without writing code

The pattern that spread fastest this week needs no engineering team. Your coding agent (Claude Code, Codex) is the builder, Jev is the judge, and you are the person who writes the questions. Three builds worth copying:

  1. Network triage. Export your LinkedIn connections and pending invitations, and filter tens of thousands of people down to the few hundred actually worth a personal message before a launch. Questions like: is this person in my target audience, which segment do they belong to, how strong is the fit.
  2. Contact cleanup. Thousands of auto-collected email addresses sorted into Keep, Review and Remove. Anything that looks like a real person and doesn’t clear a high bar goes to Review, never straight to Remove.
  3. Research filter. A firehose of new papers narrowed to the handful that matter for a specific reader, scored for relevance and practical usefulness. People are reporting hundreds of papers processed for a few cents, in seconds.

The setup guide below gets you to the point where you can build any of these. But the interesting part is the architecture they share. Four lessons:

Division of labor. Jev judges meaning, and only meaning. Code does all the counting, dates, matching and tier math. The big model writes prose, and only for the final shortlist.

Escape hatches everywhere. Every Choice question gets an “other” or “unclear” option. Rows with no signal never reach Jev at all, they go to a “no signal” bucket. Anyone who has ever designed a survey knows this rule. Turns out it applies to machines too, and for the same reason: if the right answer isn’t on the list, the probability still has to land somewhere. Langfuse, who tested Jev as an eval judge, put it bluntly: it cannot abstain. Force a binary with no “unknown” and it will pick the least wrong answer rather than tell you it doesn’t know.

Thresholds as a user control. The best versions of the triage app expose the classifier to the user: you can rewrite the questions inside the app, and sliders recompute the tiers instantly from stored probabilities, with no new model calls. The threshold becomes a slider the user can play with, which is exactly where I think it belongs.

Question writing is the craft. The single most useful instruction you can give your coding agent: show me the questions before building anything. Agents write mediocre questions. The model costs nothing and the code writes itself, so what’s left is knowing what to ask and how to word the options. That’s us.

What people built in the first week

The community numbers are more fun than the vendor ones, so here they are, with their fine print:

  • Browser Use (Gregor Zunic, @gregpr07) put Jev inside a browser agent that found flights in about 7 seconds for $0.0039. The clever part is the design: the list of possible actions is rebuilt from the page at every step, Jev picks one, and a small LLM steps in only when text needs typing. Fine print: the clock starts after the first page read, and it finds flights, it doesn’t book them.
  • Hassan (@nutlope) classified 1,018 AI research papers into 24 topics for $0.08 in total, at a median of 256ms per paper, and published the result as 1kpapers.com. Fine print, from Hassan himself: summarizing the papers with an LLM first cost another $3.99. The judging was fifty times cheaper than the reading. He followed up with a fraud detection demo that routes anything under 95% confidence to a bigger model, with the code on GitHub.
  • Riley Brown (@rileybrown) triaged 500 emails in seconds for 3.5 cents.
  • Tamara Tran (@tamarajtran) used it for context compaction: instead of asking an LLM to summarize a long session, score every tool call for relevance and drop the rest. It’s open source as fast-jev-compaction, a Claude Code plugin. Alex Volkov (@altryne) reports it took his Claude session from nearly 1M tokens to 86K in about a second. Fine print: Theo (t3.gg) pushed back hard, arguing that compaction is meant to keep an agent focused, and that judging tool calls one by one misses the context of the thread. Worth reading both before you install it.

That last one is my favorite, because nobody at TypeSafe planned it. Make something cheap enough and people find uses you never imagined. Jevons would be smug.

The numbers, with salt

I’ll ruin the party a little.

The headline figures are everywhere: up to 193.6x faster and 444.6x cheaper than LLMs. Early access pricing is $0.042 per million input tokens, with output unmetered because there barely is any. You get $5 of free credit, which at that price covers hundreds of thousands of questions. The name is a nod to Jevons paradox: make a resource radically cheaper and total consumption goes up. TypeSafe’s bet is that you won’t save money. You’ll just start asking a hundred times more questions.

But those numbers come from TypeSafe’s own evaluations. The most careful independent read I found is Anthony Maio’s, and it’s worth your time. The short version:

  • On TypeSafe’s four test workflows, Jev averaged 67.8 percent agreement with the reference answers. That’s on par with mid-tier models at a fraction of the cost. But the frontier models landed around 73 to 74 percent, and on invoice processing the gap was brutal: 61.8 against 79.1.
  • The “reference answers” were themselves produced by averaging two frontier LLMs, not by real-world ground truth.
  • The training method (they call it RLCD, reinforcement learning for calibrated decisions) is undisclosed. No paper, no published calibration curves.
  • It’s still in beta, and the docs say behavior may change without notice.

Also, “it can’t hallucinate” needs a footnote. Jev can’t invent a field or return malformed output, which kills a real category of bugs. But a well-formed answer can still be the wrong answer, delivered with great confidence.

And a note on sources. LangChain and Vercel are launch partners, and a good share of the enthusiastic newsletters sell workshops on the setup. None of that makes them wrong, but treat them as how-to guides, not as independent validation.

Accuracy versus cost, log scale. Jev is the pink diamond on the far left. Now look at the pairs: diamonds are models inside a workflow, circles are the same models with one big prompt. The diamond wins every time. Chart: TypeSafe AI, from their own evals.

One more finding, the one that stuck with me. In TypeSafe’s own benchmark, every model, including the big ones, got more accurate, faster and cheaper when placed inside an explicit workflow instead of being handed one giant prompt. So the big lesson of their benchmark has little to do with Jev: break the work into small steps and everything gets better.

Where it fits, where it doesn’t

Don’t use it for anything that needs prose, multi-turn conversation, open-ended answers, tool calling, or a long chain of dependent reasoning. And remember that a probability is not an explanation. If your product needs evidence, appeals or an audit trail, you need another layer on top.

The sweet spot is the control layer around your agents. The generative model drafts and plans, Jev makes the small calls, code enforces the rules, and people handle whatever is ambiguous or high-stakes. No single very talkative loop has to be trusted with everything.

Try this before you touch the API

You can get most of the value here without an account. Take one flow you own, a support journey, an onboarding, an approval process, and do this:

  1. List every decision hiding in it. Decisions, not screens. There are always more than you think.
  2. Rewrite each as a closed question. Yes/no, pick one, or rate on a scale. If you can’t, the decision isn’t well defined yet, and that’s a finding.
  3. Add the escape hatch. “Other”, “unclear”, “not enough information”. Always.
  4. Design the three zones. What happens at high confidence, at medium, at low? Who sees what? What’s reversible?
  5. Mark the irreversible ones. Those get the highest bar and a human.

That’s a decision layer, and you designed it on paper. Whether Jev or something else ends up running it matters less than you’d think.

Setup guide: from zero to your first decision

Two paths. Pick the one that matches how you work. Both take about fifteen minutes.

Path A: no code, through Claude Code or Codex

This is the route I’d recommend if you don’t write code for a living. You never call Jev directly. You install a skill that teaches your coding agent how to use it, then you describe what you want.

1. Create a TypeSafe account. Go to typesafe.ai and sign up. It’s free, no credit card, and you start with $5 of credit. At current prices that is more questions than you will ask this year.

2. Install the TypeSafe skill. Open Claude Code (or Codex) and run these two commands, using claude or codex depending on your tool:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Type /typesafe afterwards. If the skill shows up, you’re good. Using a different coding agent? With Node installed, npx skills add typesafe-ai/skills --skill typesafe-ai does the same and lets you pick your tool.

3. Create an API key. In the TypeSafe console, generate a key. Paste it once when the skill asks for it, and click Allow.

4. Start with a plan, not a build. If you’re on Claude Code, switch to Plan mode first. Then describe the job in plain language: what the data is, what you want to know about each row, and what should happen with the answers. Tell the agent to use the TypeSafe skill for every Jev question.

5. Review the questions before anything gets built. This is the step people skip. Ask the agent to show you every question, every option and every threshold first, and wait for your approval. The questions are the design. Everything else is plumbing.

Optional, for the bigger builds: the three apps above also benefit from connecting GitHub (to store the code), Vercel (to put the app online) and Apify (to enrich LinkedIn data). You don’t need any of them for a first experiment on a CSV.

Path B: a few lines of code

If you or someone on your team writes code, the official SDKs are tiny.

Python (3.10 or later):

pip install typesafe-sdk
export TYPESAFE_API_KEY="your-key"

python

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient()

response = client.system_one(
    state="I was charged twice this month. Please fix this today.",
    questions={
        "team": Choice(
            instructions="Which team should handle this message?",
            criteria={
                "billing": "Payments, invoices, refunds",
                "technical": "Bugs, outages, integrations",
                "other": "Anything that fits neither",
            },
        ),
        "urgent": Noul(
            instructions="The message conveys urgency or time pressure",
        ),
    },
)

print(response.choices["team"].choice)
print(response.nouls["urgent"].noul)

JavaScript / TypeScript: npm install @typesafe-ai/sdk, same environment variable, same shape.

Already on another stack? You may not need a new account at all. Jev is available through Vercel’s AI Gateway (the AI SDK’s experimental_evaluate with model typesafe-ai/jev), through LangChain (pip install langchain-typesafe, then TypeSafeClassifier), and through OpenRouter.

Your first test, whichever path you took

Don’t start with your entire LinkedIn network. Start with twenty rows you know well: twenty support tickets, twenty pieces of user feedback, twenty briefs. Ask three questions about each (one Noul, one Choice, one Score) and compare the answers with your own judgment.

Look at two things. Where it disagrees with you, and how confident it was when it did. Confidently wrong answers almost always point to a badly written question or a missing option, not to the model. Fix the wording, run it again. That loop is the actual work.

Before anything touches production, scale the same idea up. Take a decision your system already makes, collect a few hundred historical cases where you know what should have happened, and run Jev against them. Record accuracy, false positives, false negatives, confidence, latency, cost. Then run it in shadow mode: let it decide without acting, and compare with what actually happened. Only then hand over control. And remember what confidence means here. TypeSafe’s docs are explicit that calibration holds across groups of predictions. A 0.95 is not a guarantee about this one answer.

A shortcut for this step: the TypeSafe console has a Playground. State on the left, questions on the right, run. No code, no agent. It’s the fastest way to develop a feel for how question wording moves the probabilities.

Nine habits to adopt from day one

  1. Always include an escape option. “Other”, “unclear”, “not enough information”.
  2. Describe situations, not degrees. “Customer mentions a deadline or lost revenue” beats “very urgent”.
  3. Keep math out of it. Counting, dates and comparisons belong in code. Jev judges meaning.
  4. Set thresholds per action, not globally. Routing a ticket and issuing a refund should never share a confidence bar.
  5. Keep the key server-side and log the model version. The response tells you exactly which version answered. Thresholds tuned on one version may drift on the next, and it’s still a beta. For anything serious, pin a specific version instead of jev-latest.
  6. Send less. Give each question only the fields it needs. Extra state can lower accuracy, which is the opposite of what LLMs taught us.
  7. Rebuild the menu. Options should reflect what is possible right now: the workers that are available, the buttons that are on the page. A static list means the model is choosing from yesterday’s menu.
  8. The key name is invisible. Jev never sees the ID you give a question. Calling it safe_to_publish tells it nothing. The requirement goes in the instructions, and every option gets a clear description.
  9. Never trust “done”. A confident answer cannot prove that a file was saved or an email was sent. Check outcomes independently, and measure cost per completed task, not per decision. A cheap decision that sends a worker down the wrong branch is expensive.

Watch

If you prefer video, these are the ones worth your time. Paste each link on its own line and Substack will embed it.

The three question types, explained. The walkthrough LangChain links to in its own tutorial:

The balanced take. Fast and cheap, with the “it isn’t an LLM” caveat front and center:

The ten-minute news version. Tech Brew Ride Home on what Jev is and why it matters:

Hands-on with agents. Jev driving a browser-use agent, tested end to end:

For the technically curious. A livestream coding session that also speculates on the architecture behind it:

Live session. LangChain and TypeSafe are hosting Building a Harness with Jev, covering routing and tool-call guardrails.

Where this is going

Gott closes his piece with a prediction I share: we spent years assuming one giant model should do everything, and that architecture suddenly looks expensive. The likely future is one frontier model for the hard thinking, surrounded by small specialists for decisions, retrieval and routing, with code owning the rules. That means more parts and more seams between them, which sounds to me like more design work, not less.

Whether Jev’s calibration claims survive independent testing is an open question, and I’ll happily come back to this when someone outside TypeSafe has published real numbers. In the meantime I’ve started looking at every agent flow I work on and asking how much of it actually needs to talk. Less than I thought.

Sources and further reading

Thanks for reading Sorted Pixels! This post is public so feel free to share it.

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论