Lyria RealTime API: streaming music vs a Sume file job

Lyria RealTime is a streaming model: you hold a WebSocket open and steer instrumental music while it plays. Sume's docs describe no streaming music route. The Music Router takes a prompt, runs a job, and gives you a finished audio artifact to fetch.

Google's page calls Lyria RealTime experimental, and points to Lyria 3.5 for non-streaming generation. Sume's side is from its docs, read 2026-09-30.

What is Lyria RealTime?

Google describes it as a real-time, streaming music generation model for apps where users can interactively create, continuously steer and perform instrumental music. It uses a persistent, bidirectional, low-latency WebSocket connection, similar to the Live API.

How does Sume's music flow differ?

Does Sume have a WebSocket or event stream for music?

No. The jobs docs state there is no SSE or WebSocket transport on the Developer API today, and GET /v1/jobs/:id/events is a pull snapshot, not a stream. Submit with async, then poll status, or take a webhook; see music API wait.

Which Sume ids can I request?

Routable ids are sume/music-auto (default), lyria-3.5 and lyria-3-pro. result.lyrics carries the model-reported lyrics or section map when present. For length, see Lyria 3.5 song length.

When should I pick which?

If a person must change the music live, you need a streaming model and Google's API. If you need a track that ends up as a file in a video or a project, a job that returns one audio artifact is the simpler shape.