music_generate tool lets the agent create music or audio through the
shared music-generation capability with configured providers such as Google,
MiniMax, and workflow-configured ComfyUI.
For shared provider-backed agent sessions, FluffBuzz starts music generation as a
background task, tracks it in the task ledger, then wakes the agent again when
the track is ready so the agent can post the finished audio back into the
original channel.
The built-in shared tool only appears when at least one music-generation provider is available. If you don’t see
music_generate in your agent’s tools, configure agents.defaults.musicGenerationModel or set up a provider API key.Quick start
Shared provider-backed generation
- Set an API key for at least one provider, for example
GEMINI_API_KEYorMINIMAX_API_KEY. - Optionally set your preferred model:
- Ask the agent: “Generate an upbeat synthpop track about a night drive through a neon city.”
music_generate automatically. No tool allow-listing needed.
For direct synchronous contexts without a session-backed agent run, the built-in
tool still falls back to inline generation and returns the final media path in
the tool result.
Example prompts:
Workflow-driven Comfy generation
The bundledcomfy plugin plugs into the shared music_generate tool through
the music-generation provider registry.
- Configure
models.providers.comfy.musicwith a workflow JSON and prompt/output nodes. - If you use Comfy Cloud, set
COMFY_API_KEYorCOMFY_CLOUD_API_KEY. - Ask the agent for music or call the tool directly.
Shared bundled provider support
Declared capability matrix
This is the explicit mode contract used bymusic_generate, contract tests,
and the shared live sweep.
Use
action: "list" to inspect available shared providers and models at
runtime:
action: "status" to inspect the active session-backed music task:
Built-in tool parameters
Not all providers support all parameters. FluffBuzz still validates hard limits
such as input counts before submission. When a provider supports duration but
uses a shorter maximum than the requested value, FluffBuzz automatically clamps
to the closest supported duration. Truly unsupported optional hints are ignored
with a warning when the selected provider or model cannot honor them.
Tool results report the applied settings. When FluffBuzz clamps duration during provider fallback, the returned
durationSeconds reflects the submitted value and details.normalization.durationSeconds shows the requested-to-applied mapping.
Async behavior for the shared provider-backed path
- Session-backed agent runs:
music_generatecreates a background task, returns a started/task response immediately, and posts the finished track later in a follow-up agent message. - Duplicate prevention: while that background task is still
queuedorrunning, latermusic_generatecalls in the same session return task status instead of starting another generation. - Status lookup: use
action: "status"to inspect the active session-backed music task without starting a new one. - Task tracking: use
fluffbuzz tasks listorfluffbuzz tasks show <taskId>to inspect queued, running, and terminal status for the generation. - Completion wake: FluffBuzz injects an internal completion event back into the same session so the model can write the user-facing follow-up itself.
- Prompt hint: later user/manual turns in the same session get a small runtime hint when a music task is already in flight so the model does not blindly call
music_generateagain. - No-session fallback: direct/local contexts without a real agent session still run inline and return the final audio result in the same turn.
Task lifecycle
Eachmusic_generate request moves through four states:
- queued — task created, waiting for the provider to accept it.
- running — provider is processing (typically 30 seconds to 3 minutes depending on provider and duration).
- succeeded — track ready; the agent wakes and posts it to the conversation.
- failed — provider error or timeout; the agent wakes with error details.
queued or running for the current session, music_generate returns the existing task status instead of starting a new one. Use action: "status" to check explicitly without triggering a new generation.
Configuration
Model selection
Provider selection order
When generating music, FluffBuzz tries providers in this order:modelparameter from the tool call, if the agent specifies onemusicGenerationModel.primaryfrom configmusicGenerationModel.fallbacksin order- Auto-detection using auth-backed provider defaults only:
- current default provider first
- remaining registered music-generation providers in provider-id order
agents.defaults.mediaGenerationAutoProviderFallback: false if you want
music generation to use only the explicit model, primary, and fallbacks
entries.
Provider notes
- Google uses Lyria 3 batch generation. The current bundled flow supports prompt, optional lyrics text, and optional reference images.
- MiniMax uses the batch
music_generationendpoint. The current bundled flow supports prompt, optional lyrics, instrumental mode, duration steering, and mp3 output. - ComfyUI support is workflow-driven and depends on the configured graph plus node mapping for prompt/output fields.
Provider capability modes
The shared music-generation contract now supports explicit mode declarations:generatefor prompt-only generationeditwhen the request includes one or more reference images
maxInputImages, supportsLyrics, and
supportsFormat are not enough to advertise edit support. Providers should
declare generate and edit explicitly so live tests, contract tests, and
the shared music_generate tool can validate mode support deterministically.
Choosing the right path
- Use the shared provider-backed path when you want model selection, provider failover, and the built-in async task/status flow.
- Use a plugin path such as ComfyUI when you need a custom workflow graph or a provider that is not part of the shared bundled music capability.
- If you are debugging ComfyUI-specific behavior, see ComfyUI. If you are debugging shared provider behavior, start with Google (Gemini) or MiniMax.
Live tests
Opt-in live coverage for the shared bundled providers:~/.profile, prefers
live/env API keys ahead of stored auth profiles by default, and runs both
generate and declared edit coverage when the provider enables edit mode.
Today that means:
google:generatepluseditminimax:generateonlycomfy: separate Comfy live coverage, not the shared provider sweep
Related
- Background Tasks - task tracking for detached
music_generateruns - Configuration Reference -
musicGenerationModelconfig - ComfyUI
- Google (Gemini)
- MiniMax
- Models - model configuration and failover
- Tools Overview