Voice prompting, explained: how AI voice design actually works

Until 2026 the only way to get a custom AI voice was voice cloning · record a real human, upload the sample, and the model produces a synthetic copy of that voice. It works, but it imposes constraints: you need a consented speaker, you need clean audio, and the voice you get is the voice you recorded.

Voice prompting flips the constraint. You describe a voice in plain language, "warm raspy elderly woman, low-pitched, magnetic, slight breathy tremor", and the model conjures a fresh timbre from the description. There is no source speaker; the voice did not exist before the API call, and the legal posture for using it is "this is synthetic, not anyone in particular".

This post explains what voice prompting is, why it ships on Hakim Mulhim v3, how the three-axis prompt structure works in practice, and where voice prompting fits relative to the existing voice cloning surface.

If you only have two minutes, the headline is: voice prompting is a fundamentally different way to create a voice, gated to the Mulhim tier (the most-capable model in our family), and it pairs with our existing voice-cloning + non-verbal-tag surfaces to give product teams a complete creative toolbox for generative voice.

What voice prompting is, exactly

Voice prompting is the generation of a synthetic vocal timbre from a natural language description. You write text like:

A middle-aged male broadcaster, low-pitched and magnetic with a slight rasp, delivering a passionate news bulletin.

You send that text to POST /v1/audio/voices/design. The API returns audio: a short sample that demonstrates the voice the model created for your prompt. Optionally, you save the voice to your library so subsequent POST /v1/audio/speech calls reuse that timbre exactly.

The mental model that lands fastest with developers is "Midjourney for voice". Text in, voice out. No speaker. No audio reference. No consent paperwork. You described a voice, and the model handed you one.

curl https://api.tryhakim.ai/v1/audio/voices/design \
  -H "Authorization: Bearer $HAKIM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "description": "warm raspy elderly woman, low-pitched, magnetic, slight breathy tremor",
    "sample_text": "Welcome. This is a quick sample of the voice you described.",
    "save_as_voice": { "name": "Broadcaster Demo" }
  }' \
  | jq '.voice.id'
# "voi_01HX3K..."

Three things the curl above demonstrates and the prose above didn't:

The prompt and the audio sample are separate fields. description is the voice prompt; sample_text is the script the model speaks in the returned audio so you can hear what the voice sounds like. Splitting them means you evaluate "does this voice land?" on whatever sentence is closest to your use case · a podcast intro, a news bulletin, a product disclaimer.
The save step is optional. Calls without save_as_voice return only the rendered sample · useful for prompt iteration before you've decided which voice is the one. The voice library doesn't get cluttered with discarded drafts unless you ask it to.
The saved voice is a regular Voice row. Same shape as preset voices and cloned voices · same id format, same voice field in POST /v1/audio/speech calls, same playground picker, same audit log. The design path is a creation surface for the existing catalogue, not a parallel system.

Why this needs a premium tier

Voice generation is fundamentally more expensive to run than playback of an existing voice. The Mulhim tier on which voice prompting ships carries a larger model with a richer prior over vocal timbres, longer context for the prompt itself (so adjectives stack predictably), and the additional decoder state needed to maintain coherence across an entire designed voice rather than just reading the next syllable.

That is why voice prompting is gated to Hakim Mulhim v3, the premium tier of the Hakim TTS family. The Saree' speed tier and Faseeh quality tier can both read text · neither can design a voice from text. Sending a voice_prompt field to Saree' is silently stripped at the edge (you get the prose without the overlay, with a soft warning in the x-hakim-warnings response header); calling POST /v1/audio/voices/design with model: "hakim-fast-v1" is rejected with a 422 because there's no graceful fallback when the prompt is the request.

For a longer treatment of the three-tier ladder · Saree' / Faseeh / Mulhim · see Introducing the Hakim TTS family and the Models guide.

How voice prompting differs from text LLM prompting

The mechanics rhyme · text in, structured output out · but the loop you run around it is different in shape:

Text LLMs reward precision. "Write a 200-word summary of this article in the tone of a Reuters business correspondent" lands with high consistency because the model is steering toward a single correct response in a well-explored register.
Voice prompting rewards iteration. Two calls with the same description produce similar-but-distinct voices. The model isn't aiming for a "correct" timbre · there isn't one. It's drawing a voice from a space of voices consistent with your description, and the space is broad on purpose. Run the prompt three times, pick the one that lands, save.

This has practical consequences for product design:

Don't expect determinism. A test that asserts byte-for-byte equality between two calls with the same prompt will fail. Assert on the prompt + the saved voice.id, not on the rendered audio bytes.
Expose an iteration loop to your users. "Generate", "Listen", "Generate again", "Save when you like it" is the right UX shape. Three generates takes ~30 s end-to-end on Mulhim and tends to land on a keeper.
Treat the prompt as canonical, the audio as a sample. Two team members designing the same voice should iterate on the same prompt, not pass audio files back and forth. The prompt is the artefact; the audio is a preview.

The three-axis prompt structure

In practice, the most consistent results come from prompts that explicitly cover three dimensions:

Axis	What it controls	Example
Identity	Gender, age, role	"middle-aged male broadcaster"
Texture	Pitch, timbre, grain, pacing	"low-pitched, magnetic, slight rasp"
Scenario	Emotion, register, performance	"passionate news bulletin"

You can write all three into a single prose paragraph; there is no required syntax, and the playground's voice-prompt drawer reflects that with a three-pane composer that joins the fields with commas before sending. Both English and Arabic prompts are accepted.

A complete prompt in 30 seconds:

A middle-aged male broadcaster, low-pitched and magnetic with a slight rasp, delivering a passionate news bulletin.

Now consider what each axis adds:

Without identity ("Low-pitched and magnetic with a slight rasp, delivering a passionate news bulletin.") · the model picks a gender + age + role; you may get a voice that's correct for the texture and scenario but mismatched for the application you had in mind.
Without texture ("A middle-aged male broadcaster delivering a passionate news bulletin.") · you get a generic-broadcaster voice. Functional but forgettable. Texture is what makes a voice memorable.
Without scenario ("A middle-aged male broadcaster, low-pitched and magnetic with a slight rasp.") · the voice has the right identity and the right texture, but the prosody on long-form output drifts because the model has no register cue.

All three together produces consistent, reusable voices. Two axes can work; one axis rarely does.

For deeper guidance on writing voice prompts that land, see the voice prompt engineering playbook, which annotates twelve example prompts and documents the anti-patterns that fight the model.

A complete end-to-end example

Here is the loop a product team typically runs when they're designing a new brand voice:

Sketch the prompt. Three axes. Write the first draft fast; don't overthink it.
Generate three times. Same prompt, three calls. Listen to each. Voice prompting is non-deterministic by design; the third generate is often the one that lands.
Save the winner. Add save_as_voice to the call that produced the keeper. The API persists the voice; you get back a slim DTO with the voice.id.
Use the voice on every subsequent speech call. Same wire shape as a preset voice or a cloned voice.

import { HakimClient } from '@hakim/node';

const hakim = new HakimClient({ apiKey: process.env.HAKIM_API_KEY });

// 1 + 2 · Sketch the prompt; generate three samples.
const description =
  'A warm female podcast host in her late 30s, smooth low-pitched timbre, natural cadence, intimate podcast intro register.';
const sampleText = 'Welcome back, listeners. Today we have something special.';

const candidates = await Promise.all(
  Array.from({ length: 3 }, () =>
    hakim.audio.voices.design({ description, sample_text: sampleText }),
  ),
);
// Hand the three previews to a UI; the operator picks one.

// 3 · Save the winner.
const saved = await hakim.audio.voices.design({
  description,
  sample_text: sampleText,
  save_as_voice: { name: 'Sahibi Podcast Host', gender: 'female' },
});
const voiceId = saved.voice!.id;

// 4 · Use the voice for production speech generation.
const { stream } = await hakim.audio.speech.stream({
  model: 'hakim-v3', // Mulhim · needed for non-verbal tags below; speech itself works on any tier with this voice.
  input: 'Welcome back. [breath] Today we are talking about something special.',
  voice: voiceId,
  response_format: 'mp3',
  stream: true,
});

The same flow on the playground takes about five minutes of clicking · the voice design guide in /docs walks through the UI version step by step.

Where voice prompting fits in a product

The five product surfaces where voice prompting tends to land hardest, ordered by how much value it adds over the alternatives:

Brand voices for early-stage products. A team that doesn't have a hired voice talent yet but needs a consistent brand voice across audio notifications, in-product help, marketing reels. Voice prompting compresses the "find a voice actor, agree on rate, schedule recording, get sample, iterate" loop into a five-minute exercise on the playground.
Character voices for games and interactive media. A studio shipping a game with twenty named characters can't realistically book twenty voice actors. Voice prompting per character produces twenty distinct, consistent timbres that the studio owns outright.
Localised brand voices across dialects. Need the same brand personality in MSA, Khaleeji, Egyptian, and Levantine? Write the same prompt and add a dialect hint per language. The brand timbre stays consistent; the dialect shifts.
A/B testing voice fit. Marketing teams that want to know whether audiences respond better to a warm narrator or an authoritative one can ship both variants at near-zero production cost.
Filling gaps in the preset catalogue. Need a "young Bedouin storyteller with a desert wind in their voice" and we don't ship a preset that matches? Design it. The cost is one prompt.

Voice cloning still wins for "we need this specific person's voice", which covers founder voices, hired narrators, dubbed actors, and any production where the speaker is themselves the brand. We treat the two surfaces as complementary; voice design vs voice cloning walks through the decision rules in detail.

What voice prompting cannot do

Three constraints worth knowing about up front:

It cannot replicate a real person you describe. "Voice that sounds like Morgan Freeman" gets flagged for manual review and held in pending_manual_review until a human at Hakim approves or rejects. Even when approved, the result is a voice influenced by the description's general texture · not Morgan Freeman. To get a specific real person's voice, use voice cloning with proper consent.
It cannot reuse a voice you heard somewhere else. There is no "describe a voice you heard yesterday" mode; the model designs from text only. If you have a sample of a voice you want to recreate, that is voice cloning, not voice prompting.
It cannot guarantee byte-for-byte reruns. Two calls with the same prompt produce similar-but-distinct voices. To pin a voice down, save it · the voice.id is the canonical reference, and every subsequent speech call with that id renders the same timbre.

Pricing posture

Voice prompting is a Mulhim tier capability. The Mulhim tier is on premium pricing (per-character rate higher than Saree' v1.3, lower than full voice cloning per-minute rates). The design endpoint itself uses the existing voice clone rate-limit bucket since each design call is structurally a small training pass.

Full pricing schedule on /pricing; the per-tier rate-limit budget is documented in the rate-limits guide.

Try it

The playground at /app/playground/tts opens on Mulhim v3 by default and preloads a worked example so you can hit Generate and hear the model immediately. Open the voice-design drawer to see a populated three-axis prompt that pairs with the script in the composer; edit either to start making it yours.

Two further reads:

Writing a voice prompt that lands: a playbook · twelve annotated examples + anti-patterns + the iteration loop in detail.
Voice design vs voice cloning: when to pick which · decision rules, consent posture, and a comparison matrix.

The reference docs:

Voice design guide · the design endpoint, prompt structure, save flow, tier gating.
Models guide · the full three-tier ladder, capability matrix, graceful-strip behaviour.
API reference → design endpoint · request and response schema, error codes, rate limits.

Voice prompting is the most generative capability we've ever shipped. It works best when you treat the prompt as a first-class artefact, the audio as a preview, and the iteration loop as the unit of design. Pair it with non-verbal tags on the speech endpoint and a designed voice carries narration that holds up over twenty minutes; pair it with the voice cloning surface and a single product can ship cloned founder voices and synthetic brand voices side by side.

Voice is the next interface. Voice prompting is how you stop renting other people's voices and start designing your own.