Music 1.0 is retiring: switch to /v1/music-router/generate in one line

Sume's Music 1.0 is retiring gradually. Its routes keep working and keep job.model = sume/music-1.0, but every request now resolves through the Music Router, so new code should call POST /v1/music-router/generate. The body is the same plus an optional model, and the price is unchanged at $0.125 per accepted generation.

Everything about Sume below is from the Music Router and Music 1.0 docs. The engine facts come from Google's Gemini API release notes, read on 2026-10-03.

What exactly is being retired?

The retiring surface is the product name, not the capability. POST /v1/music-1.0/generate and the model-run alias POST /v1/models/sume/music-1.0/runs still work, and jobs from them still report sume/music-1.0 as the model. The docs say each request now goes through the router with sume/music-auto as the engine selector, which today means Lyria 3.5. The docs do not give a shutdown date, so treat the retirement as a reason to move on your own schedule, not an emergency.

Google's release notes list lyria-3.5 as generally available on September 3, 2026, supporting text and image input and 44.1 kHz stereo audio. That matches what the Sume docs say the router picks today.

What changes in your request?

One thing: the URL. The prompt rules are identical. prompt is 1 to 5,000 characters, image_url is an optional public HTTPS image, and duration or duration_seconds are rejected, so you still steer length in the prompt with something like "a 2-minute track" or section markers. A non-empty negative_prompt still returns 400, so put exclusions in the positive prompt.

The new field is model. Omit it, or send sume/music-auto, to let Sume pick. Send lyria-3.5 or lyria-3-pro to pin an engine from the catalog. An unknown id fails with 400 model_not_found and a catalog_url.

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: music-router-001" \
  -d '{
    "model": "sume/music-auto",
    "prompt": "Warm lo-fi hip hop, 84 BPM, C minor. A 30-second track. Instrumental, no vocals."
  }'

How do you see which engine made a track?

job.model echoes what you asked for, so sume/music-auto stays sume/music-auto. The engine that ran is in job.request.routed_model, for example lyria-3.5, and the docs say that field is present on both the router and the Music 1.0 routes. Log it with every track, because it is the one field that tells you what produced a file if the default engine changes later.

Read the audio from result.artifacts[] where type is audio. result.lyrics carries the model-reported lyrics or section map when present; the docs call it model metadata, not an audio measurement.

What is a safe migration order?

Move one call site at a time and keep the idempotency keys you already use, so a retry mid-migration returns the original job instead of a second charge.

• Change the URL in one low-traffic job and compare the artifact and routed_model.
• Leave model off at first so behavior matches the old route.
• Pin an explicit id only if you need reproducibility, and expect to revisit it when the catalog changes.
• Update any code that reads job.model and expects sume/music-1.0.
• Remove the old route from your allow lists and docs once every call site has moved.