Music prompt rejected? Revise the flagged part, keep the brief

If a Sume music request is rejected on policy, change only the content that was flagged and keep the rest of the musical brief: tempo, key, instruments, and the arc. Sume's Music 1.0 page says to revise the flagged content while retaining the brief, to retry only within the budget you authorized, and not to strip the request down to a generic bed.

This matters more now that Lyria 3.5 is generally available. Google's Gemini API changelog (read 2026-10-02) lists full-length song generation from text and image inputs on 2026-09-03, so a long, specific brief is the normal request, and one flagged phrase should not cost you the other six details.

Is a policy rejection the same as a 400 validation error?

No. Two different things can stop a music job. A validation error means the request body broke a rule, and the fix is to change the field. A policy rejection means the content of the prompt was refused, and the fix is to rewrite that content. The Music Router and Music 1.0 share the same body and the same rules, so the table applies to both.

What should I keep when I rewrite?

Keep the parts that make the track yours. The docs describe a seven-axis brief: emotion, genre, tempo as a number, key and mode, two to four instruments with texture, an arc with one named moment, and era or production. Those axes are creative direction, not guaranteed settings, so listen to the result.

Change only the clause that triggered the refusal. If you cannot tell which clause it was, remove one candidate at a time rather than rewriting the whole prompt into something safe and generic. A stripped prompt will pass, but it throws away the reason you wrote a brief in the first place.

How do I retry without paying twice?

Send the same Idempotency-Key only when you resend the identical request; a revised prompt is a new request and needs a new key. Sume's job pages say not to resubmit a paid request just because a local process timed out, so poll the job first. Check the status before you decide a request failed.

Music is a fixed price per accepted generation: $0.125 on the Music 1.0 page. Set your own ceiling on how many revisions a track gets, for example three, then hand the brief to a person.

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: score-rev2-001" \
  -d '{"prompt": "Hushed neo-soul nocturne, 72 BPM, D minor. Rhodes, sub bass, brushed snare. Instrumental, no vocals."}'

What if the router picks an engine I did not expect?

Omit model and Sume sends the job to sume/music-auto, which routes to Lyria 3.5 today. The job's request.routed_model names the engine that ran. Read it before you blame the prompt.

What should I log for each revision?

Keep a short log per track: the brief, the version number, the error or reason you saw, and what you changed. After a few tracks the log shows which kinds of phrasing get refused, and you can write the first version of the next brief to avoid them. It also keeps retries inside your cap, because each attempt is written down.