Sume Music Router: job.model vs routed_model, which engine ran

On Sume Music Router, job.model echoes the id you sent and request.routed_model names the engine that ran. Ids, price and the Music 1.0 route.

5 min readSume
All posts

How do you know which engine made a Sume music track? Read job.request.routed_model. The Music Router docs say job.model echoes the model id you requested, so sume/music-auto stays sume/music-auto, while routed_model names the catalog engine that ran, for example lyria-3.5.

Every Music Router model charges the same fixed Music price, $0.125 per audio generation, so the engine that runs does not change the bill.

The ids

The routable ids are sume/music-auto (the default), lyria-3.5 and lyria-3-pro. Omit model or send sume/music-auto and Sume picks the engine, which is Lyria 3.5 today. Pass an explicit id from GET /v1/music-router/models to pass through to that engine. An unknown id fails with 400 model_not_found and a catalog_url.

Music Router request and result fields (read 2026-10-03)
FieldWhereMeaning
modelRequestOptional; omitted means sume/music-auto
job.modelJobEchoes the id you requested
job.request.routed_modelJobThe catalog engine that ran, such as lyria-3.5
promptRequest1 to 5000 characters
image_urlRequestOptional public HTTPS image, or null to clear

The Music 1.0 route goes through the router

The Music 1.0 docs say that model is retiring gradually: its routes keep working and keep job.model = sume/music-1.0, but every request now resolves through the Music Router. routed_model is set on both the router and the Music 1.0 routes, so you can use it to audit either.

New integrations should call POST /v1/music-router/generate.

Why log routed_model

With sume/music-auto, the engine behind it can change when the catalog changes. If you store only job.model you lose that detail. Store both: the requested id for what you asked, and routed_model for what you got.

That matters when a client asks why two tracks sound different, or when you compare a prompt across engines. Pin lyria-3.5 or lyria-3-pro explicitly for a repeatable test.

Request limits that do not change

The body is the same as Music 1.0. duration and duration_seconds are rejected, and a non-empty negative_prompt is unsupported, so put exclusions in the positive prompt and steer length with wording such as "a 2-minute track" or section markers like [0:00-0:30] Intro.

Results arrive as a job. Read the audio artifact from result.artifacts[] where type is audio; result.lyrics carries a model-reported section map when present. For waiting and webhooks see Sume jobs and results. The catalog endpoint is covered in listing Music Router models.

A small audit habit

When you generate several tracks for one project, write one line per job to your own log with the job id, the requested model, routed_model, the prompt and the artifact URL. A table like that answers most later questions: which prompt produced the track the client liked, whether the engine changed between two batches, and what a re-run would cost. At a fixed $0.125 per generation, ten re-runs of a favourite prompt cost $1.25, so re-rolling a track is cheap enough to do rather than argue about.

Sources

Related posts

More in Models

All Models posts

Written by Sume