Jev for Vibe Coders: When a Decision Model Beats an LLM in Your App

Somewhere in your app there is a function that sends a short piece of text to a language model, waits a second or two, and uses the answer to decide one thing. Is this submission spam. Which team gets this ticket. Is this lead worth a notification. The model writes a sentence, your code pulls a word out of it, and the sentence is thrown away.

That call is the most expensive way to answer a yes or no question, and until a week ago it was the only way that did not involve training something. Jev, released by TypeSafe AI on 15 September 2026, is built for exactly that call and nothing else. You send it a piece of state and the questions you want answered, and it returns typed answers with a probability on each. It cannot write a reply, a summary or a line of code. That is the trade.

For an app built with Lovable, Bolt, Replit or a coding agent, that changes the maths on a specific call: what it costs, how to reach it from where your code already runs, what other people got out of it in the first week, and the four cases where you should leave the LLM exactly where it is.

What it actually returns

Three question types, and you can ask many of them in one request.

• Choice picks one option from a list you define, up to 255 of them. You get the key it chose and a confidence number.
• Score rates the state against levels you define, so "how urgent is this" comes back as a level rather than a sentence about urgency.
• Noul answers a yes or no statement as a probability between 0 and 1. "The user is asking for a refund" comes back as 0.93, not as "Yes, the user appears to be requesting a refund."

Every answer carries its own probability, and that is the part that makes it usable without a human reading everything. You act above a threshold you set, and send what falls below it to a person. TypeSafe's own models page puts the current version at jev-1.13.0, with 64k tokens per request (32k of that for the state), text only, and rate limits of 250,000 tokens per second and 1,200 requests per minute that the docs say can change without notice.

Price is the headline: $0.042 per million input tokens, with output free, because there is almost no output to meter.

The number that matters is not the price

It is how you shape the call. TypeSafe's own parallel questions cookbook runs the same 13 questions over a 54,000 character document two ways. Thirteen separate calls cost $0.006090 and took 2.71 seconds. One call carrying all thirteen questions cost $0.000497 and took 0.27 seconds. Same answers, 12.2 times cheaper and 10 times faster.

The reason is that you are charged for the state, and the questions barely add to it. So the mistake to avoid is one call per question. Ask everything you might need in a single request, including the questions you will probably throw away, and route on the answers in your own code afterwards.

What other people got out of it

We have not run the API ourselves, so every number here belongs to the person who published it, with their name on it.

MotherDuck shipped a prompt_jev() SQL function and posted that classifying 100,000 rows took 40 seconds and cost $0.50, against 32 minutes and $37 for the comparable language model run. That is the clearest published before-and-after so far, and it is the shape most apps will recognise: a column of text, one question per row.

Andy Wang put 34 months of bookkeeping through it over a weekend, work he says was previously billed at over $20,000, and reports a better result in 20 seconds for $0.32. AgentOS added Jev as a routing strategy in its Pilot Router at around 0.9 seconds a decision, and says it beat both a local MiniLM classifier and an LLM judge on a 121-turn multilingual test set.

HackerNoon's list of 101 projects built on it in the first week sorts almost all of them into four buckets: routing something to the right place, gating an action before it runs, scoring items in a list, and classifying rows in a database. If your idea is not one of those four shapes, it is worth asking whether you want a decision model at all.

Calling it from where your code already runs

It is an HTTP endpoint with a JSON body, which means you do not need a framework, an SDK or a new deploy target. You need somewhere server-side to put an API key.

const res = await fetch("https://api.typesafe.ai/v1/systemone", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.TYPESAFE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "jev-1.13.0",
    state: submission.message,
    questions: {
      topic: {
        type: "choice",
        instructions: "What is this message about?",
        criteria: {
          bug: "Something in the product is broken",
          billing: "Charges, invoices, refunds",
          sales: "Wants to buy, or asking about price",
          spam: "Automated, irrelevant or promotional",
        },
      },
      needs_human: {
        type: "noul",
        instructions: "This message needs a person to reply today.",
      },
    },
  }),
});

const { answers } = await res.json();

if (answers.topic.confidence < 0.6) return route("inbox");
if (answers.needs_human.noul > 0.8) return notify(answers.topic.choice);
return route(answers.topic.choice);

Two questions, one call, and the routing decision lives in your code where you can read it. Where that snippet goes depends on what you built with:

• Lovable: a Supabase edge function. Lovable apps already keep their server-side logic and secrets there, so the key never reaches the browser, and the front end calls the function.
• Bolt or Replit: a server route in the app you already have, with the key in the environment variables panel rather than in the code the model generated.
• Anything on Vercel: the AI Gateway carries it as typesafe-ai/jev, which means no second account and no separate key. Vercel's developer account posted a free window on the gateway; several trackers put the end of it at 25 September 2026, so check the gateway page before you plan around it.
• Cursor or Claude Code: the community has published skills and routers that call it from inside the agent, including jev-skill and jev-router. The curated index is awesome-jev.

One warning that applies everywhere: your state field is untrusted text if it came from a user. TypeSafe's own documentation says the model does not treat the state as hostile by default, which puts this in the same bucket as every other guardrail decision you make about user input.

Where it is confidently wrong

This is the part the launch coverage skipped, and it is the reason to read TypeSafe's own jaggedness page before you design anything. It lists twelve known weaknesses in the current version. The ones that will bite a normal app:

• Arithmetic and counting. It is not a calculator and does not count reliably. Do both in code.
• Dates. It reads them as text, not as ordered quantities, so "is this within the window" is unreliable. Extract the parts, compare them in code.
• Large state. Accuracy falls as you send more text that is irrelevant to the question. Filter first, send only the fields the question needs.
• Language. English is strongest. The docs say other languages, CJK scripts included, are supported but less reliable.

Then the findings from people testing it in public. Bourne Shao found that a two-number comparison works, but checks across multi-line invoice totals come back clean, typed, confident and wrong, with no refusal and no error. AGTP Insights summarised community tests showing the same prompt can return different answers, and probabilities shift when you reorder the options. Anuj Magazine notes that independent testing put the median cost gain nearer 30 times rather than the 444 times in TypeSafe's launch figure, which was measured on its own workflow evaluations against frontier models.

So treat "it cannot hallucinate" precisely. It means the answer is always one of the options you defined, which removes schema and parse failures from that step. It does not mean the answer is right. The confidence gate is not decoration; it is the thing standing between a cheap decision and a wrong action.

When to keep the LLM

Four cases, and they cover most of what an app does.

1. Anything that writes. Replies, summaries, product copy, code. Jev produces no text at all.
2. Anything that needs exact numbers. Totals, counts, date maths. That belongs in code, not in either model.
3. Open-ended reasoning. Multi-step planning, working out what the user even wants, recovering when a task goes sideways.
4. One decision, once. If a feature makes ten decisions a day, the model call you already have is fine. The case for a second vendor, a second key and a second failure mode starts at volume and latency, not at elegance.

The architecture that makes sense is both: the decision model picks, the language model writes. Sort the ticket with Jev, draft the reply with an LLM.

Trying it without committing to it

An afternoon is enough to find out whether it helps your app.

1. Pick the one decision your app makes most often. Frequency is the whole case.
2. Write it as questions with a fixed set of answers. If you cannot list the answers in advance, this is not the tool.
3. Run it in shadow mode: call Jev alongside your current logic on real traffic, log both, change nothing that users see.
4. Compare on 50 items you have labelled yourself, and look at the disagreements rather than the accuracy number.
5. Set the confidence floor from those disagreements, then let it route above the floor and send the rest to a person.

That fifth step is the one worth keeping whatever you decide about the model. If you already run evals on the model calls in your app, this is the same job with a smaller unit of measurement, and it is a great deal easier to measure a choice than a paragraph.

One caveat on timing: TypeSafe opened access to everyone on 20 September and then paused new signups two days later because of demand, so the gateways may be the faster route in this week. There are also no public weights, so this is a hosted dependency, not something you can bring in house. If that matters for your app, the shape of the work still transfers: the same edge function with the same questions can call a small language model or an open classifier instead, for more money and more latency.

FAQ

What is Jev in one sentence? A hosted model that takes text plus the questions you want answered about it, and returns typed answers with a probability on each, instead of writing a reply.

How much does Jev cost? Read on TypeSafe's models page on 22 September 2026: $0.042 per million input tokens, output free.

Can I use it in a Lovable or Bolt app? Yes, from anywhere your app runs server-side code. A Supabase edge function is the natural home for a Lovable app, a server route for Bolt or Replit.

Does it replace the LLM in my app? No. It writes nothing. It replaces the model call you were making to decide one thing.

Can it be wrong? Yes. The answer is always one of your options, so it cannot be malformed, but it can be the wrong option, and the published failure cases are arithmetic, counting and dates.

The short version

If your app keeps asking an expensive model a cheap question, this is the cheaper way to ask it, and the published numbers from MotherDuck and others are big enough to be worth an afternoon of your time. Keep the questions bounded, keep the arithmetic in code, keep a confidence floor, and keep the LLM for everything that has to be written.

Browse the Jev card for pricing and links, or the rest of the AI API tools if you are still deciding what belongs in your stack.