Text to Audio LLM: What It Can and Cannot Do

Short answer: an LLM writes the instructions, not the sound

When people search for a text to audio llm, they often picture one model that reads a sentence and returns a sound file. Large language models do not do that. They read and write text. Sound comes from a separate model built for audio, which takes a text description as input.

That split is useful, because the quality of the description matters a great deal. A vague request such as "relaxing music" gives an audio model little to work with. A specific one that names genre, tempo, instruments, mood, structure and length gives it much more. Writing that specific description at volume, in a consistent format, is a good job for a language model.

This site offers exactly that half: an OpenAI-compatible text API. It has no audio generation, no embeddings and no fine-tuning. If you need the sound itself, you pair it with a tool that makes sound, and use this endpoint as the writing step in front of it. We are not affiliated with any audio vendor, so check each tool's own documentation for its input rules.

Where a text model helps in an audio pipeline

The tasks that fit are the ones where the output is words:

• Prompt writing. Turn a rough idea into a detailed description with genre, tempo, instrumentation and mood.
• Lyrics and scripts. Verses and a chorus for a song, or a narration script for a podcast intro or an audiobook chapter.
• Variations. Ten alternative prompts from one concept, so you can audition several directions.
• Metadata. Titles, descriptions, tags and track notes once the audio exists.
• Revision. Rewriting a prompt after a result missed the mark, using your notes on what went wrong.

The model here is tuned to answer without content refusals for lawful adult use, which matters for fiction-heavy audio such as dark storytelling, horror dramas or mature game dialogue, where a stricter model may decline a perfectly reasonable request. The one hard line is that nothing involving minors in a sexual context is allowed, and the keys are not for that.

Our video prompt page covers the same idea for video tools; the pattern of writing a structured description first and handing it to a generator second carries across media.

A working example: one idea in, one structured prompt out

The most reliable way to feed a downstream tool is structured output. JSON mode (response_format: {"type":"json_object"}) makes the model return a JSON object, so your script can read named fields instead of parsing paragraphs. Here is a Python script using the OpenAI SDK against this endpoint.

Copyimport json, os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.stableaudio.top/v1",
    api_key=os.environ["UNCENSORED_API_KEY"],
)

system = (
    "You write prompts for text-to-audio tools. Return a JSON object with keys: "
    "genre, tempo_bpm, instruments (list), mood, structure, duration_seconds, prompt. "
    "The prompt field is one paragraph, no more than 60 words."
)

resp = client.chat.completions.create(
    model="uncensored",
    messages=[
        {"role": "system", "content": system},
        {"role": "user", "content": "A tense chase scene in a rain-soaked neon city."},
    ],
    response_format={"type": "json_object"},
    temperature=0.8,
)

spec = json.loads(resp.choices[0].message.content)
print(spec["prompt"])

Keep the word JSON in your system message and list the keys you want. The model then has a clear target. Validate the result before sending it onward: check that tempo_bpm is a number and that instruments is a list, and retry once if not.

The same request in curl, handy for a quick check, looks like this:

Copycurl https://api.stableaudio.top/v1/chat/completions \
  -H "Authorization: Bearer $UNCENSORED_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "response_format": {"type": "json_object"},
    "messages": [
      {"role": "system", "content": "Return JSON with keys mood and prompt for a text-to-audio tool."},
      {"role": "user", "content": "A quiet morning in a mountain village."}
    ]
  }'

Writing prompts the audio model can use

A language model will write whatever shape of prompt you ask for, so the real work is deciding the shape. A few rules hold up across most audio tools.

Say what the tool wants, in the order it wants it

Read the audio tool's documentation and copy its vocabulary. If it responds to bracketed section tags or to a style line of comma-separated descriptors, put an example of that exact format in your system message. Models imitate examples closely.

Give concrete nouns

"Sparse piano, brushed drums, upright bass, vinyl crackle" beats "nice jazzy feel". Tell the model to name instruments, tempo range and texture, and to avoid filler adjectives.

Set length limits in the instruction

Many audio tools cap prompt length. Put the cap in the system message ("no more than 60 words") and enforce it in code as well. Models drift on word counts, so truncate or retry when the check fails.

Keep a feedback loop

After you hear a result, feed your note back: "Too busy in the second half, drums too loud, keep the key." A second call can revise the earlier prompt with that note in context. The 100,000-token window means you can carry a long history of attempts if you want the model to learn what you keep rejecting.

Chaining the model to an audio generator

The glue code is short. Generate the spec, validate it, then pass the prompt field to whichever audio service you use. The audio call is shown as a placeholder because each vendor's interface differs; take its parameters from their documentation.

Copydef make_spec(idea: str) -> dict:
    r = client.chat.completions.create(
        model="uncensored",
        messages=[
            {"role": "system", "content": system},
            {"role": "user", "content": idea},
        ],
        response_format={"type": "json_object"},
    )
    return json.loads(r.choices[0].message.content)

ideas = ["Lo-fi study beat", "Epic orchestral trailer hit", "Haunted music box"]
for idea in ideas:
    spec = make_spec(idea)
    # send spec["prompt"] to your audio generator here
    print(idea, "->", spec["prompt"][:80])

If you run this over a list in parallel, mind the limits. A full key allows 8 concurrent requests and 300 per minute; the trial key allows 2 and 60. A 429 with concurrency means too many at once, rate_limited means too many per minute, and a Retry-After: 5 header means wait five seconds and try again. A small thread pool sized to your limit, plus a retry, is enough.

The API docs list the supported parameters, including temperature, top_p, stop and seed. A fixed seed helps when you want repeatable prompts while you tune the system message.

Lyrics, narration and metadata at scale

Prompts are only one kind of text an audio project needs. Once the pipeline runs, the same endpoint can write the other pieces around it, and you can reuse the client object from the earlier script.

Narration scripts

For spoken audio, ask for a script with stage directions in a fixed notation, such as a pause marker between paragraphs and a note when the speaker should slow down. Tell the model the target reading time. A common rule of thumb is that a narrator reads somewhere around 150 words per minute, so a two-minute piece needs roughly 300 words; ask for that figure and then count the words in code.

Lyrics with a fixed structure

Ask for named sections, a rhyme scheme and a syllable range per line. A model follows "four lines, ABAB, eight to ten syllables each" much better than "a nice rhyming verse". Run a check in code afterwards and ask for a rewrite of only the section that failed.

Titles, tags and descriptions

After the audio exists, send the final prompt and lyrics back to the model and ask for three title options, five tags and a two-sentence description. This is cheap, repetitive work that suits a text model well.

Stories and games

Fiction audio, such as a horror serial, an interactive story or the dialogue for a game, often includes dark or mature themes. The model is tuned to answer without content refusals for lawful adult use, so a request that fits the genre is not met with a lecture. The rule against sexual content involving minors stays absolute.

If you stream long scripts to a screen, set stream: true and read the chunks as they arrive; usage is reported at the end of the stream.

What it costs to write a thousand prompts

Text is cheap compared with the audio step. The rate is $0.15 per 1M input tokens and $0.50 per 1M output tokens, billed from prepaid credit with no subscription.

Suppose each request sends about 600 tokens (system message plus idea) and gets back about 300 tokens of JSON. For 1,000 requests:

• Input: 600,000 tokens x $0.15 / 1M = $0.09
• Output: 300,000 tokens x $0.50 / 1M = $0.15
• Total: $0.24

So a thousand finished prompts cost about twenty-four cents, and requests that fail or are refused are not charged. A new account can claim $0.50 of trial credit with one click on the key page, no card, valid for 7 days, which is roughly two thousand prompts at the size above. After that, top-ups start at $20; see pricing for the bonus tiers and payment options. Prompts are not used for training.

More guides

• LangChain and LangGraph Without an API Key
• Uncensored Text API for Video Prompts