A simple fix for LLM tail latency

# A simple fix for LLM tail latency | HOAi Source: [https://engineering.myhoai.com/posts/a-simple-fix-for-llm-tail-latency](https://engineering.myhoai.com/posts/a-simple-fix-for-llm-tail-latency) When LLM responses are too slow for your realtime use case, you may be tempted to pay double the cost for a faster service tier\. Anthropic’s[Priority tier](https://platform.claude.com/docs/en/api/service-tiers), OpenAI’s[priority processing](https://developers.openai.com/api/docs/guides/priority-processing), Gemini’s[priority inference](https://ai.google.dev/gemini-api/docs/priority-inference), whatever your LLM provider calls it\. There’s a simpler solution: send every request twice and take the faster response\. ## Why tail latency matters for voice agents Our voice agent at HOAi answers phone calls\. Every turn in a conversation makes an LLM request\. Most responses come back within 1\.5 seconds, but occasionally one takes 10 to 20 seconds\. On a phone call, that’s 10 seconds of awkward silence, and after enough silence, the caller hangs up on our agent\. This happens more often than you’d think\. A typical phone call has 20 to 30 turns\. If 1% of LLM requests are catastrophically slow, a 25\-turn call has roughly a 22% chance of hitting a long silence\. ## Priority tier vs\. sending each request twice We had two options\. 1. Upgrade to OpenAI’s priority tier and pay 2x cost per token for faster, more consistent responses\. 2. Stay on standard tier, but send every request twice and take the faster response\. We replayed 50 real production requests against both setups and tracked two metrics: time to first token \(when the agent starts speaking\) and time to complete response \(when it can act on tool calls\)\. Time to first token: Priority tierStandard tier, sent twicemedian0\.61s0\.58sp951\.04s0\.68sp994\.2s1\.2sTime to complete response: Priority tierStandard tier, sent twicemedian1\.35s1\.35sp953\.4s2\.0sp999\.8s3\.5sworst9\.8s3\.5sSending the request twice clearly outperformed the priority tier\. Worst\-case time to complete response dropped from 9\.8s to 3\.5s\. Worst\-case time to first token dropped from 4\.2s to 1\.2s\. Even the median matched the priority tier exactly, despite the standard tier being slower per individual request\. This works when slow responses are rare and independent\. Sending the request twice makes it unlikely both copies are slow on the same turn\. This significantly reduced the 10\-second silences our callers were experiencing\. ## The takeaway If you are building a realtime interactive LLM product, before you pay for the faster service tier, benchmark it against sending the request twice\. You may get better latency at the same cost\.