Skip to main content
every muga prompt is three parts: a [tone], an optional <event>, and your words. hear one first:

anatomy of a prompt

every prompt is these three parts.

the 3 rules that prevent most problems

  1. start every paragraph with one [tone]. it must be the first token. no tone means flat delivery. one tone per paragraph; a blank line starts a new one.
  2. romanised hinglish only. latin script. devanagari was never in training, so it comes out as garbage.
  3. match the event to the tone. laughs belong to high, positive tones; sighs to low, reflective ones. a <laugh> in a [sad] line fights the model (matrix below).
everything else is detail.
saying numbers, IDs and dates. silk normalizes your text before speaking it, so amounts, dates, times and percentages are read out for you. anything that must be read digit by digit, like an OTP or an order number, has to be wrapped in double quotes. see numbers, IDs & dates.

tones

six moods. press play on any one, and copy the prompt to try it yourself. no tag means the default tone ([neutral] if nothing is set). the tone covers the whole paragraph.

inline events

drop these in the text, where you want the sound: rules:
  • lowercase, angle brackets, no inner spaces: <laugh>, never <Laugh> or < laugh >. get it wrong and it’s spoken as a word.
  • one space on each side. never mid-word.
  • position matters: <laugh> kya baat hai lands differently from kya baat hai <laugh>.
  • stack at most two (<laugh> <laugh>) for a harder laugh. three or more gets unstable.

tone × event compatibility

the rule that trips people up most. laughs ride high tones; sighs ride low ones. mix contradictory pairs (a laugh in grief, a sigh in a hype shout) and the model has almost no training to fall back on, so it fights itself.

length and chunking

muga is built for 2 to 40 second utterances.
  • 2 to 30s: the sweet spot. one to three sentences.
  • 30 to 40s: fine for a short monologue.
  • 40s+: split it. past 40s, tone drifts and you get repeats or cutoffs.
to chunk: break at sentence boundaries, keep each piece under 30s, re-state the tone on each piece, and send them as separate calls.

recipes

using muga in a voice agent

muga sets tone per paragraph, so it needs the whole tagged utterance up front. it can’t tag half a sentence.
  1. buffer the tokens streaming out of your LLM until the turn is complete.
  2. you now have one fully tagged utterance.
  3. send it to the TTS endpoint and stream the audio back to the call.
never forward partial LLM output. a fragment like [hap or a half-placed <lau is spoken literally, not rejected, so validate before production. need token-by-token low latency instead? use mulberry. for transport, see streaming and the pipecat integration.

system prompt for your agent’s LLM

hand this to the LLM that writes muga’s lines. tune the wording, not the tags.

pre-flight checklist

before you ship a prompt, six yes/no checks:
  1. starts with exactly one [tone]?
  2. latin script only, no devanagari?
  3. every event lowercase, spaces around it, none mid-word?
  4. event matches the tone (laugh = high, sigh = low)?
  5. under ~40s (1 to 3 sentences)?
  6. in an agent: full utterance buffered before sending?

troubleshooting

faq

the selected default tone, or [neutral] if none is set.
not inside a paragraph. start a new paragraph (a blank line) with a new [tone].
it doesn’t match the tone. laughs need high, positive tones; sighs need low ones. see the matrix.
no. it saw zero devanagari in training. मैं ठीक हूँ produces garbage, romanise it: main theek hoon.
2 to 40 seconds. past ~40s, split it into chunks of 30s or less.