Call ID: 019c27ea-1252-7775-9dce-b89b74927e01 Model: gpt-4o-mini During a squad call (during agent handoff), two nearly identical OpenAI HTTP requests are fired ~2 seconds apart for the same user turn. The message payload is identical — the only difference is the model string: the first uses gpt-4o-mini-2024-07-18 and the second uses gpt-4o-mini. Request 1 (log-570): timestamp 1770196248822, model gpt-4o-mini-2024-07-18 - Request 2 (log-573): timestamp 1770196250818, model gpt-4o-mini — same messages, same tools, same max_tokens - Response (log-580): timestamp 1770196251708, latencyMs 2886 — matches request 1 only

This usually happens because of alias vs snapshot models. gpt-4o-mini is an alias, while gpt-4o-mini-2024-07-18 is a pinned version. During a squad handoff, if one assistant (or override) uses the alias and another uses the snapshot, both can briefly fire on the same user turn. Only one response is used; the other request is wasted. Fix: make the model identical across the entire squad (all assistants + overrides). Use either only gpt-4o-mini or only the dated snapshot everywhere. If it still occurs, share the callId with Vapi support—it’s likely a handoff race condition.

We reviewed the logs for call ID

019c27ea-1252-7775-9dce-b89b74927e01

and can confirm the two OpenAI requests you’re seeing are expected behavior. This is Vapi’s model fallback / racing mechanism working as designed. What happened: The system was configured with

gpt-4o-mini-2024-07-18

as the primary model (with a ~2s timeout) and

gpt-4o-mini

as the fallback. When the primary didn’t respond within the timeout window, the fallback request was triggered. The primary then completed successfully, so the fallback was immediately aborted. Key points: • Only one response was used (from the primary model) • The fallback request was aborted with 0 tokens / 0 cost • This racing behavior improves reliability and avoids latency spikes when a model is temporarily slow No action required. If you want to reduce how often fallbacks trigger, the system automatically learns from historical latency and adjusts timeouts over time, so the primary timeout will better match real-world performance.