Create a key in your account, name a voice model, send your text and get an audio file back. The catalog holds 24 text-to-speech models from several providers, so an app narrator, a phone menu and a voice agent can each get the voice that suits them. Test any script in the toolkit today.
Text to speech has no single best voice. One model reads a bedtime story warmly, another keeps a phone menu crisp, another is built to answer inside a conversation. A text to speech API from Picasso IA puts them behind one key: you name a model, send the text, and get an audio file back, without opening an account with every voice provider.
Every voice provider has its own sign-up, its own billing and its own way of describing a voice. That is bearable when you need one narrator. It gets old when your app needs a calm reader for lessons, a clear one for phone menus and a quick one for a voice agent, because each choice means another account, another key and another set of settings to learn.
The Picasso IA API takes the opposite route. You create a key in your account, send one request that names a model and its inputs, and the result comes back as a file you can download. The text-to-speech category of the catalog holds 24 models from owners such as elevenlabs, google, inworld, xai and minimax, out of 502 models in total. The outline of the request stays the same: a model and its inputs. Switching voices becomes a change of model name instead of a new integration.
Cost works the way it does in the toolkit. A generation spends credits, and how many depends on the model and the settings you choose, so the pricing page is the place to read about plans. The toolkit runs the same catalog, which means you can hear every voice there today, before you build anything around it.
A request has four parts. The key proves the request comes from your account. The model name says which voice should speak. The inputs carry your text and the settings that model understands. The answer is the generated audio, delivered as a file you download.
The inputs are where models differ, and that is useful rather than annoying. google/gemini-3.1-flash-tts offers 30 voices and takes a plain-language style instruction, such as speak slowly and with confidence, plus tags like whispering or laughing inside the text. inworld/tts-1.5-max and inworld/realtime-tts-1.5-max read emotion tags such as happy or sad and accept a voice you own by its identifier. elevenlabs/v3 lets you set stability, speed and how theatrical the delivery should be. xai/grok-text-to-speech has five voices and can export formats meant for phone systems.
You do not memorize any of this. Each model page in the collection lists what the model accepts, and the toolkit shows the same fields as a form, so you can learn a model by clicking before you ever write the request.
The four uses people ask about most are app narration, phone menus, audiobooks and voice agents. The table below is a starting point for what to try first and what to listen for. It is not a ranking: run the same script through two models and trust your ears over this page.
| Job | Model to try first | What to listen for |
|---|---|---|
| App narration | elevenlabs/v3 | A voice that stays steady from the first screen to the last |
| Phone menus | xai/grok-text-to-speech | Clear numbers and a file format your phone system accepts |
| Audiobooks | elevenlabs/v3 | The same speaker and pace, chapter after chapter |
| Voice agents | inworld/realtime-tts-1.5-max | Short replies that sound spoken, not read aloud |
| Many languages | google/gemini-3.1-flash-tts | Accent and pronunciation in every language you ship |
| A voice you own | inworld/tts-1.5-max | The same tone across everything you generate |
A model that suits a lesson may sound wrong in a phone menu, and the reverse is just as common. Keeping two or three candidates for each job, and choosing between them per project, is exactly what a single key across providers makes cheap to do. For the production side of narration, AI voiceover for videos and audiobook narration go deeper on pacing and chapters.
Most disappointing audio is a script problem, not a model problem. Voices read exactly what you give them, so write for the ear. Short sentences breathe better than long ones. Spell out anything you want said a particular way: a product name with an odd pronunciation, a phone number grouped the way people say it, an abbreviation you want read in full.
Send one language per request, and match the language setting to the text. Mixed-language lines are where voices guess, and a guess sounds like an accent mistake. Keep tags to the ones the chosen model documents, because a tag that works on one model can be read out loud as a word on another.
Read your script aloud once before you send it. Anywhere you stumble, the voice will stumble too, and fixing a sentence costs nothing while regenerating costs credits.
Start with one paragraph, not the whole chapter. Each generation spends credits, so a short test tells you whether the voice, the language and the tags are right before you commit a long script to it. Models also cap how much text one run accepts, and the cap differs per model, so long material gets split by section or chapter and joined afterward.
This is the path from nothing to a file in your hands. Before step one, run a paragraph of your real script in the toolkit: it uses the same models, so the voice you pick there is the voice your requests will use.
If a step does not behave the way this page describes, support answers questions about it.
This is a description of a key, a request and a file. It is not a promise of anything more, and there are five places where a builder should slow down:
Phone menus and voice agents deserve a final caution. A synthetic voice that reads a menu is fine; a synthetic voice that handles money, health or legal decisions needs a human process around it, and your own review of every script it can speak.
A text to speech API lets software turn written text into spoken audio without a person recording it. With Picasso IA you create a key in your account, send a request that names a voice model and its inputs, and the result comes back as an audio file you can download. The point of this one is range: the voice models of the catalog sit behind the same key, so you pick the voice per job instead of per account.
The text-to-speech category of the catalog holds 24 models, including elevenlabs/v3, google/gemini-3.1-flash-tts, inworld/tts-1.5-max, inworld/realtime-tts-1.5-max and xai/grok-text-to-speech. You do not need a separate account with each owner: the same key and the same credits cover them. The full catalog lists every model, and each model page shows the voices and settings it accepts.
Treat it like a password. It identifies your account and spends your credits, so anyone holding it can generate audio at your expense. Keep it out of public repositories, front-end code that visitors can inspect, screenshots and shared chats. If you suspect it has leaked, remove it from your account and create a new one, then update wherever your app stores it.
It costs credits, and the amount depends on the model and the settings you choose, the same way it does in the toolkit. This page does not quote numbers because any figure would go stale; the pricing page is where plans live, and new accounts get free credits. A practical habit is to test with one short paragraph first, so you learn the cost of a voice before sending a whole script.
You can generate the prompts for one. xai/grok-text-to-speech lists formats made for telephony alongside regular ones, and a phone menu is mostly short, clear sentences, which suit synthetic voices well. What you upload to your phone system, and which audio formats it accepts, depends on that system, so check its current requirements. See also AI phone greetings for the writing side.
The audio half, yes. inworld/realtime-tts-1.5-max is the model in the catalog described for conversational use, and it reads short replies with emotion tags. But a request still takes time to render and spends credits, and this page makes no promise about speed, so test your own flow in the toolkit before you design an experience that depends on instant audio.
Split them. Every model accepts a limited amount of text per run, and the limit differs from model to model, so a chapter goes through as several sections. Use the same model, voice and settings for every section so the narrator does not change midway, then join the files in your audio editor. elevenlabs/v3 has stability settings that help keep a voice consistent across a long project.
It depends on the model. google/gemini-3.1-flash-tts lists more than 70 language codes, xai/grok-text-to-speech covers around twenty, and the inworld models cover 15. Pick the model whose language list includes yours, set the language to match your text, and listen for accent and pronunciation before you ship. A voice that is excellent in one language can be merely acceptable in another.
Only a voice you own or a fictional character. Some models accept a custom voice by its identifier, which is useful for keeping your own brand voice consistent. Never use a real identifiable person's voice without that person's permission, and do not make audio that could pass for someone who did not say it. For the consent side of cloning, read AI voice cloning.
Yes, and it is the best first step. The toolkit runs the same catalog: pick a voice model, paste a paragraph of your real script, generate, and compare. Do it with two or three models, and you will know which voice to name in your first request. The comparison with ElevenLabs is useful reading if one provider is your starting point.
Before you wire anything up, hear the voices yourself: open the toolkit, paste a paragraph of your real script and compare two models. Questions about the API go to support.
Choose your language
