Jev: How Its Decision API Works and What People Build

TL;DR: Jev is TypeSafe’s proprietary model for typed decisions: the application passes in state and defines the allowed answers in advance, while the API returns a choice and probabilities instead of free-form text. This contract guarantees the shape of the result, but not its correctness.

On September 15, TypeSafe unveiled Jev and kicked off a week of tech hype. The launch post racked up around 33 million views. Two days later, a browser agent was already searching for flights in seven seconds, a trading bot had appeared, and one developer claimed to have rebuilt Tesla Full Self-Driving on Jev in an hour. Another day later, Jev had made its way into gateways, databases, plugins, and content filters.

I went through a hundred posts and projects built on Jev across Twitter, Reddit, and GitHub and picked the 15 most revealing cases. Below, we’ll look at the API contract, how jev-ultrafast works, the math behind those seven seconds, and what in all these demos you can actually trust.

What Jev is: the output is not text, but a valid decision

A regular LLM receives context and continues the token sequence. Even when we ask for JSON, its job is still fundamentally generative: the model writes a serialized object, a validator checks its shape, and if something goes wrong, the familiar retries begin.

Jev uses a different contract:

state + questions → answers + probabilities

state contains text or structured application state. In questions, the developer specifies one or more typed questions. Answers come back under the same keys. There are three public primitives:

• Noul answers a yes/no question with a probability from 0 to 1;
• Choice selects one of a predefined set of options and returns a distribution over the entire list;
• Score distributes probability across a scale of 2–10 levels and calculates the expected value.

Take a support request: “I was charged twice, fix this urgently.” In a single request, you can ask whether it is urgent (Noul), which department should handle the ticket (Choice), and how annoyed the customer is (Score). All questions see the same state, but not each other’s answers. If the second question needs to depend on the first, you have to implement that dependency in code.

The independence of questions enables speculative fan-out. The application sends questions for several possible branches in advance, gets the answers at the same time, and then the code picks the branch it needs. Some answers may never be used, but there is no need to wait for another API call.

This is the basis for the launch’s favorite phrase: “zero hallucinations.” In a narrow sense, it is true. If the only allowed values are billing, technical, and sales, the API will not return legal, a long explanation, or a poem about refunds. But Jev can still confidently choose sales. Type safety guarantees the shape and the set of allowed answers, not factual correctness.

confidence has the same trap. It is a property of the shape of the distribution, not the probability that the decision is correct. A value of 0.9 does not mean “it will be wrong one time out of ten.” TypeSafe explicitly recommends calibrating thresholds on your own labeled data and taking the cost of errors into account. The same threshold clearly will not work for comment moderation, blocking a payment, and deleting a production database.

So far, System One and its RLCD training method, Reinforcement Learning for Calibrated Decisions, are known only from TypeSafe’s descriptions. The company has not published the weights, architecture, data, loss function, or reward scheme. Archer Hume’s experiments are consistent with question isolation and show that the full list of options affects the result. But they do not establish the existence of a causal decoder, KV cache, separate output heads, let alone a sparse MoE model.

For now, the only thing we can verify about Jev is what happens at the boundary between the model and the application. A similar interface can be built on top of an LLM with structured output, constrained decoding, or local logit scoring; TypeSafe itself has even open-sourced a System One adapter for regular LLMs. So the interface should be judged by model quality, calibration, latency, and how the full system behaves in production.

Josh Kuechly compared Jev with the open-weight GLiNER 2.5 classifier on Banking77. Without fine-tuning, GLiNER trailed Jev by about 9 percentage points, although it ran 10 times faster. After 51 minutes of training on roughly 10,000 examples, it gained 18 points, beat Jev by about 9 points, and ran 8 times faster locally. The author did not publish the code or logs, so for now this is a single experiment rather than an independent benchmark. But the trade-off is clear: Jev buys zero-shot flexibility, while a narrow classifier buys speed and accuracy on a stable task.

Jev does not replace these options. It adds another one: a general-purpose cloud decision layer between regular code and an LLM.

How to try Jev without waiting for TypeSafe to open access

You can try Jev at askjev.ai or easyjev.app.

As of my September 18 check, direct access from TypeSafe was still in early access. Once admitted, a user creates a key, buys credits, and calls POST /v1/systemone. Without waiting for direct access, Jev could also be called through Vercel AI Gateway, where the model is called typesafe-ai/jev and billed through Vercel credits. OpenRouter uses the earlier /api/alpha/decisions endpoint, while Cloudflare Workers AI calls typesafe/jev through its own ai/run. These are four different routes with their own keys, billing, and limitations, not interchangeable proxies.

As of September 18, the jev-latest and jev-preview aliases pointed to jev-1.13.0. The model documentation listed a price of $0.042 per million input tokens; output tokens were not charged. Early-access limits were 64k tokens per request, 32k for the combined length of state and the longest question, 1,200 requests per minute, and 250,000 input tokens per second. TypeSafe warned that these limits could change.

The minimal request from the official quick start looks like this:

curl -X POST [https://api.typesafe.ai/v1/systemone](https://api.typesafe.ai/v1/systemone) \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
{
  "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": {
    "urgency": {
      "type": "noul",
      "instructions": "Does this message express urgency?"
    }
  }
}
EOF

The request shows the contract: the state is sent in full, the question is typed, and there is no free-form field for a text response. The Python and JavaScript SDKs hide HTTP calls and retries, but do not change the operating model.

The price looks almost indecently low until you remember that an agent resends a large context on every step, and you pay for all those tokens. Output tokens are free because there are very few of them, not because the entire chain costs nothing.

TypeSafe states that it does not train Jev on user requests and responses, but it does not publish a specific retention period for a standard account with direct access. ZDR is offered to enterprise customers. Vercel does not retain the request and response after the call completes, but it does store operational metadata, while routing-attempt details may persist for 30 days. “We don’t use it for training” and “we store nothing” are still different promises.

For direct accounts, TypeSafe’s Master Customer Agreement restricts reverse engineering and the publication of benchmarks or information about the service’s performance. This may apply to more than just your own measurements.

How the Jev browser agent works

The browser agent does not start with the model. The jev-ultrafast repository is useful because the hype video can be unfolded back into code. We’ll look at the MVP version 0.1.0 at a pinned commit: Jev chooses the next action, while the browser mechanics are implemented by the agent code.

One loop looks like this:

snapshot.js
  → visible text and indexed action space
  → batch of Choice questions
  → Jev selects an operation and target
  → Mercury 2.5 writes a value only for TYPE_TEXT
  → browser.py validates and executes the action

snapshot.js collects visible text and interactive elements of supported types. Regular Python code turns them into a list of allowed operations: CLICK, TYPE_TEXT, SELECT, scrolling, waiting, DONE, and BLOCKED. Jev does not invent a CSS selector, coordinates, JavaScript, or a shell command. It sees a prebuilt list and chooses an index.

In model.py, the operation question and target questions are assembled into one batch. Here is a real excerpt from the choose() function:

questions = {
    "operation": {"type": "choice", "criteria": operations, "instructions": {"goal": goal, "rules": NEXT_ACTION}}
}

The next loop adds targets from observed elements to questions. Jev evaluates operation, click_target, type_text_target, and other branches in parallel. If CLICK wins, the answer for type_text_target is ignored.

Free-form text is still needed when the agent fills in a field. The strings Zurich and London in the demo were generated by Mercury 2.5, not Jev. After the choice is made, the executor validates the page, DOM node, properties, geometry, and element overlap again. The model proposes an action; the code decides whether it can actually be performed.

This is a strong architectural boundary, but it also shows where the complexity went. The action space is truncated to the first 250 entries, and visible text to 6,000 characters. The first version does not support, or only partially supports, frames, <canvas>, file uploads, new tabs, nested scrolling, shadow DOM, and custom elements. If the button you need does not make it into the snapshot, Jev cannot choose it even with perfect accuracy.

The issues already include an empty initial action space, invisible clickable elements, and a report of an 81.62-second run: two Page.captureScreenshot timeouts and manual resumes increased total time, while the author cited background rendering throttling as a likely cause. These isolated reports are not enough to estimate failure rates. They do identify three things worth testing: completeness of the action space, visibility of interactive elements, and stability of the browser environment.

Freshness and geometry checks filter out actions based on stale page state, but they do not protect against prompt injection. The project has no general confirmation policy for dangerous operations and no allowlist of domains. A narrow set of allowed actions reduces the range of possible mistakes, but does not make a chosen action safe on its own.

What actually fit into seven seconds

The published Flights trace took 7,073 ms. In that time, the agent made 17 Jev requests, 11 browser actions, and two Mercury calls. It found Google Flights results for Zurich → London on the specified date. It did not book a ticket.

Jev took 3,720 ms, or 52.59% of the total measured time. The two text calls added 927 ms. Calls to both models took 4,647 ms, or 65.70% of the total time. The rest went to page snapshots, execution, and the browser environment.

Those 7,073 ms cover only the agent loop. The timer starts after the initial observation, just before the first model call, and stops when DONE is accepted. Browser setup, initial navigation, and the final verifier are not included in the seven seconds. And DONE is selected by the same policy model. Success is established by a separate check of the route, date, and visible results outside the timer.

In an arbitrary task, that verifier does not exist until the developer writes one. An agent that declares its own work finished is like a student grading their own exam. Sometimes everything really is correct, but that does not make the check independent.

The cost of the model calls here can be calculated quite precisely. 90,558 Jev input tokens at the current price cost $0.003803436. Mercury added $0.00006272. Total: $0.003866156, excluding browser infrastructure. About 98.38% of model spending went to Jev: resending the state turned out to cost more than two short text generations.

The authors compared the old and new execution environments across three alternating pairs of the same task. The median fell from 9.450 to 7.092 seconds, roughly 25%, while the number of CDP calls dropped from 1,092 to 101. All six runs passed the verifier, but the sign test gives p = 0.25. This is an execution-environment speedup on one task, not a comparative test of Jev versus an LLM, a local classifier, or Playwright.

A third-party Retriever test adds a useful counterexample. In two scenarios, the Jev configuration was 31% and 43% faster, but 38% and 51% more expensive. Of 50 calls, 39 were Score: pre-filtering ate up the savings from cheap decisions. Each configuration was run only once, and no raw traces were published, so the percentages cannot be generalized. In these two scenarios, a fast model did not make the system cheap.

15 Jev projects: from flights to StarCraft

The final fifteen are the projects that best show Jev’s range. This is not a ranking: released code sits alongside one-off demos and author claims. A repository confirms that a project exists, but says nothing yet about its accuracy or reliability in production.

Choosing the next action

1. jev-ultrafast demonstrates a dynamic action space: Jev selects the operation and target, the browser wrapper executes the action, and Mercury writes text into fields. We covered the architecture and the boundaries of the seven-second run above.
2. mobile-jev brings the same principle to Android. Jev receives the available UI elements and chooses the next tap; in the demo, the agent ordered an Uber in nine actions over roughly 21 seconds. The code is open, but there are no other scenarios yet for evaluating reliability.
3. Justin Schroeder claimed he rebuilt Tesla Full Self-Driving on Jev in under an hour. The subsequently published JevPilot turned out to be a playable simulator built with Three.js: the model chooses trajectory and speed, while geometry, route finding, and emergency braking remain in regular code.
4. One completed mission is not enough for systematic evaluation. But the original StarCraft is a good fit for Jev’s contract: the game has a finite set of commands, the model controls the keyboard and mouse, and the probabilities of selected actions are recorded. Astra completed the mission on its first try. It is, of course, still a long way from Androide and his silver medal at WCG 2005.

Checking an agent before it acts

5. pi-warden sits between an agent and its tools. Before a command is executed, Jev evaluates irreversibility, consistency with the plan, external consequences, repeated loops, and suspiciously early done. The author ran the check on 17,000 of his own tool calls, but did not publish the original sessions or the complete results.
6. A permissions plugin for OpenCode checks the agent’s intent before allowing it to access a domain. The author says Jev caught every demonstrated attempt to bypass the restriction. There is no public attack set, so for now this is a successful demo of a defensive gateway, not a proven security boundary.
7. The Discord bot scores messages for spam, phishing, and social engineering. The code turns Jev probabilities into four response levels, from allowing the message through to hard escalation. The authors provided no accuracy metrics. But the division of responsibilities is visible in the code: the model assigns a score, while the program defines the consequences.

Helping other models

8. fast-jev-compaction ranks old tool calls from Claude Code and preserves verbatim the ones it considers useful. In the demo, context size fell from one million to 86,000 tokens in about a second. The repository confirms the selection mechanism, but does not prove that nothing important was lost among the discarded 914,000 tokens.
9. jev-router selects a model for Claude Code and Codex requests: simple tasks can go to a cheap model, difficult ones to a stronger model. Savings appear only if routing is accurate enough. Otherwise, a cheap first decision turns into an expensive correction.

Processing large data streams

10. pg-jev adds a function to PostgreSQL for natural-language conditions. The result is a kind of fuzzy WHERE: rows can be filtered by meaning without precomputed embeddings. The cost, accuracy, and speed of a full scan over a large table have not yet been measured.
11. unclutter turns Jev into a semantic filter for web pages. The user writes a rule in plain language, the extension classifies page elements and remembers removal patterns. This means the model does not have to be called every time the site is opened, although no one has independently tested the quality of the rules themselves.
12. Another extension listens to YouTube audio and skips sponsored segments inside videos. The author estimated the cost at roughly $0.005 per video. The post does not reveal how accurately it detects the beginning and end of ads, or how much regular speech it skips along with them. But you’re better off installing SponsorBlock.
13. In an experiment with 1,018 AI articles, Jev sorted the material into 24 topics. The author reported $0.08 for the entire set and a median of 256 ms per article. However, Jev was given pre-generated summaries from DeepSeek, so those figures describe only the second stage of the pipeline.

Testing extreme ideas

14. jev-trader chooses buy, sell, or wait for the MON-USDC pair on every 300-millisecond Monad block. Demo. The code includes a real-order mode, but by default the bot runs in mock/dry-run. The author has not shown a public transaction or performance history. So, ready to ape in?
15. killmyidea asks roughly ten questions about a startup in parallel and combines the answers into a numerical score. The model does not need to generate free-form text at all: Jev assigns scores, and the interface turns them into an analysis. This digital Wolf of Wall Street is only as useful as its criteria.

Two tests where speed was not enough

On 1,565 German and English business emails, Gemini was more accurate than Jev at classification across ten categories. The author still considered Jev for production because of its other advantages, but there was no universal quality win.

In an open test on 2,000 phishing emails, Jev lost to Claude Haiku 4.5 on accuracy. The code is published, but the result has not yet been independently reproduced. Two different datasets do not add up to an overall ranking, but they are a useful reality check after the videos with cars, games, and trading bots.

Should you use Jev right now?

Jev is worth testing if your LLM already selects a label, route, or action from a finite list and you want to reduce latency and cost. If you do not already have that kind of problem, the Jev hype will not create one for you.

It makes sense to try if

1. Your LLM returns a category, score, or yes/no, and you throw away the generated explanation anyway.
2. Several sequential decisions are slowing the system down and can be combined through speculative fan-out.
3. You already have a list of allowed actions, result verification, and a fallback path. Jev only chooses; the code still executes.

The best first candidates have already appeared above: routing models and tools, defensive checks before an external action, bulk classification, and ranking. In all three cases, the correct answer can be enumerated in advance, and an error can be detected before it becomes expensive.

It is probably not worth it yet if

• the output needs to be new text, code, or a plan;
• regular code or Playwright already solves the task reliably;
• you have a stable narrow domain and enough labeled data for a local classifier;
• the state cannot be sent to a proprietary cloud service;
• there is no cheap way to verify an error;
• the decision immediately triggers an irreversible action.

The Jev 1.13 limitations page adds arithmetic, dates, indirect questions, large amounts of irrelevant context, contradictory criteria, and adversarial content to that list. TypeSafe recommends leaving these parts to regular code.

What a pilot should prove

Run Jev and your current solution on the same labeled sample. Compare accuracy, latency, and the full cost of the pipeline, then choose a confidence threshold and a fallback route. If there is nothing to compare it against, you will end up with another pretty demo, not a reason to change the system.

If the idea of typed choice itself fits your use case but a proprietary cloud does not, jevlike and openjev let you test a similar interface with local models. They do not reproduce the proprietary Jev model, its quality, or RLCD. One of the claimed Qwen-RLCD artifacts does not even have its own uploaded weights.

The first wave found many places for Jev, but it has not yet shown that a single model is equally good at all of them. For a technology that is three days old, that is a perfectly normal outcome.

Jev proposes a contract where the application describes the world of allowed answers in advance, the model distributes probability among them, and the code retains control over execution and verification. That constraint becomes an advantage only when the developer has described that world correctly.

If the button you need is not among the 250 elements, the right class is not in Choice, and nobody is there to verify a dangerous action, Jev will still return a perfectly valid answer. Just not the one you need.

Stay curious.

I write about artificial intelligence, language models, and developer tools. I test models and services on real-world tasks and share what I learn in my Telegram channel.

Frequently asked questions about Jev