Vibe coding para calcular custo real de API de vídeo antes de usar: o piso por projeto

A página de preços de uma API de vídeo dá o preço do plano. O custo do seu vídeo está em outro lugar. Na live em que está montando uma agência de marketing com IA, Thiago abriu a documentação de cobrança antes de escrever a integração e leu em voz alta a linha que muda a conta:

"cada projeto enviado a API com a taxa mínima de 10 créditos"

Piso por projeto significa que um vídeo de 1 minuto e um vídeo de 10 minutos consomem o mesmo crédito dentro do mesmo degrau. Quem leu só a página comercial acredita que comprou um valor por minuto baixo, e o valor por minuto que ele de fato comprou depende inteiramente da duração do vídeo que manda. Esse número não está na página comercial, está na documentação de cobrança.

A conta cabe em 4 números

O plano custa 9 dólares e dá 300 créditos. Com o piso de 10 créditos por projeto, 300 dividido por 10 dá 30 vídeos. Cada vídeo pode ter até 10 minutos de processamento.

O custo por unidade sai daí. São 9 dólares divididos por 30 vídeos, ou seja, 0,30 dólar por vídeo. Se o vídeo usa os 10 minutos inteiros, esses 0,30 dólar cobrem 10 minutos, e o minuto sai a 0,03 dólar. Se o vídeo tem 1 minuto, os mesmos 0,30 dólar cobrem 1 minuto só, e o minuto sai a 0,30 dólar. A assinatura e o crédito são os mesmos nos dois casos, e o custo por minuto varia 10 vezes conforme a duração do que você manda.

Qual dos dois números vale depende do produto. Se o produto processa vídeo curto, a economia anunciada na página de preços não é dele: cada envio começa nos 10 créditos, e sobram 9 minutos pagos que ninguém usa.

Por que essa leitura entra no vibe coding

No vibe coding o produto fica de pé antes de a fatura chegar. Você pluga a API numa tarde, o fluxo funciona, e a unidade econômica só aparece quando o mês fecha, junto com o preço que você já prometeu ao cliente. A documentação de cobrança é onde esse número existe antes. Foi o mesmo caminho de gsap scrolltrigger.

O que ele fez dá para repetir em qualquer API: abrir a parte da documentação que descreve a cobrança, procurar como uma chamada é contada, achar o piso, transformar o piso em custo por vídeo. A pergunta que ele leva para a documentação é quanto custa uma unidade do produto dele.

Toda integração externa também precisa de guardrails. Vibe coding para não deixar o agente em loop de retry sem limite mostra como proteger agentes quando eles chamam APIs: não é só importante saber quanto custa, mas também limitar quantas vezes a tentativa acontece. Permissões também precisam de limite: vibe coding para dar permissão pontual ao agente sem virar regra lembra que toda credencial liberada precisa de um fim. E toda mudança de estrutura também precisa de certeza antes de rodar: vibe coding para migrar dados sem perder historico mostra como separar garantia técnica de suposição. Isso aparece também em property based testing.

O acervo que cresce junto com as sessões também necessita de triage: vibe coding para organizar varios documentos de plano sem apagar historico lembra que marcar o que morreu é melhor que deletar a história.

A janela em que o crédito é válido também tem que estar clara: vibe coding para creditos anuais nao expirarem como os mensais mostra como a validade importa mais que o desconto na escolha entre plano mensal e anual. O mesmo problema apareceu em como calcular markup.

Dentro de uma sessão longa com agente, o que muda o critério de decisão é a nomeação: vibe coding para separar bug bloqueante de polimento visual mostra por que dizer em voz alta o que fica para depois é a parte que garante que o item volta na hora dele.

Quando o agente trabalha em paralelo e a falha aparece como lista, a triagem é tudo: vibe coding para distinguir falha de worker redundante de bug real mostra como separar o ruído da redundância do defeito real sem depender da máquina.

Com vários workers ligados, quem controla o tempo de vida é a memória local: vibe coding para monitorar memoria ao rodar varios workers em paralelo mostra que quem decide o limite não é o plano, é a máquina.

Uma decisão que não fica escrita volta a ser pergunta: vibe coding para congelar decisao de escopo e nao reabrir mostra por que marcar o que já foi decidido custa uma linha e economiza dias.

E em produção, o feedback que sustenta a confiança vem de guardar o motivo: vibe coding para ia aprender com o motivo da rejeicao lembra que a escada de confiança sobe com feedback específico, não com reprodução cega.

Alugar conveniência ou operar a máquina

Com o número na mão, ele não fecha a decisão. Considera que talvez não valha a pena, e o motivo que dá é que estaria usando o servidor do provedor. Em seguida levanta a alternativa: oferecer processamento local, para quem não tem máquina boa o suficiente para renderizar.

A API de terceiro é conveniência alugada por unidade, e ela faz sentido exatamente para esse usuário cuja máquina não dá conta. Rodar local troca custo por unidade por custo fixo, e junto vem a responsabilidade de operar: fila, falha, atualização, suporte a hardware que não é seu.

O que decide entre os dois é o volume em que eles se cruzam, isto é, quantos vídeos por mês precisam passar para o custo fixo de rodar local ficar abaixo de 0,30 dólar por projeto. Esse ponto de cruzamento só existe depois que você tem o custo por unidade. Sem ele, comprar ou construir vira preferência defendida com adjetivo. A live termina sem decisão fechada, com a alternativa levantada e o número na mesa.

Outro builder já tratou do risco de API de terceiro no vibe coding pelo lado do acesso: sem aprovação de acesso à API, o produto vira outra coisa. Aqui o risco é de custo por unidade, mesmo fornecedor externo e perguntas diferentes.

O que fazer antes da primeira chamada

Abra a documentação de cobrança da API que você pretende usar e procure a unidade real: se a conta é por segundo, minuto, crédito ou requisição, se existe mínimo por chamada ou por projeto, e como o arredondamento funciona. Os termos que costumam esconder o piso são "minimum", "per request", "per project" e "billing". Quando a página de preços e a documentação divergirem, quem gera a fatura é a documentação.

Depois monte a sua conta por unidade. Divida o preço do plano pelo número de envios que o piso permite e você tem o custo por envio. Divida esse custo pela duração típica do seu caso, não pela duração máxima que o plano permite, porque é a típica que vai aparecer na sua fatura. Compare o resultado com o que você cobra por unidade do seu produto e a margem aparece ou não aparece.

Com o custo por unidade na mesa, sobra decidir de que forma esse custo volta em receita — e é aí que aparece a tentação de somar mensalidade e pacote de créditos no mesmo checkout, o que costuma sair caro demais para o cliente aceitar. Vale ler o vibe coding para não cobrar assinatura e crédito ao mesmo tempo antes de montar a mistura de planos. O mesmo problema apareceu em ffmpeg o que é.

Fazer essa conta antes de escrever a integração é o que mantém o vibe coding de pé quando o produto começa a rodar com usuário de verdade. Dá para assistir à live e ver o momento em que ele para na taxa mínima e começa a dividir.