Music 1.0 to Music Router: what changes in your integration
Sume is retiring Music 1.0 gradually; every request already resolves through the Music Router. New code should call /v1/music-router/generate. What changes.

Music 1.0 is being retired gradually on Sume, and its routes keep working. Every request already resolves through the Music Router (sume/music-auto), so the migration is small: for new code, POST to /v1/music-router/generate and optionally send a model id. The body, the price ($0.125) and the job flow stay the same.
What stays the same
The Music Router body is the same as for Music 1.0, plus an optional model field. The prompt is required, 1 to 5,000 characters. image_url is optional, a public HTTPS image, or null to clear it. A non-empty negative_prompt is not supported: omit it or send an empty string. Sume rejects duration and duration_seconds, so you steer length in the prompt.
Old routes keep working and keep job.model set to sume/music-1.0, so existing dashboards that group by model do not change under you.
| Item | Music 1.0 | Music Router |
|---|---|---|
| Invoke URL | POST /v1/music-1.0/generate | POST /v1/music-router/generate |
| Public model id | sume/music-1.0 | sume/music-router |
| Engine choice | Resolved by the router | model field: sume/music-auto, lyria-3.5, lyria-3-pro |
| Price per generation | $0.125 | Fixed Music price for every router model, per docs |
| Catalog | None | GET /v1/music-router/models |
What changes
First, you can pin an engine. If you omit model or send sume/music-auto, Sume picks the engine (Lyria 3.5 today). Unknown ids fail with 400 model_not_found and a catalog_url. Second, job.model echoes the id you requested, and job.request.routed_model names the engine that actually ran, on both the router and the Music 1.0 routes. Log that field, because auto can move.
Third, the model-run alias for Music 1.0 (POST /v1/models/sume/music-1.0/runs) is the legacy path; new work should use the router URL.
A safe cutover
Change the URL and nothing else, and run a few generations. Compare the audio artifact in result.artifacts (type audio) and read result.lyrics when it is present; it is model-reported metadata, not a measurement of the audio. Keep your Idempotency-Key scheme the same so a retry during the cutover cannot create a second charge.
Once the router path is stable, decide whether to pin lyria-3.5 or leave auto. The related post on pinning covers that choice.
Checklist
Switch the URL. Log job.request.routed_model. Keep Idempotency-Key per request. Do not send duration, duration_seconds, or a non-empty negative_prompt. Decide whether to pin an engine. Test with one generation ($0.125) before you move traffic.
Nothing in the docs requires you to move on a deadline; the retirement is described as gradual, with old routes continuing to work. The recommendation is for new integrations.
Sources
Related posts
More in Developers
- Music API 400s: duration and negative_prompt, and the fix
Sume's Music Router returns 400 if you send duration, duration_seconds or a non-empty negative_prompt. The fix for each, and a request that passes validation.
- Music prompt limits: 1-5000 characters and no duration field
Sume's Music Router takes a 1 to 5000 character prompt and rejects duration. How to set length and sections in the prompt text, with a request.
- Nano Banana 2.1 4K batch: handle 200 and 202, reuse the key
A 4K Nano Banana 2.1 call can return 200 with the image or 202 with a job. A short Python handler, the retry rule, and what 4K costs: $0.20 per image on Sume.
- Nano Banana 2.1 PDF and video grounding: Sume takes image URLs
fal's Nano Banana 2.1 Edit page lists video and PDF grounding. Sume's Image API takes public HTTPS image URLs only, so render pages first.
Written by Sume