OpenAI announced on October 16 that Prompt-to-voice was available to all of its API clients. The ability allows you to describe a voice using text, create it via the API or Voice Playground, and save it for use in GPT-Live calls. According to the company, creating a voice from a description is free, while generating speech with it is billed at regular GPT-Live session rates.
This distinction is important for developers building a voice interface. Free voice creation does not mean that an entire voice service operates at no cost. The cost depends on subsequent use and the conditions of the system to which the sound is connected. The announcement does not announce a reduction in call rates, and therefore there is no basis for updating a price per user or budget forecast without checking the expected usage.
What can be created, and what systems to use
According to the documentation, characteristics such as pitch, rhythm, accent and presentation character can be described. In this path, there is no need to record a sample or record consent, because the sound is created from the description. This is a different path from creating a voice based on the recording of a person. OpenAI states that such voices are intended for GPT-Live and are not supported on this path in Text to Speech, Realtime, or Chat Completions with audio.
The documentation requires responsible use and transparency with listeners that the speech is AI-generated. The company prohibits impersonation and limits this workflow to adult voices. It also notes that the voice is not guaranteed to be unique, and that other users may get a similar result. Therefore, it should not be assumed that his creation itself provides an exclusive vocal identity to a brand or the right to imitate a particular person.
How to test fit before incorporating into a product
An initial check may include the sentences that the product is actually required to say: names, numbers, instructions, and transitions between languages. It is worth checking whether pronunciation is understandable and the pace suits the context. The announcement does not guarantee specific Hebrew support or uniform availability in Israel, and therefore the actual behavior should be examined rather than deduced from the general release or the possibility of writing a description in Hebrew.
Product teams should also retain an alternative when a voice is unsuitable and define who checks sensitive wording before deployment. A short experiment with a representative scenario can reveal problems that are not prominent in the demonstration sentence. There is no need to build a complex mechanism in advance: the aim is to ensure that the voice serves the task, users understand its origin and costs are measured where speech is actually generated.
The test should also include listening in the full context where the voice will be used and ensuring that the synthetic-voice disclosure appears where listeners encounter it. A good example in itself is not a test of the entire use case.