Report
Should you use Jev? I made Jev answer that question
Jev is a model from TypeSafe AI that never writes text. You send it some state and a list of typed questions. It returns a choice, a score or a probability for each question. TypeSafe's launch post gives a latency of 70 to 500 ms and a price of 0.042 USD per million input tokens.
jev-fit is a small tool that I built. It uses TypeSafe's Jev model through its public API. It is an independent project and is not affiliated with TypeSafe AI.
The question every team has
The launch thread for Jev argued about one thing. Is this a classifier with a good API, or a new layer between code and LLMs? The useful question is smaller, and every team asks it in the same words: which of my workflows fit this?
The mental models from the explainers are good. Jev is a smart if statement. It is a switch over an enum where the input is free text. The result is always a valid case, and it can still be the wrong case. Jev is the referee who decides a thousand times per match, and the LLM is the VAR that you call for the unclear ones.
None of this tells you if your ticket router, your log triage job or your invoice checker is a Jev task. I wanted an answer for one specific idea.
What I built
jev-fit is one page with one text area. You paste a software idea. The server sends the idea and a fixed set of typed questions to Jev in one call.
The page shows a verdict with three options: plain code, Jev, or a reasoning LLM. When Jev fits but some cases will be unclear, the verdict reads "Jev, with a review band". That means Jev decides the clear cases, and a person or a slower model takes the rest. The page also shows the probability of each option and a success potential score from 1 to 5.
No LLM writes anything on the page. Every sentence is a template that the code fills from Jev's answers. Each result has a permalink with a card image, a Copy link action and a Post on X action. There is a public API. POST /api/fit takes {"idea": "..."} and returns the same verdict as JSON.
The tool is closed source. The set of questions is the product, so I keep it private. The tool and its API are free to use. I describe the method, without the questions, in a separate post: How to write questions for Jev.
How it works inside
The design has three parts. The first part is the rubric. It is a set of small questions, and each one asks about one property of the idea. Is the output one option from a fixed list? Does each item need one judgment? Does the task need text as output? Does it need counting? One question gives the verdict. The others are signals.
The second part is code. A gate rejects text that is not a software task, such as a shopping list. Veto rules remove a verdict that the signals contradict.
The third part is a state for low confidence. When the confidence is under 50%, the page says "Not sure" and gives a hint: "Add detail: what goes in, what comes out, how many per day."
I tuned the rubric against test ideas that I wrote and judged myself, from nonsense to obvious cases. That work is internal. TypeSafe's terms do not let customers publish benchmark or performance results, so this page has no numbers from it. What I can share is what the work taught me about the design.
The design bug that taught me the most
Jev takes no image input. One of my trap ideas was a screenshot task: look at a screen and decide if the layout is broken. My first rubric answered "Jev".
The cause was my design. The rubric had a separate question about images, and the answer to it was correct. But the verdict question did not know that. Questions in one call run in parallel, and no question can see another question's answer. TypeSafe's docs say this plainly: "One primitive's result does not become hidden context that changes another primitive's result". I had read that sentence, and I still built a rubric that depended on the opposite.
I did not fix it with better wording. I added a rule in code. When the idea needs images, audio or video, the code removes Jev from the verdict, whatever the verdict question says, and the page says why. The model supplies the signals, and the code owns the policy.
What fits a decision model
The ideas that fit have the same shape. The input is text or structured data. The output is one option from a fixed list, a level on a scale, or a yes or no. Each item needs one judgment. The volume is high enough that cost and speed matter. Examples are ticket routing, review classification, tone detection, policy checks on listings, and relevance filtering before an LLM reads anything.
What does not fit
A decision model is the wrong tool when a rule can decide. Email format checks, discounts, sorting and rate limits belong in plain code. A free, deterministic if beats a model call that can be wrong.
It is also the wrong tool when the output is text, such as summaries, replies or plans. Jev does not generate text at all.
TypeSafe documents the other weak points on its own jaggedness page: counting, numeric formats and date comparison, among others. Keep that work in code.
The grey zone
Some ideas sit between the options. A moderation queue is a Jev task until a post is ambiguous. Pull request review is a Jev task until somebody wants the reason written in a comment. Data extraction from emails is part code, part Jev and part LLM, and the right split depends on details that a two-line idea does not contain.
The tool handles these in two ways. "Jev, with a review band" covers the first kind. The "Not sure" state covers the second kind. I count that state as a correct answer.
What this means if you evaluate Jev
Write your workflow as one sentence per decision. If you cannot, it is not one Jev task. It may be several.
Check the output. A fixed list, a scale or a yes or no can fit. Text does not.
Keep counting, dates, sums and hard vetoes in code, and let Jev answer only the judgment part.
Plan the review band before you ship. Decide who handles the low-confidence cases, and measure how many there are on your own data.
Test with your own labelled examples, under your own account. My test ideas tell you about my rubric. They tell you nothing about your tickets.
Try it
Paste one idea at jev-fit.com. Use two or three sentences, and include the input, the output and the volume. If the verdict looks wrong, send me the permalink.
curl -s https://jev-fit.com/api/fit \
-H 'content-type: application/json' \
-d '{"idea":"Route each support email to billing, technical or sales. About 3,000 a day."}'The tool stores the idea text and the answers. It stores no IP address and no account. The text goes to TypeSafe's API, because that is where Jev runs. You can delete any result from its own page, and the details are on /privacy. Do not paste secrets.