Lyria 3.5 is single-turn: what that means for Sume Music retries

Lyria music generation is single-turn: you cannot edit a track in conversation, and the same prompt can return different results. On Sume that translates into a simple rule: every retry is a new paid take, and nothing in the Music request pins the output.

Google's Gemini API music page (read 2026-10-10) states 'no iterative editing' and says results may vary between calls, even with the same prompt. Sume's Music 1.0 page adds the other half: the request has no seed, temperature, guidance or duration parameter.

What you can and cannot control

Sume's Music request takes prompt (1 to 5,000 characters), an optional public HTTPS image_url, optional metadata, and the usual mode, webhook_url and wait_timeout_seconds. A non-empty negative_prompt returns HTTP 400 with public_reason=negative_prompt_unsupported, so exclusions belong in the positive prompt, for example 'Instrumental, no vocals.'

Plan retries as takes, not edits

Because the price is a fixed $0.125 per accepted generation, you can budget a take count up front. Three takes cost $0.375. The retry loop that works is to change the brief deliberately: the Music page lists seven axes (emotion, genre, tempo as a number, key and mode, instruments with texture, an arc with one named moment, era and production) and notes that these are creative directions rather than guaranteed values.

When a take is close, keep the brief and change only one axis. When a take is rejected by policy, change the flagged content but keep the musical brief.

Make retries safe on the wire

Send an Idempotency-Key per intended take so a network retry does not create a second paid job, and a fresh key for each new take. Poll GET /v1/jobs/{id}/status and read the result when it completes; the Music page says the audio artifact sits in result.artifacts[] with type equal to audio. The 30-second wait limit on sync mode bounds the HTTP call, not the job, so submit async or use a webhook for longer waits (Jobs and results).

curl -X POST https://api.sume.com/v1/music-router/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: take-001" \
  -d '{"model":"sume/music-auto","prompt":"Warm lo-fi, 84 BPM, C minor. Rhodes, brushed drums. A 30-second track. Instrumental, no vocals."}'

What to do when you need a small change

Single-turn also means there is no 'make the drums quieter' follow-up. The practical substitute is the audio toolchain around the track rather than another generation. If you only need a different length, split the file with timeline audio. If you need the music quieter under speech, set soundtrack.gain_db or duck_db in a Timeline render instead of regenerating; the Timeline page lists gain_db, loop, fade_out_seconds up to 10 and duck_db from 0 to 20 for a bed.

Only changes to the music itself, such as a different instrument or a different arc, justify another take. Treat those as a new brief and a new $0.125 charge, and keep the earlier file in case the new take is worse. Because the outputs are not reproducible, the earlier file is the only copy of that version you will ever have.

Choosing between takes

Listen to every take before you build on it; the model-reported lyrics field is not an audio measurement. If you need to compare engines on one brief, the blind test post shows the router ids. Keep the winner's file and prompt together, because you cannot regenerate it.