Lovable lança limite de créditos por membro e projeto

No dia 7 de outubro de 2026, o Lovable registrou no changelog uma novidade para quem divide workspace, projetos e membros: limites e alertas de uso de créditos. Owners e admins de planos pagos agora definem um teto de gasto por workspace, por projeto ou por membro, e escolhem o que acontece quando o teto chega: um aviso ou um bloqueio.

Este texto é um primeiro olhar, feito a partir do changelog e da documentação oficial do recurso. Você vai ver como a configuração é organizada, o que cada bloqueio pausa de verdade e os pontos que a documentação trata com cuidado e que o anúncio resume em uma linha.

O que mudou

O recurso fica em Workspace settings, na seção Usage limits & alerts, e reúne duas ferramentas diferentes.

Os limites de uso disparam quando os créditos gastos num período chegam a um valor que você escolheu. A ação pode ser e-mail, notificação no app, bloqueio ou uma combinação deles.

Os alertas de saldo disparam quando o saldo do workspace cai abaixo de um valor, em créditos fixos ou em percentual dos créditos concedidos. Eles só avisam e nunca bloqueiam.

Quem configura são owners e admins. Editores enxergam os limites que se aplicam a eles e aos seus projetos, mas não alteram nada. Criar limites e alertas exige plano pago.

Onde o limite pode ser aplicado

Cada limite tem um escopo:

Limite padrão não funciona como um pote compartilhado. Cada projeto ou membro recebe a própria cota. Um limite específico só sobrepõe o padrão quando o tipo de crédito e o período são os mesmos.

Limites por grupo e por token de acesso exigem os planos Business ou Enterprise.

Build e Run: dois ramos de crédito

A documentação separa o consumo em dois ramos. Build é construir e editar apps, conversar com o agente e gerar imagem e vídeo. Run é o uso do app já publicado, dividido em Cloud, AI e Connectors.

A divisão decide o que um limite alcança. Limites por usuário e por grupo contam só Build, porque o uso de Run pertence ao projeto e não à pessoa. Para colocar um teto no gasto do app em produção, o escopo certo é projeto ou workspace.

Períodos e quando o contador zera

Há dois períodos, mensal e diário. O mensal reinicia no dia 1 de cada mês às 00:00 UTC, independente da data de cobrança do seu plano. O diário reinicia às 00:00 UTC. No horário de Brasília, isso cai às 21:00 do dia anterior.

Alerta ou bloqueio

Um limite com bloqueio entra num estágio chamado Approaching quando o gasto chega a 80% do valor, desde que as notificações estejam ligadas. Cada notificação sai uma vez por mudança de estado, sem repetição. O aviso vai para owners e admins e para a pessoa mais próxima do limite: o membro afetado, quem criou o projeto ou o dono do token.

Quando o bloqueio entra em vigor, o efeito depende do tipo escolhido:

Só Block building e Block all usage impedem as pessoas de construir no Lovable. Os demais deixam o editor funcionando.

Três pontos que pedem leitura com calma

Pause Cloud alcança o app publicado. Pausar o Cloud mexe no backend de todos os projetos cobertos, inclusive os que já estão no ar. Login, banco de dados e storage deixam de funcionar para os usuários do app. A documentação é explícita: nada é apagado, e os arquivos continuam consumindo créditos. Se você publicou um SaaS como o da parte 5 da série Construindo um SaaS do zero, um limite de Cloud com bloqueio mal calculado tira o produto do ar para o cliente.

Comprar crédito não destrava o bloqueio. O limite conta créditos já gastos no período, então adicionar créditos ou trocar de plano não o levanta. O bloqueio sai quando o período reinicia, quando você aumenta o limite, desliga o bloqueio ou apaga o limite.

O gasto pode passar um pouco do teto. O uso é registrado antes de ser avaliado, e a documentação avisa que o consumo pode ultrapassar levemente um limite rígido. Trate o teto como uma cerca com folga e deixe uma margem entre o limite e o valor que você aceita gastar.

Pedidos de aumento

Quando um membro bate num limite com bloqueio, ele escolhe Request an increase, informa um novo valor e, se quiser, um motivo. Owners e admins recebem a notificação Limit increase requested e revisam na aba Requests, onde aprovam ou negam.

A aprovação pode valer por tempo indeterminado ou até o fim do período de uso, caso em que o limite aparece com a marca Temporary until. Aprovar o pedido de um limite padrão cria uma exceção só para aquele membro ou projeto. Limites de grupo e de token de acesso não aceitam pedidos de aumento.

Detalhes de operação

A documentação fala em até 500 limites por workspace, e limites não atravessam workspaces. No topo da tela há um cartão Requires attention com os limites disparados ou próximos de disparar, além de filtros por status, período e tipo de crédito.

Editar um limite muda valor e comportamento. Escopo, tipo de crédito e período ficam fixos, então mudar um deles exige criar outro limite. Apagar é permanente.

Workspaces Enterprise já começam com dois alertas de saldo por e-mail, em 25% e 10% dos créditos concedidos.

Quem deve configurar agora

Quem tem time ou projetos de clientes no mesmo workspace é o público mais óbvio. Um limite mensal de Build por membro evita que uma sessão longa de prompts consuma o saldo de todos.

Quem tem app publicado gastando crédito de Run, com Cloud e AI, ganha um alerta de saldo e um limite de projeto só com notificação antes de qualquer bloqueio. Notificação primeiro, bloqueio depois que o padrão de consumo estiver claro.

Quem trabalha sozinho num plano pago pode começar com um alerta de saldo e parar por aí. Para cruzar o gasto com o custo total de operar um produto, vale ler Quanto custa rodar um micro SaaS feito com IA em 2026.

O que ainda precisa provar

Três pontos ficam em aberto até o uso real. O primeiro é quanto o consumo passa do teto na prática, já que o registro vem antes da avaliação. O segundo é como o fluxo de pedidos de aumento se comporta quando o admin demora a responder. O terceiro é como os limites de Cloud, AI e conectores se comportam em apps com tráfego real, que é o cenário de maior risco para quem tem cliente usando.

O que fazer agora

1. Abra Workspace settings, depois Usage limits & alerts, e confira o cartão Requires attention.
2. Crie um alerta de saldo antes de qualquer limite com bloqueio, com um percentual dos créditos concedidos que combine com o seu ritmo.
3. Defina um limite mensal padrão de Build por membro, só com notificação, e observe o consumo por duas semanas.
4. Configure bloqueio depois disso, e prefira Block building a Pause Cloud em projetos que já atendem clientes.
5. Releia as 7 regras para prompts no Lovable que não quebram o projeto para gastar menos crédito por tarefa.