Suno old models retired, what now? Keep a music API stable

Keep a music integration stable by calling an id you control, logging which engine actually ran, and reading the vendor's retirement notes before your deadline. Suno replaced its model line with v6 on its blog dated 2026-09-09; for the retirement details, use Suno's own pages. Sume's docs show the same pattern on their side: Music 1.0 is retiring gradually, its routes keep working, and new integrations should call POST /v1/music-router/generate.

What does Sume do when a music model retires?

Sume's Music 1.0 is the worked example. The docs say its routes keep working and keep job.model = sume/music-1.0, but every request now resolves through the Music Router. So an old integration does not break; it just runs through the router while the docs steer new code to the router directly.

How do I make a music client resilient?

Three habits cover most of it. Log job.model and job.request.routed_model for every job so an engine change shows up in your data. Decide whether you want sume/music-auto, which routes to Lyria 3.5 today, or a pinned id such as lyria-3.5. And read GET /v1/music-router/models at deploy time rather than hard-coding a list. An unknown id fails with 400 model_not_found and a catalog_url, a clear signal that your id list is stale.

When should I migrate to the router?

Now, for anything new. The Music 1.0 docs say new integrations should call the router. Existing Music 1.0 callers can keep working, but a quick switch to the router endpoint removes the surprise of reading sume/music-1.0 on jobs that are really routed. Test with your real prompts, since output for a prompt can differ between engines.

Does a retirement change what I pay?

Not for Sume's music routes as documented: the Music Router says every model charges the fixed Music price per audio generation, and Music 1.0 lists a fixed $0.125 per accepted generation. Pricing is one less thing to re-check when an engine id changes, though you should still read the docs at each release.

What is the short version?

Call the router, log job.model and job.request.routed_model, pin an id if engine stability matters, and read the catalog at deploy time. Old Music 1.0 routes keep working, but the docs steer new code to POST /v1/music-router/generate. Retest your prompts whenever the engine behind an id changes.