Stable Audio: Documentação da API, Preços da API e Guia da API Stable Audio 2.5 (2026)

As seções abaixo se concentram nas partes que geralmente importam depois que você passa da página inicial: como o Stable Audio é exposto por meio de diferentes superfícies, o que ler primeiro na documentação, como pensar sobre os preços e onde as perguntas específicas da versão precisam de verificação extra

Resumo em 3 linhas

• Comece com a documentação do provedor (autenticação → esquema de solicitação → assíncrono/streaming → erros) antes de ajustar os prompts.

• Orçe pelo que o provedor cobra (créditos, duração, tentativas), não por "uma solicitação = um custo".

• Trate "Preços do Stable Audio 2.0 em 2026" como uma tarefa de verificação: confirme os IDs do modelo e a tabela de preços na plataforma que você está realmente usando.

Ir para

• O que o Stable Audio pode gerar

• Documentação da API do Stable Audio

• Fluxo completo da API Stable Audio 2.5

• Preços da API do Stable Audio

• Stable Audio vs Suno vs Udio

• Solução de problemas

Em um nível prático, o Stable Audio é um sistema de geração de áudio que você pode usar para criar ideias musicais curtas, elementos de design de som e variações — seja apenas a partir de texto ou transformando áudio existente, dependendo da superfície e API específicas do produto que você integrar. A maioria das equipes o avalia para: prototipagem rápida, variantes de conteúdo (anúncios, redes sociais), esboços de SFX/música para jogos e ferramentas de criação onde latência e custo são importantes.

No uso diário, você normalmente verá dois modos de geração amplos:

• Texto para áudio: você descreve o que deseja (gênero, instrumentos, humor, tempo, mixagem) e o modelo gera um novo áudio.

• Áudio para áudio: você fornece um clipe de áudio de entrada e pede uma transformação (variação, reestilização, edições semelhantes a inpainting ou "mesma ideia, produção diferente"), sujeito ao que o seu endpoint escolhido suporta.

Para a visão geral canônica do produto e qualquer posicionamento oficial em torno das capacidades, comece na página inicial do Stable Audio na Stability AI: Stable Audio da Stability AI. A partir daí, decida se você é um criador individual (a interface interativa pode ser suficiente) ou um desenvolvedor/equipe (você vai querer um caminho de provedor de API com faturamento previsível, limites de taxa e expectativas de suporte).

Os desenvolvedores frequentemente se deparam com confusão porque o "Stable Audio" pode ser acessado por meio de diferentes pontos de entrada: as próprias superfícies de produtos da Stability AI, uma API oficial e plataformas parceiras que hospedam ou expõem modelos como endpoints gerenciados. A diferença é importante para tudo o que você precisa na produção: autenticação, cotas, observabilidade, repetições e exibição de preços.

Uma maneira simples de pensar sobre isso:

Um exemplo concreto de estilo de parceria é a experiência de listagem de modelos que você verá em provedores como o fal (útil para entender rapidamente o tipo de endpoint e a exibição de preços): Página do modelo Stable Audio 2.5 (áudio para áudio).

Se o seu objetivo imediato é a documentação da API Stable Audio, comece com a referência específica do provedor para o endpoint que você planeja enviar. Por exemplo, se você estiver integrando um endpoint de parceiro, pode começar com a referência da API aqui: Documentação da API de áudio para áudio Stable Audio 2.5.

O que ler primeiro (em ordem) para evitar perder horas:

1. Autenticação: como as chaves de API são passadas, quais cabeçalhos são necessários e como funcionam os escopos/permissões.

2. Esquema de requisição: nomes de campos exatos, tipos de dados, valores mínimos/máximos (limites de duração são frequentemente a primeira surpresa).

3. Esquema de resposta: onde a URL/blob do áudio de saída aparece, além de quaisquer metadados que você precise para atribuição/registro.

4. Assíncrono vs síncrono: se a geração é enfileirada e requer polling/callbacks, e por quanto tempo os resultados permanecem disponíveis.

5. Códigos de erro & limites de taxa: especialmente erros de autenticação 401/403, throttling 429 e comportamento de timeout.

Considere a documentação como a fonte da verdade para nomes de parâmetros e valores padrão—mesmo pequenas incompatibilidades (segundos vs milissegundos, duration vs duration_seconds) podem produzir falhas confusas.

A maioria dos problemas de "minha primeira solicitação falhou" não são problemas do modelo, mas sim problemas de autenticação, ambiente ou cota. Use esta lista de verificação antes de depurar os prompts.

Lista de verificação pré-voo

• Armazene a chave da API em uma variável de ambiente (evite codificá-la diretamente em repositórios ou aplicativos cliente).

• Confirme se a chave é para o workspace/projeto correto (as equipes geralmente têm vários).

• Verifique se o acesso ao modelo está habilitado (alguns provedores limitam determinados modelos, regiões ou níveis).

• Verifique os limites/créditos de uso antes de testar a carga (uma parada repentina pode parecer um bug de rede).

• Certifique-se de que o relógio do seu servidor esteja preciso se o provedor usar assinaturas baseadas em tempo (varia de acordo com o provedor).

Erros comuns → causas prováveis → soluções rápidas

Como as limitações podem diferir entre as superfícies oficiais e as de parceiros, sempre verifique os documentos exatos do endpoint que você está chamando.

Na documentação da API Stable Audio, os campos mais importantes são os que determinam (a) o que é gerado e (b) quanto você paga. Embora os nomes exatos variem de provedor para provedor, você verá comumente:

• prompt: sua descrição de texto (gênero + instrumentação + humor + estrutura + notas de mixagem).

• duration / duration_seconds: duração desejada da saída. Isso geralmente afeta o custo e o tempo de execução.

• input_audio (áudio para áudio): um upload, um URL ou um payload base64—mais parâmetros opcionais que controlam o quão fortemente a saída adere à entrada (os nomes dos campos diferem).

• Controles opcionais de seed / randomness: se suportados, eles ajudam a reproduzir as saídas; se não forem suportados, você usará truques de consistência no nível do fluxo de trabalho (abordados abaixo).

Uma “forma” mínima para uma solicitação de áudio para áudio (pseudo-estrutura; verifique as chaves exatas na documentação do seu endpoint):

• Defina API_KEY no seu ambiente

• Envie uma solicitação com:

• prompt: “Lo-fi hip hop beat, warm vinyl noise, 85 BPM, mellow keys, tight kick”

• duration_seconds: 15

• input_audio: sua referência de clipe (URL/upload/base64 conforme a documentação)

• Receba uma resposta contendo:

• uma URL de áudio de saída ou referência de arquivo

• um ID de solicitação/tarefa para rastreamento (especialmente para async)

Uma integração da API Stable Audio 2.5 pronta para produção é menos sobre uma única solicitação POST e mais sobre o fluxo de trabalho circundante: preparação de ativos, controle de tarefas, download/armazenamento e observabilidade. Um passo a passo conceitual útil (especialmente se você estiver usando ferramentas baseadas em nó) é o tutorial do parceiro aqui: Stable Audio na documentação do Comfy.

Um fluxo prático de "0 para 1" se parece com isto:

1. Preparar recursos

• Se você estiver fazendo áudio para áudio, normalize o clipe de entrada: volume consistente, silêncio cortado e um formato/tamanho suportado (os requisitos exatos dependem da documentação do seu provedor).

• Pré-calcule os metadados que você vai querer mais tarde: ID do usuário, versão do prompt, ID do modelo e um sinalizador de política de conteúdo se seu aplicativo tiver um.

1. Submeta o pedido de geração

• Armazene o payload completo que você envia (menos os segredos) para depuração e reprodutibilidade posteriores.

• Anexe uma chave de idempotência se o provedor a suportar (evita cobranças duplicadas quando ocorrem novas tentativas — específico do provedor).

1. Lidar com execução assíncrona

• Muitas gerações de áudio estão enfileiradas; prefira um padrão de tarefa assíncrona, se disponível.

• Implemente polling com backoff ou webhooks/callbacks onde suportado.

1. Baixar + armazenar saídas

• Persista o arquivo resultante no seu próprio armazenamento (S3/GCS/R2) para não depender de URLs de provedores temporários.

• Armazene metadados: versão do modelo, parâmetros, timestamp e qualquer campo semelhante a uma semente.

1. Reutilize, itere e faça testes A/B

• Salve modelos de prompt e configurações de "bom funcionamento conhecido" para cada caso de uso (jingle de anúncio, SFX de UI de jogo, loop lo-fi).

• Gere variações em lote e escolha os vencedores usando revisão humana ou verificações leves de recursos de áudio.

Escolher o padrão de endpoint correto é a maneira mais rápida de obter uma saída melhor com menos tentativas (e menos surpresas na sua fatura).

Se o seu provedor oferece ambos, é comum usar texto para áudio para rascunhos iniciais e, em seguida, áudio para áudio para "fixar" uma direção e produzir variantes controladas.

Consistência é geralmente a diferença entre uma demonstração divertida e um recurso pronto para ser lançado. Seu objetivo é reduzir a aleatoriedade nas entradas (prompt, configurações, referências) para que você não gaste orçamento com força bruta.

Se o seu endpoint suporta sementes

• Persista a semente com cada recurso gerado.

• Mantenha os prompts estáveis e altere apenas uma variável por vez (instrumentação, BPM ou humor — não todos os três).

Se o seu endpoint não suportar sementes (ou o comportamento da semente variar)

• Use um modelo de prompt fixo e restrinja-o com requisitos musicais + de mixagem claros.

• Use áudio para áudio com um clipe de referência consistente para ancorar a estrutura.

• Gere em lote um pequeno conjunto (por exemplo, 4–8) e escolha a correspondência mais próxima em vez de regenerar repetidamente um por um (isso geralmente reduz a "deriva" no seu processo de seleção).

Uma estrutura de prompt reutilizável que tende a permanecer no alvo:

• Estilo/gênero: “minimal techno, vibe de armazém”

• Tempo e groove: “125 BPM, batida constante de quatro por quatro”

• Instrumentação: “bumbo preciso, chimbal fora do tempo, baixo mono”

• Atmosfera: “sombria, tensa, hipnótica”

• Notas de mixagem: “graves impactantes, agudos controlados, reverb leve”

• Restrições negativas: “sem vocais, sem introdução longa, evitar acordes de jazz”

Para iteração amigável ao criador, você também pode prototipar modelos de prompt e variações em um aplicativo de música como o MelodyCraft antes de consolidá-los em predefinições de API.

O preço da Stable Audio API pode ser direto ou confuso dependendo da plataforma: algumas cobram por créditos, algumas mostram o preço por solicitação e muitas efetivamente precificam pela duração da saída (e às vezes pelas configurações de qualidade). O ponto de partida mais confiável para alterações oficiais de preços e como os créditos são definidos é a postagem de atualização da Stability AI: Atualização de preços da API.

Para estimar o custo sem adivinhar, construa o seu modelo de orçamento em torno de três questões:

1. Unidade de cobrança: créditos, segundos, requisições ou um híbrido?

2. O que conta como uso: apenas gerações bem-sucedidas ou trabalhos falhados/repetidos também consomem créditos? (Isso varia de provedor para provedor — verifique na documentação de cobrança.)

3. Limites e níveis: duração máxima por chamada, concorrência e se níveis mais altos desbloqueiam melhor taxa de transferência.

Um método de estimativa simples que você pode aplicar hoje:

• Determine a duração média solicitada (por exemplo, 10s, 15s, 30s).

• Determine a taxa de repetição esperada (por exemplo, 5–15% no início da produção; ajuste para baixo à medida que melhora os prompts e a validação).

• Multiplique pela tabela de crédito por unidade do seu provedor e aplique um buffer.

Tabela de exemplo de intervalo de custos (insira os números do seu provedor)

A chave é que “1.000 gerações” não é um número de custo até que você defina a duração, o tipo de endpoint e o comportamento de repetição.

Mesmo quando ambos os modos estão disponíveis, texto para áudio vs áudio para áudio podem ter preços diferentes (ou ter limites diferentes). Antes de enviar, faça esta verificação de 7 pontos para não descobrir a economia unitária em produção.

Lista de lançamento (preços + limites)

1. Confirme o(s) endpoint(s) exato(s) que você chamará e seu preço unitário (créditos/segundos/requisições).

2. Confirme a duração máxima por requisição e se áudios mais longos exigem divisão em partes.

3. Confirme os limites de concorrência (requisições por minuto, trabalhos paralelos).

4. Confirme as regras de faturamento de falhas e novas tentativas (específicas do provedor; não presuma).

5. Confirme se a largura de banda de upload/download do áudio de entrada afeta o custo (geralmente separada, mas varia).

6. Confirme se os parâmetros de "qualidade" ou "etapas/iterações" alteram o preço (se expostos).

7. Confirme a janela de retenção de saída (por quanto tempo o provedor hospeda o arquivo gerado).

Se algo do acima não estiver explícito na documentação, trate como um risco e teste com um pequeno piloto pago.

Em algumas plataformas de parceiros, você verá um rótulo simples como “$0,2 por áudio”. A maneira correta de interpretar isso é: “$0,2 por solicitação sob as premissas padrão para este endpoint”. Seu custo real pode ser maior ou menor, dependendo do que o provedor considera uma unidade faturável.

Use a exibição de preços da página do modelo como ponto de partida e, em seguida, valide com documentos de faturamento e faturas. Exemplo: Página do modelo de áudio para áudio Stable Audio 2.5.

O que geralmente altera o custo real (frequentemente dependente do provedor, então trate como inferência até confirmado):

• Substituições de duração: áudios mais longos podem custar mais, mesmo que a interface do usuário mostre um único número.

• Tentativas: tentativas de rede ou timeouts podem criar trabalhos duplicados se você não usar idempotência.

• Alterações de parâmetros: modos de "alta qualidade", passes adicionais ou recursos avançados podem alterar o faturamento.

• Loteamento: gerar 4 variações em uma chamada versus 4 chamadas separadas pode ter preços diferentes (depende do design da API).

Se você quer gastos previsíveis, registre: nome do endpoint, duração, tamanho do payload, ID do trabalho e unidades finais cobradas por solicitação — então reconcilie semanalmente.

As pessoas pesquisam “stable audio 2.0 pricing 2026” porque estão tentando determinar se a versão “2.0” é cobrada de forma diferente das versões mais recentes (como a 2.5) ou se está incluída em uma tabela de créditos unificada. A abordagem mais segura é não presumir — é verificar usando um rastro repetível.

Aqui está um fluxo de trabalho de verificação limpo:

1. Comece com as atualizações oficiais de preços: verifique a página de atualização de preços da Stability AI para saber como os créditos são mapeados para os modelos e se os nomes das versões são explicitamente mencionados: Atualização de preços da API.

2. Confirme o nome/versão do modelo no seu provedor: procure o identificador exato do modelo (por exemplo, "stable-audio-2.5" vs "stable-audio-2.0") na listagem de endpoints e na documentação.

3. Verifique na página de faturamento/fatura: identifique qual SKU/ID de modelo está sendo cobrado quando você executa uma geração de teste.

4. Salve evidências para sua equipe: mantenha um snapshot (data + URL) da página de preços e do ID do modelo que você usou para que as discussões sobre preços não se tornem adivinhações mais tarde.

Essa abordagem funciona tanto se você estiver usando uma superfície de API oficial quanto um marketplace de parceiros, porque, em ambos os casos, o "preço real" é o que o sistema de faturamento registra para o ID do modelo que você executou.

Se você não conseguir encontrar um item de linha separado para 2.0, geralmente é por causa de um destes cenários:

• Roll-up de versão: o preço é listado sob uma categoria mais ampla de "Stable Audio" ou "Áudio" em vez de um rótulo "2.0".

• Descontinuação ou renomeação do modelo: a plataforma pode ter movido os usuários para um ID de modelo mais recente sem enfatizar o nome antigo.

• Ponto de entrada diferente: a superfície oficial do produto e uma superfície de parceiro podem mostrar preços diferentes.

• Termos exclusivos para empresas (inferência): alguns direitos de uso ou preços podem ser negociados por meio de vendas em vez de tabelas públicas.

O que fazer a seguir:

• Entre em contato com o suporte da plataforma com seu ID do modelo, ID da solicitação e uma captura de tela de onde você esperava ver os preços.

• Execute um teste controlado (uma solicitação) e verifique como ele aparece na fatura/exportação.

• Documente o resultado em suas notas de engenharia, incluindo a data, caso os preços mudem novamente.

Antes de publicar qualquer coisa gerada com o Stable Audio, confirme os termos de licenciamento e uso comercial para a superfície exata que você usou (plataforma oficial vs plataforma parceira). Os termos podem diferir por provedor e por plano, portanto, sempre valide nas páginas de termos relevantes, em vez de confiar em resumos da comunidade.

Uma checklist de conformidade prática para equipes:

• Confirme se o uso comercial é permitido no seu plano e através do endpoint escolhido.

• Confirme os requisitos de atribuição (se houver) para áudio publicado.

• Confirme se pode usar as saídas em anúncios, jogos, podcasts ou bibliotecas de stock (os termos geralmente diferem por tipo de distribuição).

• Confirme o tratamento de dados: se os prompts/entradas de áudio são retidos e se podem ser usados para treinamento (específico do provedor).

• Confirme a sua política interna para conteúdo proibido (por exemplo, personificação, melodias protegidas por direitos autorais, sons semelhantes a marcas).

Isto não é aconselhamento jurídico—trate-o como um checklist operacional para garantir que faz as perguntas certas desde o início.

Quando as equipes comparam o Stable Audio com o Suno e o Udio, a escolha "melhor" depende das restrições de implantação, do fluxo de trabalho e da tolerância ao risco — não apenas da qualidade bruta da saída. O Stable Audio se torna a escolha mais segura em alguns casos comuns:

• Você precisa de sinais mais claros sobre implantação e portabilidade (por exemplo, interesse em modelos de áudio menores/compatíveis com a borda, conforme discutido em reportagens como a da TechCrunch: Stability AI lança um modelo de geração de áudio que pode ser executado em smartphones).

• Você precisa de um caminho de integração API-first com IDs de modelo explícitos e observabilidade previsível.

• Sua organização é especialmente sensível ao risco de PI e deseja basear as decisões em termos documentados e relatórios de reputação, não apenas em anedotas da comunidade.

Uma tabela de decisão simples:

Para outra perspectiva sobre as diferenças de saída, você também pode revisar as comparações da comunidade (e, em seguida, validar testando seus próprios prompts): Visão geral da comparação Udio vs Suno.

Q: O Stable Audio é de "alta qualidade" em comparação com outros geradores?

R: A qualidade depende fortemente do endpoint/versão, duração e disciplina do prompt. Para a maioria das equipes, a medida prática é "quantas gerações até obtermos uma saída aceitável", porque isso impulsiona tanto a UX quanto o custo.

P: O Stable Audio consegue gerar vocais e letras?

R: Depende da versão específica do Stable Audio e da plataforma que você está usando (alguns endpoints se concentram em design instrumental/sonoro). Verifique a lista de recursos na documentação do seu provedor e teste com um conjunto de avaliação curto.

Q: Quão controlável é (estrutura, tempo, instrumentação)?

A: O controle melhora quando você (1) especifica tempo/groove, (2) restringe a instrumentação, (3) mantém a duração curta durante a iteração e (4) usa áudio para áudio quando você precisa preservar o tempo/estrutura.

Q: E quanto ao risco de PI?

A: Nenhum modelo elimina o risco. Sua postura operacional mais segura é: seguir os termos da plataforma, evitar solicitar "exatamente como" artistas vivos ou músicas reconhecíveis, manter registros de proveniência e executar um processo de revisão para lançamentos comerciais. Se você estiver avaliando direções de pesquisa e enquadramento de risco, também pode consultar discussões acadêmicas relevantes (para contexto técnico): https://arxiv.org/html/2506.19085v1

A maioria das "falhas" de áudio estável pode ser corrigida com restrições mais rígidas, ciclos de iteração mais curtos e melhor validação de entrada. Se você estiver construindo um recurso (não apenas experimentando), trate a solução de problemas como parte do design do seu produto: defina a saída aceitável, imponha restrições de solicitação e registre tudo.

Aqui estão os cinco problemas mais comuns e duas soluções imediatas para cada:

1) A saída se desvia do prompt (gênero/instrumentos errados)

• Ajuste A: Mover as restrições principais para a frente: “Instrumental, sem vocais. 90 BPM. Bateria acústica + baixo elétrico.”

• Ajuste B: Adicionar restrições negativas: “evitar supersaw de EDM, evitar cordas orquestrais.”

2) A música parece sem estrutura ou divagando

• Ajuste A: Diminua a duração durante a iteração (por exemplo, 8–15 segundos) e só aumente a escala depois de obter o motivo certo.

• Ajuste B: Especifique as pistas de estrutura: “introdução curta, loop principal, finalização limpa” (o comportamento suportado varia, mas geralmente ajuda).

3) Clipping, agudos ásperos ou distorção

• Ajuste A: Adicione restrições de mixagem: “sem clipping, agudos controlados, volume moderado.”

• Ajuste B: Normalize seu áudio de entrada (para áudio para áudio) e evite referências extremamente altas.

4) Duração incorreta (muito curta/muito longa)

• Ajuste A: Certifique-se de que está definindo o nome/unidade do campo de duração correto nos documentos.

• Ajuste B: Se o endpoint tiver uma duração máxima, divida as solicitações em partes e junte-as downstream.

5) Inconsistência de estilo entre as variações

• Ajuste A: Use um modelo de prompt fixo e mantenha uma única "linha de estilo" constante em todas as solicitações.

• Ajuste B: Prefira áudio para áudio com um clipe de referência consistente para ancorar timbre e groove (quando disponível).

Para dicas práticas de fluxo de trabalho sobre geração e iteração de Stable Audio, o tutorial do Comfy e os guias práticos também são referências úteis: Tutorial do Stable Audio e um passo a passo orientado para profissionais no DigitalOcean: https://www.digitalocean.com/community/tutorials/stable-audio-music-generation

Quando a qualidade da saída está boa, mas sua integração é instável, depure como um engenheiro de API, não como um engenheiro de prompt. Use uma lista de verificação de incidentes consistente:

• Registe um ID de pedido (da resposta do fornecedor) e anexe-o ao ID de trabalho da sua aplicação.

• Armazene o payload bruto que enviou (oculte segredos) para que possa reproduzir.

• Valide as entradas antes de enviar:

• formato de áudio, duração e tamanho do ficheiro (de acordo com a documentação do seu endpoint)

• campos obrigatórios presentes e dentro dos intervalos permitidos

• Implemente backoff para 429s: backoff exponencial + jitter; limite o número máximo de tentativas; evite o efeito "thundering herds".

• Lide com timeouts explicitamente:

• use o envio de trabalho assíncrono, se disponível

• aumente o timeout do cliente apenas se o fornecedor o recomendar

• trate os timeouts como "estado desconhecido" e reconcilie por ID de trabalho, não repetindo cegamente

Se você estiver usando o endpoint de áudio para áudio do Stable Audio 2.5 em um provedor parceiro, mantenha a referência da API aberta enquanto depura nomes de campos e restrições: Documentação da API de áudio para áudio do Stable Audio 2.5.