Cue Turn Detection: Phone Numbers, Benchmarks and Limits

Back

Kevin Riedl

14 min read · 15 Oct 2026
Last reviewed October 15, 2026

Next

A phone number is not a sentence. Someone says a few digits, pauses to remember the rest, then continues. A voice agent that treats that pause as permission to speak can lose the number before its language model has done anything useful.

Cue v1 is Pype AI’s open-weight turn detection system for deciding when a caller has finished and whether the caller is interrupting. Its published evaluation combines a fine-tuned Gemma 4 E4B text decision model with Pipecat’s Smart Turn v3.2 audio score. Downloading Cue’s weights supplies the text component, not the complete voice pipeline. Pype’s model card makes that boundary explicit.

The opportunity is better timing during structured conversations, especially phone-number collection. The buying question is more demanding: does it help your agent capture the correct, confirmed number without talking over the caller?

What did Pype release with Cue v1?

Pype’s release record dates Cue 1.0.0 to 12 October 2026. This review was checked on 15 October 2026. Cue is Pype’s release, not a Wavect product.

The launch post and demonstration focus on pauses during phone-number dictation and multilingual conversations. That is a useful explanation of the problem, not a controlled measurement of capture accuracy. This article reviews published artifacts and proposes an evaluation plan. We have not run a Cue production deployment or independently reproduced its inference benchmarks.

Cue sits between hearing words and deciding to respond. It does not replace speech recognition, phone-number validation, speech generation or the system that saves the final customer record. Those are separate decisions, covered in our streaming ASR review and Phonely Alma voice-LLM review.

Why do voice agents interrupt phone numbers?

Consider this illustrative exchange:

Agent: “What number should we call you back on?”

Caller: “Plus four three ...”

Agent: “Thank you. And your email?”

Caller: “I haven’t finished.”

The mistake is not necessarily bad transcription. The digits may have been recognized correctly. The system ended the caller’s turn too early.

Voice activity detection, or VAD, asks whether speech is present. Automatic speech recognition, or ASR, transcribes it. End-of-turn detection asks whether the speaker has finished their contribution. Barge-in handling decides what to do when the caller speaks over the agent. These responsibilities should not share one undifferentiated “silence” setting. LiveKit’s turn-handling documentation explains their interaction.

A longer timeout can protect pauses, but it also delays genuinely complete answers. Disabling interruptions avoids some false stops but prevents callers from correcting mistakes. A useful system needs to distinguish hesitation, completion, acknowledgement and objection.

Cue is not the first model to address this. LiveKit documented structured-input and multilingual turn-detection improvements in December 2025, including phone numbers. The interesting question is whether Cue’s inspectable combination is a better fit for your workflow, not whether nobody previously noticed the problem.

How does Cue combine context and audio?

The Cue repository describes two decisions. For a pause, the text component receives conversational context and assigns scores to four states. While the agent speaks, a separate prompt distinguishes an interruption from a listening response.

Pipecat’s Smart Turn model separately examines the waveform. It is an audio-based semantic turn detector, not merely a timer. Cue adds explicit text context, such as the question the agent asked and what the caller has already supplied.

The published caller-agent recipe combines their scores:

text_end = P(DONE) + P(LIKELY_DONE)
combined_end_score = text_end * sqrt(audio_end_score)

A threshold then determines whether to end the turn. This combined score is not proof that a number is complete or correct, and the formula does not make it a calibrated real-world probability.

Two implementation details in Cue’s client source deserve attention. The model produces one answer token and reads the option log probabilities, rather than generating a paragraph. But when log probabilities are absent, the client can fall back to the returned letter and assign it all the probability mass. A successful HTTP request can therefore conceal a changed scoring contract.

Test the raw response contract, not just whether the helper returns a dictionary. Also, with_voice(...) combines scores you supply. It does not load Smart Turn or process microphone audio for you. The separate wait(...) helper implements a different silence-wait policy; it is not the benchmark’s fused-score threshold policy.

Cue vs Smart Turn and LiveKit: what do the benchmarks say?

Pype reports the following results using LiveKit’s eot-bench. These are publisher-reported measurements, not a Wavect benchmark or an independently verified leaderboard endorsement.

Source: Pype’s published results and limitations, English, 400 caller turns. The two columns describe separately tuned operating points, not two measurements of one fixed production configuration.

At the 5% budget, Cue’s reported endpointing delay is 332 ms lower than Smart Turn’s, but 176 ms higher than LiveKit’s hosted model. Those differences are arithmetic on this table, not promises about a customer’s calls. “Beats Smart Turn here” is supported. “Best turn detector” is not.

The eot-bench methodology measures when the policy decides after the actual turn ending. It does not measure GPU inference time or the full wait until the agent’s voice is audible. Its default transcript lag is 500 ms, and it sweeps thresholds, minimum action delays and timeouts.

There are also different layers of holdout. Pype says the fine-tune did not train on benchmark conversations, but 150 English benchmark turns were used to develop the prompt and fusion recipe. The headline table covers all 400 turns. Calling the entire table an untouched test set would overstate the evidence.

Does multilingual mean German, Chinese and mixed-language calls work equally well?

No. A multilingual evaluation is useful evidence, not a guarantee for every language, accent or code-switching pattern. Pype reports evaluation in 14 languages: Arabic, Chinese, Dutch, English, French, German, Hindi, Indonesian, Italian, Japanese, Korean, Portuguese, Spanish and Turkish.

These are selected rows from the same Pype results. Portuguese’s first place applies to this operating point, not every metric. The comparison pools also contain different numbers of systems.

The same English prompt was used, but preprocessing was not completely identical: Pype neutralizes the transcript-ending feature for languages where punctuation is commonly missing. The public eot-bench dataset contains human-agent turns with audio and text context. It is not a dedicated test of multilingual phone-number capture.

For an Austrian business, test German with the accents, digit grouping and English switches your callers actually use. For every market, test the production ASR output, not a manually corrected transcript. We found no published Cue result establishing within-call code-switching accuracy or exact phone-number capture accuracy.

Can Cue reliably tell “okay” from “actually, no”?

That distinction matters most during read-back. An “okay” might mean “I’m listening.” A short “no” may invalidate the number the agent is about to save.

Pype reports 98.9% STOP-versus-CONTINUE accuracy on 90 held-out synthetic questions. That is not 98.9% reliability on multilingual production calls. The results also disclose a counterexample: “hmm, actually no” can be classified as CONTINUE until more information arrives.

Training used 310 LLM-written conversations. Pype publishes a training specification and scripts, but not the conversations themselves. Open weights make deployment and inspection easier; they do not make every training claim independently reproducible from the released materials.

Our recommendation is to treat corrections as a separate safety condition in the capture workflow. Re-evaluate as words arrive, suspend a pending save when an objection is detected, and make sure a STOP decision actually cancels queued speech. A correct classifier cannot stop audio that your telephony layer keeps playing.

How should a phone-number capture workflow use Cue?

Use Cue to decide when to listen or speak. Use application logic to decide what may be stored. We recommend the following separation, regardless of the turn detector.

First, retain the number-in-progress across pauses. Keep the conversational question and earlier chunks available. Do not overwrite the draft with each ASR fragment, and do not let a stale endpointing response close a newer transcript revision.

Second, parse spoken digits and apply country-aware normalization. Check plausible format and length with an appropriate phone-number library. Do not hard-code “ten digits” globally. Format validation still cannot prove that the number belongs to the caller or that the caller intended those digits.

Third, read the normalized number back clearly. Require an explicit confirmation appropriate to the workflow before committing it. A listening noise should not count as consent to save a field. Corrections must replace the affected draft value and invalidate the previous confirmation.

Finally, save only the confirmed value. Make retries safe so a timeout cannot create duplicate records. Provide a keypad, secure text-entry or human fallback when repeated attempts fail. Minimize retained audio and transcripts rather than logging real phone numbers everywhere to make debugging convenient.

This is our proposed control design, not functionality supplied by Cue. Its outcome is a correct confirmed field, not merely a lower turn-detection delay.

How can you evaluate Cue locally without mistaking a demo for an integration?

Pype publishes a GGUF file and LoRA adapter. The release’s licensing notice declares Apache-2.0 for Cue’s weights, adapter, prompts and documentation; the separate Smart Turn dependency is BSD-2-Clause.

For a developer smoke test, use a Python environment and a GPU-capable llama-server build that supports Gemma 4. This macOS/Linux shell example pins the reviewed client source. It is not a fully pinned production environment, and it has not been executed for this review.

git clone https://github.com/PYPE-AI-MAIN/cue-v1.git
cd cue-v1
git checkout 7919e712801e4b93f8de4dd1577fd908510005db
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e . huggingface_hub
hf download Pype/cue-v1 cue-v1-q8_0.gguf --local-dir models
llama-server -m models/cue-v1-q8_0.gguf -c 8192 -np 4 -ngl 999 \
  --jinja --host 127.0.0.1 --port 8090

The Hugging Face CLI guide documents hf download and its --revision option. Record the model revision and file checksum, then pin them before a controlled comparison. Keep the llama.cpp server on loopback for a local test; do not expose an unauthenticated inference port to the internet.

In a second terminal, enter the repository, activate the same environment and run python examples/quickstart.py. That exercises the text decision interface. To evaluate the published combined system, you still need Smart Turn v3.2, synchronized audio and transcript inputs, and your own threshold policy. Add request deadlines, stale-result rejection and a bounded fallback before connecting real calls.

How many calls can one GPU handle?

Decisions per second are not simultaneous calls. Pype’s T4 measurements report roughly 13 decisions per second. The median rises from 79 ms with one request in flight to 364 ms with four and 1,220 ms with sixteen. This is the serving measurement, unlike the earlier endpointing table.

Pype’s capacity estimate assumes roughly six decisions per caller turn and six turns per minute. Under those assumptions, one call needs 0.6 decisions per second. Twenty active calls therefore average 12 decisions per second, already close to the reported throughput.

That calculation does not show that twenty callers can pause together and all receive sub-200-ms decisions. Benchmark burst arrivals, cache misses and the actual prompt length. Set admission limits using tail latency, not just average utilization.

The publisher’s approximate $0.0005 per call-minute figure is a GPU-allocation estimate under its assumptions, not an all-in voice-agent price. Add ASR, TTS, telephony, orchestration, monitoring, idle capacity and support before comparing cost per accepted AI action.

What should a phone-number acceptance test include?

Use the following as a proposed test matrix, not achieved Cue results. Create permissioned or synthetic fixtures for every supported language and keep a separate tuning set.

Define the main metric before testing: first-attempt capture success = attempts that produce the exact intended, explicitly confirmed number without restarting dictation / all eligible first attempts. Separately report eventual capture, incorrect saves, caller cutoffs, repair turns and abandonment.

Measure by language and call condition. Track end-of-turn delay, audible response delay and objection-to-audio-stop delay separately, including P95. Compare the current system, Cue’s text-only path and the combined path under the same acceptance rule. Set thresholds on tuning calls, then freeze them for the held-out test.

When is Cue worth adopting?

Cue deserves evaluation when structured answers are being cut short, multilingual caller behavior matters, and your team can operate a text-and-audio decision pipeline. It is less compelling as an untested swap into a healthy system or as a shortcut around unreliable transcription.

Wavect’s AI integration and engineering service focuses on making components work inside controlled business workflows. Our Twinsoft AI case study is adjacent delivery context, not evidence of a Cue implementation. The software QA checklist before launch covers the broader release decision.

Bring a sanitized example of a failed number capture and the required customer-record format to discuss your voice-agent workflow with Wavect. The goal is not a model that speaks sooner. It is an agent that listens long enough, accepts corrections and saves the right result.