This is a critical error for one of our functionalities. We are currently using the voice.chunkPlan.formatPlan.replacements option for the "11labs" voice type. Here is what happened: 1. I first tried the following replacements option:

voice: {
  provider: "11labs",
  voiceId: "matilda",
  chunkPlan: {
    formatPlan: {
      replacements: [
        {
          type: "exact",
          key: "Bonnie",
          value: "Bombay"
        }
      ]
    }
  }
},
firstMessage: `Hi Bonnie, this is Joy. How's it going?`,

Then when I called the phoneNumber, the assistant picked up and said "Hi Bombay, this is Joy. How's it going?" This is indeed what we expected. 2. Then after, I changed replacement from "Bombay" to "Jonathan" like the following:

voice: {
  provider: "11labs",
  voiceId: "matilda",
  chunkPlan: {
    formatPlan: {
      replacements: [
        {
          type: "exact",
          key: "Bonnie",
          value: "Jonathan"
        }
      ]
    }
  }
},
firstMessage: `Hi Bonnie, this is Joy. How's it going?`,

But when I call the phoneNumber, it is still answering with the first message audio of "Hi Bombay, this is Joy. How's it going", instead of "Hi Jonathan...". This is NOT the expected behavior. There's an example of this happening on this call: call.id: 0814b311-fadd-49a5-9886-ca934a148353 timestamp: 1740107875746 3. Suspecting that there is some caching error going on (either Vapi having cached an audio file that is just playing for the firstMessage, or whether the chunk itself was frozen with the first occurrence of the replacement and is not updating subsequently), I tried changing the string of the firstMessage itself, and only then does the new replacement actually take place (but this new one will also be stuck on that particular replacement). This is a critical error for our pronunciation implementation and we'd really appreciate your help looking into this for us! Thanks!

Thank you for reporting this issue. The issue stems from the audio caching mechanism used by the voice provider. The cache key is generated using a hash of: \- The voice configuration \- Sample rate \- The text content You can clear the cache for this specific audio by generating a new hash. The simplest way is to modify your firstMessage.

Okay do you have any best practices suggestion on how we should go about generating a new hash? Because per my situation above, the actual text content of the firstMessage has to be kept the same, but the audio needs to change based on the replacement value

The cache is not maintained or created by the Vapi; instead, it is maintained by the voice provider. In this case, you can try tweaking the first message words or using a different first message for some time. The voice provider will automatically clear the cache in such cases when the similar sentence is not used..