Jev Is a Fast Model That Picks From Your List
Lim Gang Rui starts his Coworking Friday talk with a show of hands. How many of you have heard about Jev? Most of the room. How many have tried it? "Uh-huh, that's good." The talk lives in the space between those two answers. Jev, from TypeSafe AI, has been all over social feeds, and Gang wants to walk the room past the flashy demos and into the practical part.
He comes at it from the side of someone who has to make AI behave on a budget. He teaches non-technical folks to use agents like Claude Code and Codex without busting their usage limits, builds products at GovTech, and used to build AI products for startups, mostly around evals. That last part matters, because by the end of the session almost every answer he gives comes back to evals.
Think of a receptionist
His picture of Jev is a receptionist. Someone walks up and says, "hey, you charge me twice." The receptionist's job is to decide whether it goes to billing, technical support, or someone else. That's the job Jev does. You pass it some state, ask it questions with fixed options, and it returns the most plausible choice with a confidence score. Claude and GPT have a conversation with you. Jev doesn't.
TypeSafe frames it with Thinking, Fast and Slow. Decision models are the System One thinkers, fast and efficient. The chat models are System Two, slower and deliberate, and able to do much more. Gang shows what fast buys you. In one popular demo, a browser agent books a flight from Zurich to London in seven seconds, because at every step the screen state goes to Jev with a list of possible clicks and Jev picks the next one in milliseconds. In another, OpenAI's own decision API, which can read images, drives a car in real time. A third has a frog avatar hooked up to a live voice chat, picking its facial expression from what the person says as they say it.
The answers come in three shapes. A choice from a list, up to 255 options. A yes or no judgment. A score on a scale you define, like an NPS rating. The part he calls most powerful is that you can ask fifty questions about one email in a single request. Is the person angry. Which department should it go to. All fifty answers come back in milliseconds, in a format your code can read and route.
The work is writing the rubric
Then comes the condition that most of the hype skips. "So when your problem is not well defined, right, then you shouldn't use like decision models." Jev needs a rubric. "Sort out my inbox" is not a task it can do. "Does this thread contain an unanswered question to me" is.
He shows his own morning email brief. He used to run agents to analyze and categorize his inbox, and it was slow and expensive. Now the classification step is Jev, picking one of seven sections for each email, things like important, learning, finance, ideas, and social. The trick is in how he defines each category. Every option carries a "use when" and a "not when," the same few-shot habits you'd put in a system prompt when a model keeps getting something wrong.
He calls Jev nothing new, just a model that is very fast and returns structured output your code can read. "So whatever things you are learning is still applicable." Everything builders already know about writing good prompts carries over. What changes is the cost of asking. He puts it at 0.042 cents per million input tokens and nothing for output, and when Jev isn't sure, the confidence score tells you. Below 70, route it to a human, and use those cases to find the situations your workflow never accounted for.
He's just as clear about where it doesn't belong. Writing and brainstorming, broad strategy, and anything that needs an exact calculation, which should be code. The model also only takes text. For images, you go to OpenAI's version and pay a bit more.
I've watched a lot of builders reach for the biggest model for every small yes or no in their pipeline. Gang's talk is a good argument for spending that effort on the questions instead.
What the floor wanted to know
The best question of the session was about failure. Someone asked how he evaluates Jev's decisions, since however carefully you codify it, there will be cases where it decides wrong. His first answer is plain: always fact check. His second is the one to copy. Build fifty or a hundred test cases. Run them through Jev with a first-pass rubric. Annotate the same cases yourself, pass or fail. Compare, feed the gaps back into a model to tighten the rubric, and repeat until it agrees with you. Then, he says, you know it "is encoding my taste on it."
Another builder pushed back on the pitch itself. Speed and low cost are two different problems, they said. In the hotel case, the luxury chat product Gang had worked on at a startup, nobody needs the answer to be fast. Maybe it just needs to be cheap. Which one actually matters? "As usual the answer is always it depends." A browser agent can afford to be slow. Anything talking to a person in real time can't. And because Jev has no reasoning, there are jobs where you fall back to a stronger, slower model and accept the wait.
A third question came from someone building a QA agent on computer use, which was too slow to be useful. Gang called the habit behind it one of the most common mistakes he sees: people "are too focused on like prompt." The fix is the tool. If your computer use tool can capture the state of the screen and output a clean list of possible actions, Jev can pick from that list quickly. If the tool can't, no prompt will save it.
Not everyone on the floor was sold. One person who had been designing Jev workflows shared what went wrong for them. Frontier models were bad at designing the workflows, and without TypeSafe's own skill for it, their classification was right only around 20% of the time. Multi-step decisions were still hard to design, closer to building logic gates than writing a prompt. Their verdict was that most use cases don't benefit yet, because if you're already paying for a $200 subscription, saving five or ten dollars isn't worth the setup time. Where it does pay, they said, is latency, like voice, and high volumes of decisions, like ranking around 2,000 people for an event invite list.
Where the boring work is
Asked for the less obvious uses, Gang named lead generation. Multi-stage filtering, a different rubric at each stage, leads routed to different salespeople. He was honest about what it takes. You sit beside the person who does the filtering today, learn how they actually decide, encode that into a rubric, run it, and check back with them until it matches. He called it boring more than once. He also said that done with precision, that's where these models pay off.
His advice for finding a first use case was to go back through your own AI chat logs and have a model list every step that is really classification, routing, or ranking. That's a cheap afternoon for any builder here. The harder question is whether we'll do the slow part after it, sitting with the people whose judgment we're trying to encode until the rubric is right.
SQ Collective hosts Coworking Fridays for founders, operators, and AI builders working through real product questions in Singapore.
Join an upcoming Coworking Friday: https://lu.ma/ai-labs
Explore SQ Collective: https://www.sq-collective.com
Michael
Comments