Pin lyria-3.5 or leave sume/music-auto? Read routed_model per job
sume/music-auto resolves to Lyria 3.5 today and can move without notice. When to pin lyria-3.5 on Sume and how job.request.routed_model records the engine.
Leave model unset (or sume/music-auto) when you want whatever engine Sume currently prefers, and pin lyria-3.5 when a client expects the same sound next month. Auto resolves to Lyria 3.5 today, but the Sume catalog notes that this mapping may move without notice. Either way the price is the fixed $0.125 per generation, so the choice is about repeatability, not cost.
What the router lists
GET /v1/music-router/models lists the routable ids. The Music Router docs name three: sume/music-auto (the default), lyria-3.5, and lyria-3-pro. All three accept text, optional image conditioning and up to 5,000 characters of prompt, and none supports a non-empty negative_prompt. None takes a duration field; you steer length in the prompt.
| Id | Routing | Notes |
|---|---|---|
| sume/music-auto | Auto | Default when model is omitted; resolves to lyria-3.5 today and may move |
| lyria-3.5 | Pass-through | Full-length structured songs up to a few minutes |
| lyria-3-pro | Pass-through | Explicit pass-through engine; same request body |
The two fields that prove which engine ran
job.model echoes the id you requested: if you sent sume/music-auto, it stays sume/music-auto. job.request.routed_model names the catalog engine that actually ran, for example lyria-3.5. This holds on the router and on the Music 1.0 routes alike.
So an auto request still leaves an audit trail. Store routed_model with the track. If a client later asks why a jingle sounds different from the version they approved, you can see whether the engine changed between the two jobs.
A decision rule
Pin when the output is a deliverable you may need to regenerate in the same style: a series theme, a sonic brand, a set of cutdowns made over weeks. Leave auto when you are exploring, since you benefit if the default engine improves and there is no continuity to protect.
Unknown ids fail with 400 model_not_found and a catalog_url, so a typo in a pinned id fails loudly instead of silently falling back to auto. Test your pinned id against the catalog once, then keep it in config.
What pinning does not give you
A pinned engine is not a seed. Music has no seed, temperature or guidance parameter, so the same prompt can return a different track. Pinning narrows the variation to one engine; it does not make output repeatable. Keep the accepted audio file itself as the master.
Cost of testing the choice
To compare auto against a pinned id on your own prompts, run the same five prompts on each: 10 generations, 10 x $0.125 = $1.25. Compare routed_model on each job; if it reads lyria-3.5 on all ten, auto and the pin currently agree, and the test shows that nothing differs today.
Repeat the check when you plan a large batch, since a mapping that may move without notice is worth one cheap look first.
Sources
Related posts
More in Models
- 500-image job on a preview model: Hy Image 3.5 availability, plan B
OpenRouter shows 83.39% availability over 3 days for Hy Image 3.5 Preview, one provider. At 500 images that is about 83 failures to retry. Plan B on Sume.
- Grep for nano-banana-2 in your code: those calls bill as 2.1
Retired Nano Banana 2 ids still run on Sume, as 2.1 at 10 cents at 1K. A grep-and-replace plan so logs, tests and cost sheets name the model that ran.
- Same Omni video twice: no seed, but a replay returns it
Omni Flash lists no temperature or seed, and Sume rejects seed on every video model. To repeat a clip, replay an idempotency key or use a video_url edit.
- Seedance 2.5 costs 1.53x Seedance 2.0 at 720p for 10 seconds
A 10 s 9:16 clip at 720p is $5.78 on Seedance 2.5 and $3.78 on Seedance 2.0 on Sume. What the extra $2.00 buys, and the ratio at 480p and 1080p.
Written by Sume