Lyria 3.5 Is an $0.08 Full-Song API—but Its Java Samples Still Name Lyria 3

The decision is prototype, canary, wait or reject

Prototype Lyria 3.5 when a team needs original background music, campaign variations, game or product audio and can review every result. Canary it in production only after model-ID, response-parser, rights, disclosure, data and quality gates pass. Wait if the workflow requires iterative editing, stems, deterministic regeneration, independent quality evidence or a negotiated rights position. Reject automatic publication of generated tracks without a human and provenance record.

This is not a “best AI music model” verdict. It is a release-day contract audit for one managed API. Google has exposed a surprisingly inexpensive full-song primitive, but production readiness is the behavior of the whole selection, review, export and distribution system.

The release moved Lyria from clips to complete tracks

Google published the Lyria 3.5 announcement on September 4, 2026. The API guide, updated the same day, separates a legacy-style 30-second Clip model from Lyria 3.5 full songs. The DeepMind page describes tracks up to three minutes; the API guide uses the softer contract “a couple of minutes” and says duration is influenced by prompts or timestamps.

That wording difference is operationally important. “Up to three minutes” is a product capability statement, not a duration service level. Measure actual decoded duration and reject or regenerate outside the downstream slot’s tolerance.

The original finding is a model-ID split inside one API guide

The top-level model table and the Python, JavaScript and REST full-song examples use lyria-3.5. The clip path uses lyria-3-clip-preview. Yet the Java snippets repeatedly construct Model.of("lyria-3-generate-001"), including sections presented beside Lyria 3.5 generation, response format, parsing, image input, custom lyrics, timestamps, instrumental tracks and language examples.

That may be a stale sample rather than a broken endpoint; we had no credential to test either identifier. It is still a contract risk. Generate clients from a pinned internal model registry, reject unknown IDs at configuration load, and make a one-request canary prove the exact language SDK path before rollout.

The response is more than one audio file

Lyria uses the Interactions API. A response contains steps; model_output steps can hold text blocks for lyrics or song structure and audio blocks with base64 data. Google warns that convenience properties may miss parts of a complex interleaved response and documents iterating the raw steps for full control.

Persist the raw response envelope before extracting the final audio. Bind model ID, prompt revision, input-image hashes, returned text, audio hash, MIME type, duration, request ID, moderation outcome and reviewer decision. An MP3 alone cannot reconstruct why a track was approved.

The advertised audio contract is narrow and testable

The API page specifies 44.1 kHz stereo output. MP3 is the default; Lyria 3.5 can also return WAV through response_format. That establishes container and nominal sampling properties, not mastering quality, loudness, clipping, codec behavior or clean loop points.

Decode every output and inspect channels, sample rate, duration, peak level, integrated loudness, true peak, silence, truncation and file integrity. Transcode once in the real media pipeline and compare the distributed artifact, not only the pristine API response.

Eight cents is a request price, not a finished-track cost

Google lists Lyria 3.5 at $0.08 per full-song request. Lyria 3 Clip Preview costs $0.04 per 30-second request, while legacy Lyria 3 Pro Preview also costs $0.08 per full song. None has a free API tier. The apparent 3.5 upgrade therefore carries no listed per-request premium over the legacy full-song row.

The economic unit should be an accepted and cleared track. Ten clip trials plus three full generations cost $0.64 at list rates before storage, review, editing, rights work, rejected outputs and taxes. That is an illustrative calculator, not a measured invoice. Instrument attempts per accepted asset and cap both retries and spend.

Clip-first saves money only if it predicts the full song

Google recommends iterating with the faster clip model before committing to Lyria 3.5. Two clip calls cost the same list price as one full-song call, so the workflow helps only if short clips reduce expensive full attempts or reviewer time. The clip and full paths are different model IDs; transfer is an assumption.

Run matched prompt families through both. Measure whether genre, tempo, instrumentation, vocal character and hook acceptance in a clip predict acceptance of the full arrangement. If not, clip-first is an extra stage rather than an optimization.

Prompt control is a hypothesis matrix

Google exposes useful control dimensions: genre, instruments, BPM, key, mood, sections, timestamps, language, vocal profile and supplied lyrics. Those fields make a disciplined evaluation possible. They do not come with adherence percentages or a seed for reproducibility.

Create orthogonal cases with one declared requirement at a time, then combinations that reflect real briefs. Score BPM tolerance, key, section timing, lyric exactness, pronunciation, forbidden vocals, required instruments, ending behavior and reviewer preference. Repeat every case because Google explicitly says identical prompts can vary.

Image-to-music expands the data boundary

Lyria 3.5 accepts up to ten images alongside text. The model page and prompt guide describe interpreting people, places, actions, color and mood. This is semantic inspiration, not a documented mapping a developer can predict or audit from the image alone.

Treat uploaded images as production inputs with their own rights, consent and privacy review. Hash and retain only what policy permits. Do not send client artwork, faces, unreleased campaigns or confidential boards through an unpaid surface merely because the output is audio.

Paid and unpaid paths have different data terms

The pricing table labels the Lyria paid tier as not used to improve Google products. The API terms say paid Gemini API prompts and responses are not used for product improvement, while Google logs them for a limited period for abuse prevention and required legal disclosures. The terms warn that unpaid-service inputs and outputs may be used for product improvement and reviewed by humans.

Use a Cloud project with active billing for production and verify that the actual request is billed. Keep sensitive or personal material out unless the contract, region, retention path and organizational policy permit it. “Available in AI Studio” does not establish the same data boundary as paid API traffic.

The audience restriction can block a product design

The additional terms say API users must be at least 18 and that API clients must not be directed toward or likely accessed by people under 18. They also describe AI Studio and Gemini API as tools for developers building professional or business applications, not consumer use.

A music toy, education product or open consumer creator may therefore need a different product surface or explicit contractual review. Enforce eligibility before generation rather than burying it in terms, and re-check regional availability before launch.

Generated does not mean exclusive or cleared

Google says it will not claim ownership over generated content, but also says similar or identical content may be generated for others and leaves legal compliance and use responsibility with the developer. Safety filters block requests for specific artist voices and copyrighted lyrics; a blocked prompt is not a clearance opinion on an accepted output.

Require original or licensed supplied lyrics, avoid identity imitation, run similarity and memorization review appropriate to the release, preserve prompt and provenance records, and obtain qualified rights advice for commercial distribution. Do not promise uniqueness merely because a track came from a private request.

Single-turn generation changes the product architecture

The API explicitly says multi-turn editing or refinement is unsupported. “Make the bridge shorter” cannot be assumed to edit the previous musical object. A new call is a new nondeterministic generation unless the platform later publishes an editing contract.

Design the user experience around briefs, variants and selection. Version prompts and uploaded assets, show which request produced each candidate, and make external editing a separate traceable stage. Do not present chat history as an editable audio timeline.

SynthID is one provenance layer

Google says every generated Lyria track carries an imperceptible SynthID audio watermark. The SynthID page is also Google-authored; we found no independent Lyria 3.5 study reporting detection rates after transcoding, clipping, mixing, equalization, time stretching or distribution-platform processing.

Preserve the untouched source, its hash and the generation record. Test detection on every delivered derivative when a detector is available to the organization. Add visible disclosure where policy or context requires it. A watermark does not prove ownership, factuality, consent, license status or human review.

The missing independent evaluation limits the launch verdict

Google provides demonstrations and qualitative claims about vocals, musicality, fidelity and coherent structure. The launch does not publish a model card, benchmark dataset, rater protocol, confidence intervals, failure taxonomy, subgroup results or comparison audio under a controlled blind method. We located no independent Lyria 3.5 evaluation before publication.

That absence is not evidence that the model performs poorly. It means quality claims remain vendor evidence. A buyer should run blinded, randomized review against its current licensed-production path, include failures and disallowed briefs, and report confidence intervals rather than a highlight reel.

Run a release canary before connecting distribution

First verify both documented model IDs with the selected SDK and raw REST. Then generate a frozen set covering instrumental and vocal tracks, supplied and generated lyrics, timestamped sections, supported languages, image inputs, safety refusals and repeated identical prompts. Keep the publishing destination disconnected.

Validate schema, audio decoding, duration, loudness, adherence, lyric transcription, watermark detectability, moderation, latency, billed request count and cost per accepted track. Add malformed responses, timeouts and retries. A timeout after server completion must not trigger unlimited duplicate generation.

Ship one bounded use case, not a universal music engine

Approve one use case only when its exact model ID works, the parser preserves all response blocks, accepted-track cost meets budget, reviewers pass quality and rights gates, data treatment matches policy, disclosure survives delivery and rollback is tested. Keep generation separate from automatic publishing.

Wait when model identity, rights, audience, data or provenance is unresolved. Roll back on identifier failure, response-schema drift, moderation regression, unexpected billing, unacceptable similarity, missing disclosure or watermark verification failure. Re-evaluate when Google changes the model, price, Interactions schema, terms, filters or editing support.

Disclosures

AccessAllGPT did not receive advance access, API credits, generated samples, private evaluation data or compensation for this article. Google and Google DeepMind did not sponsor, review or endorse it. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with Google, Google DeepMind, OpenAI or organizations cited. Publication-wide relationships are listed on the disclosures page.