Count works, not file URLs
Music providers may return several works from one native generation. A work can contain an audio file, cover image, lyrics, and metadata. Those assets are parts of the work, not independent generations.
Keep the provider-defined bundle clear in the model page and price rule. A task returning two tracks must not be misreported as two user API calls.
{
"works": [
{
"work_id": "work_example",
"title": "Evening light",
"assets": [
{
"type": "audio",
"url": "https://media.example.com/audio.mp3"
},
{
"type": "cover",
"url": "https://media.example.com/cover.webp"
},
{
"type": "lyrics",
"text": "Illustrative lyric content"
}
]
}
]
}This is a conceptual preview, not a generated result. Actual output fields are finalized per model before provider integration.
No automatic output_count multiplier
The new 1–4 output_count field applies to images and videos only. It does not multiply native music bundles. Music continuation, lyric creation, and song generation have distinct operation IDs and rules.
Partial works and delivery
Per-work status, asset availability, and the task’s billing status must remain distinguishable. A missing thumbnail must not silently trigger another full music generation. Retry asset retrieval when a file transfer fails.
Partial-success billing for a native multi-work task is model-specific and must be published before that model becomes billable.