Lyria 3.5 costs $0.08 a song at Google; Sume charges $0.125

Google lists Lyria 3.5 at $0.08 per song in the Gemini API. Sume's Music Router charges a fixed $0.125 per accepted generation, so a hundred songs cost $8.00 direct from Google and $12.50 through Sume, a difference of $4.50. The rest of this post shows where each number comes from and what the extra money buys.

Both numbers are per generation, not per second. Neither changes with prompt length, so the only thing that moves your bill is how many songs you generate.

What Google lists

The Gemini API pricing page lists three Lyria rows on 2026-10-05. The music generation guide says lyria-3.5 makes full songs of 'a couple of minutes (controllable using prompt)' and lyria-3-clip-preview makes 30-second clips.

What Sume charges

The Music 1.0 docs state the price plainly: a fixed $0.125 USD for each accepted generation, regardless of prompt length or optional image conditioning. The Music Router charges that same fixed Music price for every model it routes, and its catalog lists the provider list price per model for reference.

Sume's pricing policy is provider list times 1.25, plus a 5.5% platform fee on customer spend. Note that $0.08 x 1.25 is $0.10, not $0.125. The $0.125 figure is Sume's own fixed Music price, derived from Sume's provider list, and it is not simply Google's Gemini API price with a markup. I could not reconcile the two lists from public pages, so compare the final numbers rather than the multiplier.

What you get for the difference

Calling Google directly means you hold a Gemini API key, poll Google's operation, and store the audio yourself. Through Sume you send one request, poll the shared job endpoints, and read a hosted audio artifact from result.artifacts[]. Sume's docs say raw provider URLs are not public outputs, and results come back on Sume media URLs.

The router also lets you leave model out. sume/music-auto picks the engine, Lyria 3.5 today, and job.request.routed_model tells you which engine ran. You can pin lyria-3.5 explicitly when you want repeatability. If Sume later adds an engine, existing integrations keep working.

Constraints that apply on both sides

A minimal call follows the constraints below.

• Length is prompt-driven. Sume rejects duration and duration_seconds; write 'a 2-minute track' or section markers like [0:00-0:30] Intro: ... in the prompt.
• No negative prompts on Sume: a non-empty negative_prompt returns HTTP 400 with negative_prompt_unsupported. Put exclusions in the positive prompt, for example 'Instrumental, no vocals'.
• Google's guide says Lyria is single-turn with no iterative editing, and that outputs vary across identical calls. Budget for regenerating, not editing.

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."
  }'

Which to pick

If you generate thousands of songs a month and already run Google infrastructure, the $0.045 gap is real money and direct is cheaper. If you want music in the same job, billing and artifact flow as your video and voice calls, the fixed $0.125 is easy to budget: it is one number, priced per accepted generation. Check the live catalog with GET /v1/music-router/models before committing to volume.