Lovable: por que os créditos acabam

Os créditos do Lovable acabam rápido por dois motivos: o pedido vago, que vira refação paga, e o loop de bug, o “tenta de novo” que cobra mesmo quando falha. Crédito mais barato não fecha esses buracos. Quem fecha é um guardrail antes do build: um arquivo de regras que decide o que vai pro Lovable.

Eu uso o Lovable na minha operação pra tirar do papel painel, proposta e ferramenta interna. E já vi créditos do Lovable evaporarem num dia que, olhando a tela, parecia produtivo. A ferramenta não estava errada. O pedido é que chegava cru, visse.

Como funcionam os créditos do Lovable

O Lovable cobra por trabalho executado. Na documentação oficial de créditos e uso, consultada em outubro de 2026, o modo de plano custa 1 crédito por mensagem, mais o custo da pesquisa extra que ele rodar enquanto planeja. O modo de build, que é o que mexe no código, não tem preço fixo: o custo depende da complexidade do pedido e do trabalho feito.

A própria documentação dá exemplos ilustrativos de quanto cada pedido come dos créditos do Lovable. Deixar um botão cinza aparece custando 0,50 crédito. Montar uma landing page com imagens aparece custando 2,00. E ela avisa que são exemplos, que o gasto real varia com o tamanho e o escopo de cada projeto.

Dois detalhes da regra mudam o jeito de gerenciar os créditos do Lovable. Pedido interrompido no meio cobra só o trabalho feito até ali. E pedido parado antes de qualquer mudança no projeto não cobra nada. Ou seja, o medidor gira enquanto o agente trabalha, não enquanto você digita.

A âncora que eu uso com o time é simples. O Lovable é o pedreiro por empreitada. Com a planta pronta, ele levanta a parede uma vez. Com a planta pela metade, cada “quebra e faz de novo” sai do seu bolso. Os créditos do Lovable são a mão de obra, e mão de obra paga pra refazer é dinheiro rasgado.

Onde os créditos do Lovable somem

Quando eu fui olhar pra onde iam os créditos do Lovable da minha operação, achei três ralos. Nenhum deles é culpa da ferramenta. Todos são culpa do jeito de pedir.

O pedido vago

“Dá uma melhorada.” “Deixa mais profissional.” “Arruma esse layout.” Esse é o pedido que mais queima créditos do Lovable, porque o agente precisa adivinhar o estado final. Ele adivinha, você não gosta, e a segunda rodada é paga. A terceira também.

Se você não der contexto pra máquina, ela é burra. E máquina burra cobrando por hora é a pior combinação que existe numa operação. Se quem pede não sabe descrever o resultado, ainda não é hora de pedir.

O loop de bug

O sistema quebra. A pessoa escreve “não funcionou, tenta de novo”. O agente tenta, erra de outro jeito, e a pessoa repete. Cada volta dessas consome créditos do Lovable, e saída que falhou cobra igual saída que deu certo.

Na prática, o gestor só percebe o loop quando o saldo zera no meio da tarde.

O pedágio de plano que ninguém pediu

Esse é o ralo mais escondido. Quando o agente acha a tarefa grande, ele para e devolve um plano pedindo aprovação. Você aprova, ele cobra a rodada do plano, e só então começa a trabalhar. Num dia de setembro, numa rodada de 22 créditos, 8,9 foram esse pedágio: 40% do gasto do dia antes da primeira linha de código.

Por isso eu não acho que o problema seja preço. Tem muita gente procurando créditos do Lovable mais baratos, e entendo o motivo. Só que crédito barato num processo furado é gasolina com desconto num carro com o tanque vazando. Você paga menos por litro e anda o mesmo tanto.

O guardrail que segura os créditos do Lovable antes do build

Guardrail é o arquivo de regras que faz a IA travar antes de fazer besteira. Se o termo é novo pra você, eu explico o conceito inteiro no guia de guardrails de IA para quem não é dev. Aqui eu mostro o que o meu guardrail de Lovable faz na prática.

A regra mãe dele cabe numa frase: o que é grátis se esgota antes do que é pago. Pensar, decidir e escrever o pedido acontece fora do Lovable, numa IA de conversa ou na cabeça de quem pede. No Lovable entra só execução. Toda dúvida que chega lá vira iteração paga nos créditos do Lovable, e dúvida se mata antes, de graça.

Pro time decorar, a régua de bolso tem quatro linhas:

• Troca de texto na tela usa a edição direta, que tem cota grátis renovável, sem mandar mensagem pro agente.
• Ajuste de uma linha vai pelo editor de código, por quem sabe mexer, também sem acionar o agente.
• Decisão de arquitetura vai pro modo de plano, que custa 1 crédito fixo e não toca no código.
• Mensagem de build fica só pro que sobrou depois das três de cima.

Antes do primeiro crédito de um projeto novo, o guardrail exige que estas respostas existam por escrito:

• Que tipo de peça é: proposta, painel, página, ferramenta interna.
• Cores, logo e fonte já decididos. Cada “não gostei” é refação paga.
• Se a tela nasce pensada pro celular ou pro computador.
• O texto real da página. Texto provisório gera uma segunda rodada só pra trocar o texto.
• Um exemplo realista do dado que a tela vai mostrar.
• Título, descrição e prévia de link próprios, pedidos já no primeiro prompt.

Faltou uma resposta, o pedido não sai. A pergunta se faz antes, onde não custa nada.

Tem mais duas regras que pagam o arquivo sozinhas. A primeira: mudança de tela se desenha antes, num rascunho simples, e o desenho aprovado vira o próprio pedido. Isso mata a rodada de “não gostei”, que é a mais cara de todas, porque refazer layout mexe em componente inteiro. A segunda: todo pedido termina com duas frases, “aplique direto, não pare pra aprovação de plano” e “não crie arquivo de plano”. Foi assim que o pedágio do plano saiu da minha conta de créditos do Lovable.

E todo pedido de mudança declara o que não pode ser tocado. Sem cerca, o agente reescreve o vizinho, e o conserto do vizinho também é pago.

O loop de bug e a regra que para ele

A regra é seca: proibido “ainda não funcionou, tenta de novo”. No lugar dela, o guardrail manda um ciclo de cinco passos.

• Diagnóstico grátis primeiro. Ler o código e o dado antes de perguntar. Ler não custa crédito. Perguntar custa.
• Se precisar do agente, pedido de diagnóstico somente leitura. Proibido editar. O pedido exige o erro literal, a causa e a correção mínima.
• A correção vai com escopo estrito. “Altere só este arquivo e preserve o resto.”
• Deu errado de novo, volta a versão. O histórico de versões desfaz sem custo. Empilhar remendo em cima de remendo é o caminho mais caro.
• Erro de build trivial usa o conserto grátis do editor antes de gastar mensagem.

Esse último item tem número na documentação de segurança do Lovable: a conta tem 10 consertos grátis, compartilhados entre o “Try to fix” de erro de build e o conserto em lote dos achados de segurança. Cada um volta a ficar disponível 24 horas depois do uso. Passou dos 10, o conserto vira uso normal e consome créditos do Lovable.

Duas armadilhas completam a regra. A tela que demora não quer dizer pedido perdido: o agente pode estar trabalhando, e reenviar o mesmo pedido paga o build duas vezes. Confere o histórico antes de repetir. E quando a rodada fecha, alguém lê o que mudou, arquivo por arquivo. O agente também erra pra mais. Ele mexe no que ninguém pediu e entrega embrulhado como conserto.

Segurança também consome créditos do Lovable

Aqui mora um detalhe que pouca gente lê. Pela mesma página de segurança, as varreduras automáticas são grátis: rodar a varredura rápida ou a profunda não conta como uso de build. Já pedir no chat “revise a segurança do meu app” vira uso de build e consome crédito. Fazer pergunta de segurança no chat, idem.

Então a ordem importa, porque os créditos do Lovable gastos em conversa de segurança poderiam ter saído de graça. Primeiro a varredura grátis. Depois, só se sobrar dúvida, a conversa paga. O guardrail grava essa ordem pra ninguém ter que lembrar.

O Lovable é seguro?

A resposta honesta: a ferramenta ajuda, e a responsabilidade é sua. A própria documentação diz que as varreduras identificam problemas comuns, mas não garantem segurança completa. E diz, com todas as letras, que é você quem responde por fazer o app atender às exigências de segurança do uso que ele tem.

Tem um caso público que mostra por que isso pesa. O registro CVE-2025-48757, da base nacional de vulnerabilidades dos Estados Unidos, descreve uma política de acesso insuficiente no banco de dados de sites gerados pelo Lovable até 15 de abril de 2025, que permitia a quem não estava logado ler ou escrever em tabelas do banco. O mesmo registro anota que o Lovable contesta a vulnerabilidade, porque cada cliente da plataforma assume a responsabilidade de proteger os dados da própria aplicação.

Repara no que os dois lados concordam. Quem acusou e quem se defendeu chegaram no mesmo ponto: o dado do seu cliente é problema seu. Se o seu app guarda nome, telefone e e-mail de lead, a pergunta “o Lovable é seguro?” vira “a minha regra de acesso está certa?”.

Eu já escrevi sobre os furos mais comuns em segurança de aplicativo feito com IA e sobre o que muda quando o time faz vibe coding com segurança. No guardrail de Lovable, a parte de segurança se resume a quatro regras que o gestor entende sem ser técnico:

• Senha na tela é porta, não cofre. Tela de login sozinha não protege dado se o navegador conversa direto com o banco.
• Regra de acesso aberta só pra conteúdo que pudesse ir num outdoor. Se você não colaria aquele dado na avenida, a tabela não fica aberta.
• Chave de API nunca no código que roda no navegador. A documentação do Lovable diz o mesmo e manda guardar em Secrets.
• Nome de regra não é documentação. Quem audita lê o que a regra faz, não o que o nome dela promete.

Antes do próximo crédito

Os créditos do Lovable que somem não somem por azar. Eles saem pelos mesmos três ralos em toda operação: pedido vago, loop de bug e plano pago que ninguém pediu. O guardrail fecha os três antes do build, porque decide o que se resolve de graça, o que vai pro modo de plano e o que merece mensagem paga. De quebra, ele bota a segurança na ordem certa: varredura grátis primeiro, conversa paga depois.

E nada disso é exclusivo do Lovable. Qualquer ferramenta que cobra por pedido premia quem chega com a planta pronta e pune quem chega com “dá uma melhorada”. Os créditos do Lovable são só o exemplo mais visível. O arquivo de regras vale pra ferramenta que você usar amanhã.

Perguntas frequentes

Como funcionam os créditos do Lovable?

O Lovable cobra por trabalho executado. O modo de plano custa 1 crédito por mensagem, mais a pesquisa extra que ele fizer. O modo de build varia com a complexidade do pedido, e o custo exato de cada mensagem aparece no menu abaixo da resposta.

Os créditos do Lovable acumulam de um mês pro outro?

Os créditos mensais do plano que sobram passam pro ciclo seguinte enquanto a assinatura estiver ativa. Pela documentação, consultada em outubro de 2026, eles vencem 2 meses depois de emitidos no plano mensal.

O Lovable é seguro?

A ferramenta tem varreduras automáticas de segurança, mas a própria documentação diz que elas não garantem segurança completa. A responsabilidade pelo dado do app é de quem o publica, então a regra de acesso ao banco precisa ser revisada antes de guardar dado de cliente.

Como gastar menos créditos do Lovable?

Decida tudo antes do primeiro build: tipo de peça, visual, texto real e dado de exemplo. Use o modo de plano pra decisão de arquitetura, nunca repita “tenta de novo” num erro e volte a versão em vez de empilhar remendo.