![Imagem de capa de [Vibe Coder #7] Evite sustos com cobranças de IA e nuvem](/assets/images/posts/0d58c5aa-a507-4618-873b-884467859592/cloud-bill-shock-limits-1.jpg)
“Acordei e a conta da nuvem veio em milhões de wones.” Textos assim aparecem com frequência nas comunidades de vibe coding e deixam até quem lê de coração na mão. Um app feito por hobby pode devolver um salário mensal em forma de cobrança. O assustador é que isso não acontece apenas com pessoas especialmente descuidadas. Sem conhecer o modelo de cobrança, pode acontecer com qualquer pessoa.
Felizmente, cobranças exorbitantes têm poucas causas comuns, então instalar medidas de segurança com antecedência bloqueia a maioria delas na origem. A configuração leva cinco minutos por serviço. Neste capítulo, veremos de onde vêm as cobranças, como elas disparam e como configurar essas proteções de cinco minutos.
As 3 principais fontes da cobrança
Os custos de apps criados com vibe coding geralmente vêm de três lugares.
1. AI API — cobrança por token. Serviços de IA como a OpenAI cobram por uma unidade chamada token. Pense em um token como um fragmento de texto. Um detalhe fácil de ignorar é que tanto a pergunta enviada (entrada) quanto a resposta da IA (saída) são cobradas. Além disso, modelos mais potentes podem custar várias vezes mais por token. Recursos que processam documentos longos inteiros e chatbots que reenviam toda a conversa a cada vez acumulam custos mais rápido do que parece.
2. DB — capacidade de armazenamento e operações de leitura/escrita. Um armazém (DB) cobra pela quantidade de carga armazenada (capacidade) e pelo número de vezes que suas portas abrem e fecham (leituras/escritas). A capacidade cresce aos poucos, mas as leituras/escritas podem explodir em um instante quando o código está errado.
3. Hospedagem — tráfego e tempo de execução. Servidores como a Vercel cobram pela quantidade de dados enviada aos visitantes e pelo tempo real de execução do código do backend. Imagens grandes enviadas no tamanho original e tarefas demoradas aumentam os custos aqui.
3 caminhos para a cobrança explodir
Caminho 1: roubo de chave. É o incidente abordado na parte 2: um bot encontra uma API key exposta e gasta à vontade no seu cartão corporativo. É o caminho mais destrutivo e o mais comum.
Caminho 2: um loop infinito no seu código. É um caso de autodestruição sem ladrão externo. Se o código gerado pela IA esconder um circuito em que “cada atualização da tela lê o DB novamente, e essa leitura provoca outra atualização”, um único usuário parado pode chamar o DB e a IA dezenas de vezes por segundo. O app parece normal, mas a contagem de chamadas no painel sobe loucamente. Antes do deploy, peça à IA para “verificar se existe código que chama repetidamente a API ou o DB”.
Caminho 3: tráfego inesperado. O app faz sucesso de repente (um problema bom) ou bots aparecem em massa (um problema ruim). Em qualquer caso, um serviço desprotegido aumenta a cobrança.
Proteção em 5 minutos: limites e alertas
Este é o ponto central deste capítulo. As três fontes oferecem nos painéis os recursos de limite de gastos e alerta de orçamento. Entre agora em cada conta e configure apenas estas duas coisas.
- Limite de gastos mensais: “Pare o serviço quando este valor for ultrapassado.” Em um projeto de hobby, defina um valor que você consiga pagar (por exemplo, 10.000–50.000 wones). O app para ao atingir o limite, mas não há o que comparar entre um app de hobby ficar parado por um dia e receber uma cobrança de milhões de wones.
- Alerta de orçamento: “Envie um e-mail quando este valor for atingido.” Configure-o perto de 50% do limite para perceber o problema enquanto a cobrança ainda está crescendo.
Os nomes dos menus variam, mas geralmente são Billing, Usage, Budget ou Spending limit. Se estiver difícil encontrar, pergunte à IA: “Onde configuro o limite de gastos mensais na OpenAI?”. Ela indicará o caminho. Mesmo usando apenas um plano gratuito, vale a pena ativar alertas. Como vimos na parte 6, esgotar a cota gratuita também pode ser o culpado silencioso pelo problema “ontem funcionava, hoje não”.
O princípio da parte 2 volta a ser uma linha de defesa: as chaves ficam somente no backend. Se uma chave não vazar, o caminho 1 fica totalmente bloqueado.
Se já aconteceu
Se seu coração afundou ao receber a cobrança, siga esta ordem.
- Pare o sangramento primeiro. Se houver suspeita de roubo, revogue e gere uma nova chave imediatamente (parte 2). Se houver suspeita de loop infinito, pause o deploy ou retire a função problemática do ar.
- Descubra a causa. Os gráficos de Usage no painel de cada serviço mostram quando o pico começou e quais chamadas dispararam.
- Entre em contato com o suporte. Especialmente no primeiro incidente, quando a causa foi roubo ou erro, não são raros os casos de redução da cobrança após explicar a situação. Você só tem a ganhar perguntando, então pergunte.
- Evite que aconteça novamente. Desta vez, configure obrigatoriamente os limites e alertas acima.
Resumo
- As cobranças vêm de três lugares: AI API (tokens), DB (capacidade e leituras/escritas) e hospedagem (tráfego e tempo de execução).
- Os três caminhos para uma cobrança explosiva são roubo de chaves, loops infinitos no código e tráfego inesperado.
- A melhor defesa leva cinco minutos por serviço: limite de gastos mensais + alerta de orçamento.
- Antes do deploy, peça à IA para verificar se há código com chamadas repetidas e mantenha as chaves somente no backend.
- Se já aconteceu: parar o sangramento → descobrir a causa → contatar o suporte → instalar as proteções.
O próximo capítulo será o último da série. Ele reúne em uma página o checklist mínimo de segurança para revisar antes de aceitar usuários e o mapa construído desde a parte 1.