What is Jev and How to Use it? transcript

So, Jev just launched, and its launch post on X already has over 30 million views. If you have seen people talking about it, you might be wondering whether it's something you should be using, too. So, in this video, let's answer a few questions. What exactly is Jev? Why would you use it? How is it different from models like GPT, Claude, Grok, Gemini, and others? How much does it cost? How does it work? How to get started?

And finally, when should you use Jev, and when should you avoid it? So, what is Jev? Jev is an AI model from a company called Type Safe that you can use to make decisions. The simplest way to think about it is as a smart if statement. Let me give you an example. Let's say you run an online store, and you want to offer free delivery when someone buys three or more items. That is straightforward to write in code. You check the number of items, and if it's three or more, you offer free delivery.

But now, let's say you want to flag messages from customers who sound frustrated. How would you write that condition? You could look for certain words, but a customer might just say, "I've contacted you three times, and I'm still waiting." They haven't used the word frustrated, but you can see what they mean. This is where Jev comes into the picture. You give it the message, and ask whether the customer sounds frustrated.

Jev looks at what the customer is saying, and makes a judgment in a fraction of a second. Now that you have an idea of what Jev is, let's look at how Type Safe describes it. They call it a system one model built to make fast, structured decisions that software can use directly. Let's break this down into three parts, starting with system one. The term system one comes from Daniel Kahneman's book, Thinking, Fast and Slow.

The book describes two ways of thinking, fast intuitive judgments, and slower, deliberate reasoning. TypeSafe borrows the first idea for models designed to make quick judgments inside software, like judging whether a customer sounds frustrated. That is why it calls Jev a system one model, and the name Jev comes from William Stanley Jevons. He noticed something interesting about steam engines. As they become more efficient, you would expect people to use less coal.

But, making them cheaper to run encouraged people to use them more. So, coal use actually went up. That is the idea behind Jevons paradox. Efficiency can increase total consumption. And TypeSafe expects something similar with AI. If AI decisions become much cheaper, we can use them in more places, including applications where the cost previously didn't make sense. So, that's where the name comes from. Now, let's look at the next part.

Fast, structured decisions. Fast means you don't have to wait long for the judgment. TypeSafe reports end-to-end response times of 70 to 500 milliseconds. And structured means Jev gives you its answers as data instead of sentences and paragraphs, like you would get in a chat. And then we have software can use directly. Now, this is important because Jev is designed to be used inside an application. Think back to our customer message.

You could have Jev check whether the customer sounds frustrated, and your application use the result to flag that message for your support team. Jev makes the judgment. Your application handles what happens next. Now, you might be thinking, "Can't I already do something like this using OpenAI or Claude models?" Why would I use Jev? Yes, you can already use OpenAI or Claude models to check whether a customer sounds frustrated.

You can also ask for structured output. So, returning data in a particular format isn't something only Jeff can do. The difference is what Jeff is designed for. Models like GPT and Claude can make judgments, but they can also write a reply to the customer, explain a concept, or generate code. Jeff, however, focuses on just the judgment. It doesn't generate a reply or explain its answer. And because it doesn't have to generate a reply one token at a time, Jeff can produce the answer probabilities in parallel.

That's one reason it can be much faster and cheaper than other models for these decision tasks. For example, what took GPT 5.6 tera about 8.6 seconds, took Jeff only 114 milliseconds. That is how much faster Jeff can be for a task like this. And look at the cost for the same example. The GPT request cost about 1.4 cents, while Jeff cost less than 100th of a cent. Jeff was roughly 170th of the cost. So, if Jeff is that much cheaper in this example, how much does it actually cost to use?

The current price is 4.2 cents per million input tokens. That is $42 per billion input tokens. And the output tokens are completely free, so you're only paying for what you send in. Let me put that into perspective. Say you receive 10,000 customer messages a day, and you want to check whether each customer sounds frustrated, just like in our example. If each message and its question together come to around 500 input tokens, you can check 47,000 messages for just $1.

The length of the messages and the questions we ask can of course vary, but this gives you an idea of what this pricing means in practice. You could check every incoming message for frustration without spending much on those decisions. Now that we've seen what Jef does and why you might use it, let's look at how Jef works. To understand how you work with Jef, let's look at its input and output. What information do you send it and what does it send back?

Let's start with the input. When you make a request to Jef, you give it the information you want it to look at and the questions you want it to answer. TypeSafe calls this information the state and the state can either be plain text, a JSON object, or an array. Going back to our customer message, "I've contacted you three times and I'm still waiting." This message is the state we are giving Jef. Next, we tell Jef what we want to know about that message.

For example, does the customer sound frustrated? You can specify one or more of these questions. But there is a bit more to understanding questions because for each question, you choose a question type based on the kind of answer you need. And there are three question types you can choose from. Null, choice, and score. Let's understand the three types. The first one is null. You can use this for a yes or no question.

For our message, we could ask, "Does this customer sound frustrated?" But instead of simply returning true or false, Jef returns the probability that the answer is yes as a number between zero and one. Let's say it returns 0.95. That means Jef estimates a 95% probability that the answer is yes. A value closer to zero would mean it thinks the answer is no. And a value around 0.5 means it isn't clearly leaning either way.

So, a low number doesn't mean it's unsure. It means it's quite sure the answer is no. Now, the second question type is choice. You use this when you want Jeff to pick from a set of options you provide. Let's say you want to know why the customer is contacting you. You could give Jeff four options: asking for an update, requesting a refund, requesting a replacement, or something else. Jeff picks one of these options and returns the probabilities for all the options as well.

The important part is that you define the options and Jeff has to choose from the list. That is also why we've included something else, so there is an option for messages that don't fit the other three. The third question type is score. You use this when you want to judge where something falls on a scale. We already asked whether the customer sounds frustrated. But, what if we want to know how frustrated they sound? We can give Jeff a scale with three levels.

The customer makes a request without expressing frustration, the customer expresses dissatisfaction, or the customer expresses strong anger. Notice that we are describing what each level means. That gives Jeff something more specific to work with than just rate this from 1 to 10. The levels you provide start at zero and the score is a weighted average based on the probabilities for those levels. So, the result can fall between them.

If Jeff gives equal probability to levels 1 and 2, for example, the score would then be 1.5. And you don't need to send a separate request for each of these questions. Since they all are looking at the same message, you can put them in one request and Jeff evaluates them independently in parallel. Independently means one question doesn't get to read another question's answer. Each question needs to make sense using the state you've provided.

So, that is what goes into the request. The state and the questions including the type and any options or scale you've defined for each one. Now, let's look at the response. You get back an answer for each question matched to the name you gave that question in the request. For our null question, the answer contains the probability of yes. For choice, it contains the selected option and the probabilities for all the options.

And for score, it contains the score, the probabilities for the levels, and a legend that maps those levels back to their description. Now, getting an answer doesn't mean the answer is necessarily correct. Jeff can still misinterpret the message. Choice and score also return a confidence value based on how the probabilities are distributed. You can use that to help decide whether your application should act on the answer or leave it for someone to review.

Confidence is not a guarantee of accuracy and you will need to try your own examples to decide what confidence level is enough. Null, for example, doesn't return a separate confidence value. You look at how strongly its probability favors yes or no. Now, along with the answers to your questions, the response also tells you which model version handled the request and how many tokens it used. So, you send the state and your questions, get the answers back, and decide how your application should use them.

If this makes sense, let's see Jeff in action. To get started, head over to the Type Safe website. Jeff is currently in early access, so you will need to join in waitlist if you don't have access yet. And you can also use Vercel's AI Gateway and Jev is free to use till the 23rd of September. Once you have access, you can sign in to the Type Safe Console. From here, you can try Jev in the playground or get an API key to use it in your own code.

Let's try one request here in the playground before we write any code. In the top section, we specify the state and in the bottom section, the questions we want Jev to judge. I will specify the state as JSON with a property message and the value, "I've contacted you three times and I'm still waiting." This is our customer message. You can also use plain text for the state, but we will use a message field just like we will in our code in a minute.

Now, for the question, I will choose null and enter the question, "Does the customer message express frustration?" Let's run it and see what comes back. 92% true. The more closer it is to one or 100% in this case, the more strongly Jev thinks the customer sounds frustrated. And you can see the response time, milliseconds. So, this is one way to try Jev without setting up a project. You can also add more questions and see the answers together.

But for this video, I also want to show you how to make these requests from code. Type Safe provides a Python SDK and a JavaScript SDK with TypeScript support. We will use TypeScript. I've already set up a small TypeScript project for this demo and I will leave a link to the GitHub repo in the description. Let me quickly walk through what's in it, then we will make the same request we just tried in the playground. So, first in package.json, you can see the TypeScript SDK is installed at typesafe.ai/sdk.

We also have TypeScript, the Node.js types, and TSX, which lets us run our TypeScript files directly. The project uses ES modules, so we can use import statements and await our requests at the top level. There's also an .env file for the API key, which you can create in the console. This is the variable where you put your own key. You can see the key in the example .env file, but make sure to update your key in the .env file.

All right. Now, there are two demo files, and we'll start with demo.ts, which asks one null question. Then, we'll open all questions.ts to see null, choice, and score in the same request. In demo.ts, at the top, we are importing Typesafe client and the null helper. We check that an API key is available, and then create a new Typesafe client. Next, we define the state containing the customer message. We have a property called message and the string "I've contacted you three times and I'm still waiting" as the value.

To send it to Jev, we call client.system1 and pass in the state and our question. I've called this question "is frustrated". That's the name we will use to find its answer in the response. The text inside null is the actual question Jev will evaluate, and we are pointing it to the message field in our state. We log the response to the console. I've added a demo command in package.json, which uses TSX to load our environment file and run demo.ts.

Let's run this command. In the terminal, run npm run demo. Almost instantly, we get back a response. We can see the model is Jeff 1.13.0. And under answers, we can find is frustrated, which matches the name we gave our question. And inside that, the null value tells us the probability that the answer is yes, .94 in this case. We also get back the usage. Input tokens, 292. Output tokens, 23. Now, let's go back to demo.ts and change the message to "Thanks for the update.

Everything is working now." We'll keep the question the same, so "Does message express frustration?" And run it again. npm run demo. You can see answer is frustrated type null, and it's .03, which means no. The customer is not expressing frustration. And the elapsed time is once again under a second. Next, let's look at all_questions.ts. Now, this uses our original customer message, "So, I've contacted you three times and I'm still waiting." But now, we have three different question types.

We have the null type, but we've also added choice and score, which you can see imported at the top. The two extra helpers. Now, for the questions, "Is frustrated?" We still ask the same question, "Does message express frustration?" For choice, we're asking the question, "What is the main request in message?" So, we're asking what the customer wants and providing the options. Are they looking for an update, a refund, a replacement, or something else?

And finally, for type score, we're asking, "How much frustration does message express?" So, we're asking how frustrated they sound and providing three levels we discussed earlier. Makes a request without expressing frustration, expresses dissatisfaction without strong anger, and expresses strong anger. Notice that we are still making only one call. All three questions use the same state. So, we can send them together.

I'm going to clear the terminal and now run the command npm run all. We can now look at the answer for each question. So, in the response, we have the model once again. And for answers, we have is frustrated type null. We have the request type, which is type choice. Request type here, by the way, corresponds to the question name. Type choice. Choice is update. Confidence .99. So, Jeff is pretty confident that the customer is looking for an update.

Probabilities. So, are they asking for a replacement? No. Update? 99% sure, yes. Refund? No. Other? .01. And then the final question, we're looking for the frustration level. It says score 1.02, confidence .97. So, 1.02 means it lies between one and two. So, they're expressing dissatisfaction without strong anger, and they're slightly going into the expressing anger territory. The probabilities are 0.98 and 0.02. And then we have the usage at the bottom.

And even though we asked three questions, you can see the elapsed time is still under 1 second. And then in our application code, you can see we have set a review threshold of .8, which is just for demo purpose. And we're checking if answers.is_frustrated.null is greater than or equal to the threshold, in which case the customer is frustrated and very strong confidence from Jeff, flag this message for support review, which we can see here in the terminal.

I'm using 8 here, but for your own application, choose a threshold by trying representative messages and checking the results. So, this is how you can bring Jef into your application. It evaluates the information you send and use the result whenever you need it in your code. All right, you've now seen how to use Jef. Let's look at the kinds of tasks it's a good fit for and when you would be better off using something else.

Now, there are quite a few places where Jef could be useful. You could route customer requests, categorize a large collection of documents, check whether a passage supports a claim, or decide which model should handle a task. You could also use it in a game or an interface where you need a quick decision. And those are just a few possibilities. Type-safe docs shares a lot more use cases, which might be of interest depending on your requirement.

So, there is search and retrieval, scientific discovery, model routing, LLM guardrails, semantic code linting, recruiting, lead generation, customer support, insurance claims, financial crime, advertising, gaming, and a lot more. There's also example task categories, and I recommend you look this up. But, there are also tasks where I wouldn't reach for Jef. If you need to write a reply, summarize an article, or generate code, you need a model that generates text.

Jef can help judge information that goes into the task, but it won't write the result for you. And if you can calculate the answer exactly in code, do that. Remember our free delivery example? You don't need AI to check whether there are three items in a basket. The same goes for arithmetic, counting, or comparing dates. So, if you have a judgment to make, you can describe the possible answers, and speed or repeated use matters, Jef is worth trying for that task.

All right, let me quickly summarize what we've covered. Jev is an AI model from Type Safe that you can use to make decisions about information. You give it a state and questions and it returns structured answers you can use in your application. We also looked at the three question types. Null for a yes or no judgment, choice for picking from your options, and score for judging something on a scale you define. We saw how Jev's focus on these decisions can make it fast and inexpensive, then walked through using it in the playground and from TypeScript.

If you want to try it yourself, start with one small decision in your application and see how Jev handles your examples. I will leave links to the documentation and the repo, so make sure to check that out in the description. Hopefully, you now have a better understanding of what Jev is and how to use it. Thank you for watching and I'll see you in the next one.