Jev-like models are fast decision models. They read the state of a phone call, answer a set of questions about it and return typed results in a few hundred milliseconds, without generating text. In an LLM voice bot they handle the decisions a single model often gets wrong: topic changes, end of turn, barge-in, form data, checking actions before they run and picking which model answers.
I'm Head of Product at Voximplant. Before LLMs took over, my team built a classifier for voice bots, and after a few years of LLM-only bots we were coming back to the same idea when Jev came out. While we work on a native Jev integration for VoxEngine, I wanted to see where Jev and similar models already help voice bots and what I'd add to a bot first.
On real calls one LLM rarely handles the whole conversation. Sooner or later it misses a tool or runs out of context, and on large projects it often costs too much. A fast classifier can take some of the load off the LLM by making the narrow decisions for it, like when to call a tool or when to switch topics.
In 2022 to 2024, large language models weren't widely available yet, but phone bots already had to understand what callers wanted. So we built our own classifier, Voximplant Avatar. It quickly and cheaply matched the caller's phrase to one of the intents the customer had set up. It also spotted entities in the phrase, the pieces of data a bot needs to act on. Avatar recognized dates and times, numbers, amounts of money, names and locations out of the box, and you could add your own entity types for a project, such as the kinds of pizza on a restaurant's menu. You can get a rough picture of how it worked from the Avatar API reference. It worked well enough, and some projects still use it.
When LLMs arrived, it seemed for a moment that classifiers weren't needed anymore. The model would understand the caller and write the answer by itself. As usual, the excitement didn't last long. On live projects medium-sized models broke down under long system prompts or after a few changes of subject, and they started making things up. Large models coped with long prompts and topic changes, but they either made each conversation too expensive or answered too slowly for a live call.
When you build voice bots for a large customer in production, you have to deliver good answers and hit the customer's metrics without going over budget. Bot builders worked around this with engineering. They split bots into stages, put several agents and a router model on one phone number and used scripts for parts of the dialog that always go the same way.
We launch several hundred large commercial projects a year, and on these projects we keep seeing the same thing. A single model misses the moment to call a tool, runs past its context window or uses so many tokens that it breaks the unit economics of the service. In real projects you can't rely on one model to carry the whole conversation.
By then Avatar's architecture was outdated, and we had started replacing it with a similar setup based on a small language model that's fast and cheap to run. Then Jev came out, and it felt like coming back to an idea we already knew.
Jev is a decision model from TypeSafe, a model that answers questions with typed results and doesn't generate text. It's been in early access since September 2026.
You send Jev a few questions along with the current state of the call. Usually that's a piece of the transcript and the bot's last line, sometimes also the step the scenario is on. For each question Jev returns a structured answer, and you decide its type in advance. It might be one of the options you listed or a score on a short scale, and for a direct question it's the probability of "yes".
Since Jev doesn't write text, your bot's code decides what to do with each answer. The official description and question types are on jevtypesafeai.com.
Jev usually responds in under 500 ms, though published measurements vary. One developer got answers to 35 questions in about 170 ms on a connection that was already open, and another measured between 332 and 892 ms. TypeSafe's own materials give a range of 70 to 500 ms.
Jev isn't the only model of this kind. Several Jev-like models have appeared recently, and most of them are open-weight.
The rest of this piece looks at patterns that work with any of these models. The examples use Jev because their authors did.
A fast Jev-like classifier sits at the start of the call. It picks a small agent built for one topic and connects it to the conversation. The classifier also decides when the caller has changed the subject, and it does this before the large model starts writing an answer.
This solves a common problem in voice menus. One phone number often handles several topics, such as bookings, order status, complaints and requests to be connected to a human. If all of that sits in one prompt, a medium-sized model gets overloaded and starts talking nonsense after the second or third change of subject.
Piotr Zaczek showed this on a voice setup in a short video. The video shows how long the system takes to decide that the conversation should change direction. With the classifier it takes about 0.5 seconds instead of almost 5, and the large model uses fewer tokens. In Piotr's setup the large model isn't allowed to reason outside its topic, and the decision to switch topics belongs to the classifier.
A specialized agent has a short prompt and one set of tools, the specific actions it's allowed to perform. The classifier is cheap and fast, so you can ask it every time the subject changes.
In the same post, Zaczek names other ways he likes to use Jev besides routing:
The LLM only suggests an action. Before that action changes anything in your systems or in the conversation, a Jev-like model answers a few simple yes/no questions about it. Your code then decides what to do based on the probabilities.
Anyone who has run an LLM bot on real calls knows this problem. The bot sounds friendly but often doesn't finish the job. It finds a free slot but never books it, saves the appointment under the wrong name, stays on the line after "goodbye" or asks the caller the same question twice.
Giorgi Lomidze explains in his post JEV in Production from 24 September 2026 how his team moved these decisions from the speech model to a Jev-based check in two weeks. Their product, Pocos, is a phone assistant for salons and studios, and it runs on Voximplant. Thanks to Giorgi for mentioning it, it was great to see.
The call comes into Voximplant over SIP, the protocol that brings phone calls onto the platform. A VoxEngine scenario connects to the LLM through RealtimeAPIClient (Gemini Live in their case) and runs the voice conversation, including the greeting, interruptions, timers and hang-up. The speech model listens to the caller and suggests which tool to call. Before anything happens, the classifier checks that suggestion. The scenario puts together a short set of facts about the call, asks Jev several yes/no questions and gets probabilities back.
The questions are simple and literal. For example, Jev might be asked:
What happens next depends on the probabilities Jev returns, and the thresholds need to be tuned for each case. In Giorgi's setup, strong agreement starts at 0.9 and weak agreement is anything up to 0.1. A goodbye counts as strong from 0.75, but only if the caller hasn't raised a new topic.
Giorgi's approach comes down to this: the LLM only suggests, Jev checks and the business decides.
First run acoustic turn detection, then ask a Jev-like model one question about the text: has the caller finished what they wanted to say? If the two disagree, assume the caller wants to keep talking and don't give the turn to the bot.
Silence alone doesn't tell you whether a remark is finished. A caller s mid-sentence, and the silence timer is already about to give the turn to the bot. Yet "yes" after "shall we move it to Tuesday?" is a complete answer, and "What I wanted to say was..." isn't, even when the is just as long.
At Voximplant we have our own tools for end-of-turn detection in Agentic VoiceDSP. This VoxEngine module combines Silero voice activity detection, the Pipecat Smart Turn end-of-turn detector and the optional Hush noise suppressor. Developers get turn events (TurnStarted, TurnInferenceTriggered, TurnStopped) and can react to each one. When the caller s, Smart Turn decides whether the turn is over. If it isn't, the module keeps waiting for stopSecs. In other words, this layer judges the end of a turn by how the speech sounds.
On top of that, we want to add a check on meaning: is the thought complete, or is the person still looking for the next word? It should work technically. Speech recognition usually takes about 50 ms and Jev classification about 200 ms, so together it's around 250 ms. That's not instant, but for most industries it should be fast enough for a phone bot with a full cascade, where speech recognition, the LLM and speech synthesis run as separate steps.
Here's the experiment we have in mind:
Supreet Tare from Taritas uses the same approach in a live voice coaching project and describes it in semantic turn detection with Jev. In his setup, the audio layer detects silence, and after 350 ms Jev gets one question. The answer comes back in about 0.4 seconds. Then the code decides how much longer to wait: 1.7 seconds if the thought seems finished (probability of 0.75 or higher), 2.8 seconds if the result is unclear and 4.5 seconds if the phrase ends on "and", "but" or a comma. That sounds slow, but in Supreet's coaching app, not missing anything important matters more than answering fast.
One call to a Jev-like model can tell you whether the caller finished their turn, asked you to wait, really interrupted the bot or was talking to someone else in the room.
Jay Albo explored this on Agora Conversational AI in his post Jev VAD, with code in the AgoraIO-Community/convoai-jev-vad repository. His setup also detects the start of speech from the audio level, but here I'll only look at the Jev part. When the caller starts talking, the text goes to Jev, and one call returns four probabilities:
turn_complete shows the caller has finished the thought and the bot can take the turn.holding_floor shows the caller is asking for a , as in "Wait, let me check...".addressed_to_agent shows whether the caller was actually talking to the bot. "Hey, keep it down, I'm on the phone" is meant for someone else. For me this was the most interesting detail, and I hadn't seen it before.taking_floor shows whether the caller really interrupted the bot or just made a listening sound like "mm" or "uh-huh", known as a backchannel. Some models can detect these sounds on their own, but they don't do it consistently, and switching or updating the model can break the bot at exactly this point.
In Jay's tests, Jev answered in about 300 ms.
Yes, in small domains like booking, rescheduling or cancelling an appointment, or answering a billing question. The bot's code finds possible values in the transcript, and the Jev-like model picks the right one, so it can't make up a value.
These domains are narrow, but people speak naturally and often give everything at once: their details, the specialist they want and the date and time of the visit. An LLM that also has to speak is more than this task needs. What you need is something like Avatar, a classifier that pulls the useful data out of what the caller said and passes it to the bot's code.
Jason Stiles built this as a phone line for a made-up clinic and described it in Jev IVR, updated on 24 September 2026. His stack is Node, Twilio ConversationRelay, Deepgram for speech recognition, ElevenLabs for the voice and Jev for understanding.
The bot's code keeps track of the form. On each turn it sends one request to Jev with about 30 to 35 questions. Intent is picked by description, so "move it", "let's take another day" and "I need to change my appointment" all end up as reschedule. Each intent is described by what the caller wants to do.
Getting the actual values takes more work. First the code finds candidates in the transcript: every number is a possible birth year, and every phrase of one to four words is a possible name. Then Jev picks which candidate is the year or the name. The big advantage here is that the classifier can't make things up. Jev can't invent a date, so any error in the data comes from what the caller actually said. Confirmation is always a separate request: the caller agreed, refused or named a field to change. It sounds old-fashioned, but it's fast and predictable.
On every turn, a Jev-like model can decide whether the turn needs an expensive answer. Based on that, the reply comes from a script, a fast model or a heavy model.
Topic routing decides what the bot talks about. There's also a second choice on every turn: how much the answer should cost. A "yes", an account number or a short status can be handled cheaply. Confusion, instructions, a long explanation or a refusal may need a more capable model.
Deepesh Jayal (Evalgent) describes this in his article Jev for Model Routing in Voice Agents. He splits answers into three classes:
Deepesh builds on ModelRouterMiddleware from the langchain-typesafe package. The rules for picking a model are written in plain language, and the probabilities are saved in the agent's state. After the call, you can see why a turn went to the expensive model.
There are rules in his article I'd use as they are:
I'd start with end of turn and barge-in, then add topic routing, form navigation, checks on data changes and, last, answer cost. Each step needs its own confidence threshold, and you'll need to tune it for each project.
I'd personally argue with step 4. There are better ways to extract structured data from speech than having a classifier make yes/no choices. Still, it's a worthwhile experiment, and it's useful for moving through a menu and the fields of a form.
At Voximplant we're already adding Jev to the AI connectors in VoxEngine, and we'll announce it as soon as it's live. The integration will most likely work with your own TypeSafe API key.
You don't have to wait for it to start exploring these patterns: the write-ups linked above show how each one was built. If you're running Jev or a Jev-like model in a voice bot, I'd like to hear what thresholds you landed on and what broke along the way. Leave a comment here, or tell us in our Discord.
Originally published on the Voximplant blog.