How Jev-like models improve LLM voice bots

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.

Why do LLM voice bots need a classifier again?

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.

What is Jev?

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.

How fast is Jev?

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.

Which Jev-like models are available?

Jev isn't the only model of this kind. Several Jev-like models have appeared recently, and most of them are open-weight.

• Laya comes from a researcher at Convai Innovations. It's the most popular free alternative to Jev and is open-source under Apache 2.0.
• Clef is an open model from Cloudflare for making very fast decisions inside software systems.
• CMF by Cortiq is an open, lightweight model at 304.5 MB. It answers in milliseconds without generating text and shows high accuracy on classification tasks.
• Bespoke Nimble by Bespoke Labs is a recipe for an "open Jev". It's a LoRA fine-tune of Qwen3.5-9B with constrained decoding, so the model can only answer with the allowed options.
• Kev by @jaredpalmer started as Kev-0.5B, a very small Jev-like model based on Qwen2.5-0.5B that runs locally on a laptop such as a MacBook Pro. It's now a family of models on Qwen3.5 and Qwen3.8.
• CLM-8B, a joint project of Stanford and Nvidia, caches repeated agent actions and ran up to 9x faster than Jev in its authors' tests.

The rest of this piece looks at patterns that work with any of these models. The examples use Jev because their authors did.

How does a Jev-like model route calls between topic agents?

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:

• reviewing the call after it ends
• guardrails that run in the background on every turn, outside the spoken reply
• deciding when to hand the call to another agent or to a person

How can a Jev-like model check an LLM's actions before they run?

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:

• Did the caller confirm this action?
• Does the last remark change, confirm or cancel what we just said?
• Did the caller say goodbye?

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.

How do you detect the end of a turn by meaning?

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 pauses 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 pause 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 pauses, 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:

1. The turn starts with VoiceDSP and voice activity detection.
2. Jev gets one question on the partial or final text: "has the speaker finished what they wanted to say?" The bot's last line goes into the state too, because "yes" only counts as a full answer if the bot just asked a question.
3. If turn detection says the turn is over but Jev sees an unfinished thought, we assume the caller wants to continue and don't give the turn to the bot. If both agree the turn is over, the bot can answer.

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.

How do you tell barge-in from backchannel and side talk?

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 pause, 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.

Can a Jev-like model fill a form in a voice bot?

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.

How do you choose between a cheap and an expensive answer?

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:

1. A prepared answer. No model is called, and the reply comes from speech synthesis or a script.
2. A fast model for short factual answers.
3. A heavy, expensive model for unclear turns and for turns where a mistake would be costly.

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:

• When confidence is low, the turn moves one class up and doesn't stay on the cheap option.
• A question where a mistake would be costly never goes to the cheap class, even if the classifier thinks it's simple.
• Once the class goes up during a call, it stays up. The expensive model is already in the conversation, and switching back to the cheap one on the next "yes" saves very little but can damage the context the expensive model has built.

Where should you start with a Jev-like model in a voice bot?

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.

1. End of turn. The Jev-like model checks whether the thought is finished. The bot's last line goes into the state, because a bare "yes" only counts as complete after a question. On text this adds about 250 ms: around 50 ms for speech recognition and 200 ms for classification. This follows Supreet Tare's setup and our own experiment.
2. Barge-in and side talk. While the bot is speaking, the model checks whether the caller really interrupted or just said "uh-huh", whether they're asking to wait and whether the remark was meant for the bot at all. In Jay Albo's tests this took about 300 ms.
3. Topic. The model picks the specialized agent for the topic. If the topic changes during the call, the same classifier decides, and the agent doesn't guess. This follows Piotr Zaczek's setup.
4. Form and slot filling. This covers booking, rescheduling, cancellation, status and billing. The code finds candidate values, Jev picks the right part of the transcript, replies come from prepared phrases and tests keep a cassette of answers. This is Jason Stiles' approach.
5. Data changes. Before the bot creates, moves, cancels or charges anything, or hangs up, the LLM suggests the action and Jev checks whether it's correct and appropriate. The change is saved only if both agree, and if they don't, the bot decides what to do next. This is Giorgi Lomidze's approach.
6. Answer cost. The model chooses between a prepared reply, a fast model and a heavy model. Use the heavy model when the classifier marks the turn as hard or when a mistake would be costly, and don't switch back to a cheaper class during the call. The rules come from Deepesh Jayal.

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.

What's next

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.