Se você chegou aqui, provavelmente já bateu na parede dos limites de uso do Google Antigravity e ficou com a sensação de que “gastou mais do que devia”. No meu canal, vinha mencionando que a cota do Antigravity era muito generosa, e a conta veio: recentemente, o Google alterou as cotas do Antigravity e muita gente sentiu a mudança.
Particularmente, eu uso a conta Gemini Pro e até com a conta paga, a limitação das cotas é visível. E outros desenvolvedores estão enfrentando o mesmo problema.
Esse post é uma continuação de “Como Otimizar o Uso de Tokens e Créditos no Google Antigravity”. Lá eu cobri o lado das boas práticas de prompt, contexto e falei de uma parte importante deste quebra-cabeça: as requisições. Aqui, o foco é outro: como a cota é realmente calculada, por que ela esgota tão rápido e quais ajustes no seu fluxo de trabalho te dão mais tempo útil na ferramenta.
A primeira confusão: compute, não tokens
A maioria das pessoas assume que o Antigravity cobra por tokens, como a interface web do Gemini, do Claude ou do ChatGPT. Não é assim que funciona. O Google calcula o uso com base no trabalho computacional que o modelo precisa realizar, não na quantidade bruta de tokens que entram e saem.
Isso explica por que:
- O autocomplete no editor praticamente não move a agulha.
- Conversas curtas no chat consomem muito pouco.
- Planejamento de arquitetura, edições em múltiplos arquivos e varredura de repositório drenam a cota rapidamente.
- Loops no terminal e automação de browser são, de longe, as operações mais caras.
Ou seja: a mesma “tarefa” pode ter custos radicalmente diferentes dependendo de quanto esforço o agente precisa investir para concluí-la.
As cotas que você precisa conhecer
Segundo a documentação atual dos planos do Antigravity, o sistema tem dois limites que rodam em paralelo:
- 250 unidades de uso cada 5 horas, por provedor de modelo. Esse é o ciclo curto, rolling — ele se regenera à medida que o tempo passa.
- 2.800 unidades de uso por semana. Esse é o teto duro. Mesmo que o ciclo de 5 horas se reinicie, se você estourou o teto semanal, fica travado até a semana virar.
A confusão típica aparece exatamente aqui: o desenvolvedor espera as 5 horas, volta para trabalhar, e descobre que ainda está bloqueado porque o limite semanal já tinha estourado. Vale revisitar isso antes de culpar a ferramenta.
Multiplicadores por modelo
Outro ponto que o painel não deixa óbvio: cada modelo consome a cota em ritmos distintos. Tomando o Claude Sonnet como linha de base, a lista aproximada (confirmada nas discussões oficiais e na página de modelos) fica mais ou menos assim:
| Modelo | Consumo relativo | Quando faz sentido |
|---|---|---|
| Gemini Flash | ~10× mais barato que Sonnet | Execução de tarefas bem definidas, boilerplate, loops curtos |
| Gemini Pro | ~1,5× Sonnet | Raciocínio intermediário, análise de código |
| Claude Sonnet 4.6 | 1× (baseline) | Driver do dia a dia para trabalho agêntico consistente |
| Claude Opus | ~8× Sonnet | Raciocínio pesado pontual — nunca para tarefas repetitivas |
Esse fator é o que mais pega a gente de surpresa. Rodar Opus em uma automação de browser pode esgotar a cota semanal inteira em cerca de 40 minutos, enquanto o Gemini Flash faria o mesmo trabalho consumindo uma fração ínfima.
Os dois gatilhos de lockout imediato
Existem duas situações em que o Antigravity não só consome a cota — ele bloqueia a conta na hora, independentemente do que restava:
- Loops em terminal com permissão “always allow”. Um agente preso em um ciclo de debug pode queimar a semana inteira em um único prompt. Parece conveniente deixar o agente com todas as permissões, mas isso pode criar um problema se ele entrar em loop — e acredite, isso é algo super comum. Nunca deixe o Fast Mode rodando comandos em loop sem supervisão.
- Automação externa encadeando prompts. Ferramentas como n8n, Make ou scripts próprios que disparam prompts no Antigravity são detectadas pela plataforma e geram bloqueio imediato. O Google é explícito: o Antigravity não é uma API para encadeamento externo.
Esses dois casos não aparecem na barra de cota. Eles simplesmente derrubam o acesso.
Ajustando o fluxo de trabalho
Entender o mecanismo é metade do caminho. A outra metade é redesenhar o fluxo para gastar menos computação por tarefa.
1. Combine modelo e tarefa
A regra mais importante: Sonnet 4.6 em Fast Mode é o driver diário, Opus entra só quando a tarefa exige raciocínio profundo, e Flash assume qualquer coisa que seja execução determinística. Se você está usando Opus para gerar CRUD, preencher boilerplate ou percorrer arquivos, está pagando 8× o preço por um ganho que não existe.
2. Restrinja o contexto com @mentions
Mesmo sem ser token-based, o tamanho do contexto ainda escala o custo porque o modelo precisa processar mais material. Use o comando @ para fixar exatamente o arquivo que você quer editar em vez de deixar o agente varrer o repo. Um endpoint de API não precisa do tema inteiro do WordPress carregado. Combine isso com o .geminiignore do post anterior e o ganho é significativo.
3. Mantenha um arquivo de session state
Uma prática que mudou completamente o meu consumo: antes de encerrar cada sessão, eu peço para o agente escrever um SESSION_STATE.md curto com o que foi feito, o que falta, decisões tomadas e próximos passos. Na sessão seguinte, o agente lê esse arquivo e retoma o trabalho — sem arrastar o histórico inteiro da conversa, sem refazer análises e sem pagar de novo por contexto que já tinha sido processado.
O mesmo arquivo serve como ponte entre modelos e entre ferramentas: você pode começar no Antigravity com Sonnet, passar para o Gemini CLI no terminal, voltar para o Antigravity com Flash, e todos têm o mesmo ponto de partida.
4. Rotacione entre modelos e ferramentas
As cotas são contadas por provedor. Se o pool do Claude estiver travado, mude para o pool do Gemini. Se os dois acabarem, vá para fora do Antigravity: o Gemini CLI no terminal é gratuito até 1.000 requisições por dia, e serviços como Arena AI ou GenSpark dão acesso a modelos pesados sem tocar na cota da IDE. O SESSION_STATE.md permite que qualquer um desses ambientes retome o trabalho de onde você parou.
5. Planeje fora do Antigravity
Planejamento é a atividade que mais consome compute: muitas idas e voltas, muito raciocínio, muitos tokens de reasoning. A sacada é: faça o planejamento em outro lugar e traga só o plano final para o Antigravity executar.
Meu fluxo padrão hoje é usar Arena AI (ou Gemini diretamente no AI Studio) para discutir arquitetura, listar tarefas e definir decisões com Opus 4.6 ou Gemini 3 Pro. Quando o plano está fechado, entro no Antigravity com Flash ou Sonnet e deixo o agente executar apenas. Isso economiza facilmente metade da cota semanal.
6. Crie documentações locais
Evite usar a ferramenta de consulta na web; isso consome requisições extras. Se algo é importante para o seu projeto e você vai consultar com frequência, crie uma pasta docs e salve em Markdown os arquivos relevantes. Eles podem ser referenciados no seu GEMINI.md, economizando tanto as requisições de busca quanto o compute gasto para processar páginas web inteiras a cada pergunta.
Conclusão
O Antigravity, com as mudanças recentes, trouxe a sensação de estar usando um jogo sempre na versão demo. Mas essa limitação quase sempre decorre de três causas combinadas: deixar o agente em loops desnecessários, fazer o agente varrer o repositório inteiro a cada prompt e fazer planejamento dentro da ferramenta, em vez de fora dela. Corrigindo esses três pontos, o plano Pro entrega sem esforço de 40 a 80 horas semanais de trabalho agêntico que o Google anuncia.
Se este post foi útil e você quer o outro lado da moeda, o nível de sintaxe do prompt e da configuração do projeto, vale passar no Como Otimizar o Uso de Tokens e Créditos no Google Antigravity. Os dois juntos cobrem o fluxo inteiro.
Deixe um comentário