Agentes de IA no Notion a $340/mês: limitar ou reconstruir?

Em 3 de maio, meus agentes de IA no Notion custavam $0. Em 4 de maio, esses mesmos agentes começaram a consumir créditos a $10 por 1.000, e a primeira projeção indicou cerca de $340/mês para o meu OS de clientes se eu não mudasse nada.

O dia em que o contador começou a rodar

Eu vinha usando Notion Custom Agents em um workspace real de operações com clientes — o OS de clientes da DVNC — durante a segunda metade do beta gratuito. Havia um agente de triagem lendo os briefings recebidos, um agente de resumo diário consolidando o andamento dos projetos ativos e um agente de sincronização mantendo algumas bases de conhecimento compartilhadas alinhadas às páginas que serviam como fonte oficial. Eram três agentes sempre ativos, além de alguns outros acionados sob demanda. Custo: zero.

Em 4 de maio de 2026, o Notion ligou o contador. Os Custom Agents saíram do beta gratuito e chegaram à disponibilidade geral com cobrança por uso: $10 a cada 1.000 créditos do Notion, além da assinatura por usuário e exclusivamente nos planos Business e Enterprise. Não existe downgrade que preserve o recurso — os planos Plus e Free nunca ofereceram Custom Agents, então “descer de plano para manter o recurso” simplesmente não é uma opção. Ou o workspace está no Business+ e paga pelo consumo, ou fica sem o recurso.

Nas primeiras 48 horas após a mudança, deixei os agentes rodarem sem nenhum ajuste de propósito: eu queria dados reais de consumo, não mais uma projeção. Um operador que acompanho divulgou um número de cerca de $337 gastos em um único mês com uma configuração comparável. O valor ficou muito próximo da minha própria projeção para 30 dias, o que confirmou que o consumo não era um erro de configuração. Era o novo piso.

É justamente isso que a maioria dos resumos de preços deixa escapar. O dia 4 de maio não marcou um aumento de preço. Aumento é quando uma linha da planilha passa de $40 para $55 e o orçamento precisa ser atualizado. Aqui, houve uma transição do gratuito para o uso medido — outra categoria de mudança. Todas as premissas de custo embutidas na configuração, na frequência e no escopo dos agentes ficaram erradas de uma hora para outra, porque cada decisão havia sido tomada sob a premissa de que “o custo dos créditos é zero”. A primeira tarefa não era cortar gastos, mas redesenhar o workflow a partir de uma premissa que deixara de existir. O Notion fez algo estruturalmente parecido para desenvolvedores no começo do ano (veja o salto no custo de créditos para agentes externos); o padrão já era visível, mas reconhecer o padrão não paga a conta.

Para onde foram os créditos dos agentes de IA no Notion

A primeira medida realmente útil foi instrumentar o consumo por agente. A interface do Notion mostra o uso de créditos no nível do workspace, mas não entrega, por padrão, uma divisão clara que revele onde cada agente fez o contador girar. Os créditos são compartilhados pelo workspace e reiniciados todo mês. Isso parece neutro até ficar claro que um agente ruidoso cobra silenciosamente uma taxa de todos os outros workflows de IA no mesmo ambiente.

Três agentes responderam por cerca de 70% do consumo. Não cinco, nem oito. Três.

O agente de triagem e entrada — responsável por consultar uma página compartilhada e classificar novos briefings — era, de longe, o pior caso. Ele estava configurado para verificar a página a cada 15 minutos, 24/7. Na maior parte das vezes não havia nenhuma novidade, mas cada execução ainda consumia créditos. O polling ocioso sobre dados inalterados é a armadilha. O agente fazia exatamente o que eu havia pedido — e o pedido ficou caro assim que o contador foi ligado.

O agente de resumo diário dos clientes ocupava a segunda maior linha. Era uma execução por projeto ativo, por dia, distribuída por toda a lista de clientes em andamento. O custo unitário fazia sentido; o problema era o volume. Multiplicar um valor razoável por execução pelo número de projetos e por 30 dias resultou em um custo mensal que, sozinho, superava todo o gasto do mês anterior com licenças do Notion.

O agente de sincronização de documentos ficou em terceiro — e era o caso mais interessante. Cada execução era a mais barata entre os três, mas o gatilho eram as edições. Uma única sessão humana editando uma página compartilhada podia acioná-lo uma dúzia de vezes. Na prática, o agente estava com a frequência atrelada à velocidade de digitação de uma pessoa, uma escolha de configuração que ninguém faria de propósito a $10 por 1.000 créditos.

A conta mensal aproximada, reconstruída com base nos primeiros dez dias após a virada e extrapolada, ficou assim. Agente de triagem: ~$160/mês na frequência de polling que eu usava. Agente de resumo: ~$95/mês com o número atual de projetos. Sincronização de documentos: ~$45/mês com o volume de edições observado. Os ~$40/mês restantes estavam distribuídos entre quatro agentes mais leves. Total entre $335 e $345, coerente com o número público que eu havia visto de outro operador com um workspace de perfil semelhante.

Esse valor se soma a uma stack de operações sobre a qual já escrevi — veja a base de $387/mês — e acrescentar uma linha de $340 àquele patamar levaria toda a stack além de um limite que eu havia definido explicitamente. Portanto, não era “um pequeno excedente que dá para absorver”. Era um problema estrutural.

A decisão em três caminhos

Havia três caminhos, cada um sustentado por números reais, e apenas um fazia sentido para a minha carga de trabalho específica. Os mesmos números podem levar outra pessoa a uma conclusão diferente — esse é justamente o motivo para fazer a conta em vez de aceitar uma recomendação pronta.

Caminho A — manter tudo no modelo por consumo, sem mudar nada. Essa é a escolha certa quando há poucas execuções, o valor de cada uma é alto e a previsibilidade da fatura importa menos do que conter o custo absoluto. Em um workspace com poucas execuções de alto valor por dia — por exemplo, um agente que entrega um resultado bem delimitado e poupa uma hora de trabalho — a cobrança por uso funciona. O problema não está nos $10 por 1.000 créditos; está em manter agentes cuja conta não fecha a nenhum custo por execução. Meu teto para deixar tudo nesse modelo seria de cerca de $80/mês naquele workspace, considerando o que ele produz. A projeção era quatro vezes maior. O caminho A estava descartado.

Caminho B — impor limites e redefinir o escopo. Eliminar todo polling permanente. Trocar gatilhos por intervalo por eventos ou acionamento manual. Substituir o agente de resumo, que rodava uma vez por projeto, por uma única execução diária em lote, com uma saída consolidada. Configurar debounce no agente de sincronização para que ele seja acionado uma vez por sessão de edição, não a cada alteração. A nova projeção ficou em aproximadamente $70–$85/mês — abaixo do teto, mantendo as entregas essenciais, mas com uma perda perceptível da sensação de resposta “instantânea” na triagem. Agora, o agente de triagem roda a cada duas horas, em vez de a cada quinze minutos. Esse atraso tem um custo real de produto, e eu precisava encará-lo com honestidade.

Caminho C — reconstruir em infraestrutura própria. Retirar o agente mais pesado — o de triagem — do Notion e refazê-lo fora da plataforma: um Cloudflare Worker agendado por cron, chamando Claude diretamente e gravando os resultados de volta na página do Notion via API. Custo inicial de desenvolvimento: cerca de 6–8 horas de trabalho concentrado para alguém que já construiu esse tipo de solução — como eu. Custo recorrente: o plano do Worker que já pago, mais os tokens da API do Claude, que ficam na faixa inferior de um dígito em dólares por mês com esse volume. Há fundadores operando stacks comparáveis de agentes self-hosted em público, e a conta fecha quando o volume de execuções ultrapassa o ponto de equilíbrio.

O cálculo do ponto de equilíbrio é a única parte que importa. No ritmo do meu agente de triagem, o custo medido pelo Notion era de ~$160/mês. Em infraestrutura própria, o custo recorrente seria de ~$4/mês. Amortizando o desenvolvimento por 12 meses, a uma taxa interna generosa de $150/hora, são ~$100/mês no primeiro ano quando contabilizo meu tempo com rigor. Custo total da reconstrução no primeiro ano: ~$104/mês, contra ~$160/mês no modelo medido. Do segundo ano em diante: ~$4/mês, contra ~$160. A reconstrução se paga ainda no primeiro ano e amplia a vantagem depois disso.

A mesma disciplina de P&L operacional que apliquei à oferta do Codex vale aqui, mas do outro lado da decisão. Lá, eu avaliava se deveria trocar de ferramenta por causa de um incentivo gratuito; aqui, avalio se devo reconstruir um sistema em torno de uma ferramenta cuja lógica econômica mudou sob os meus pés. O framework é o mesmo, mas a direção é oposta.

Minha decisão: um modelo híbrido. Reconstruir o agente de triagem em um Worker — o caminho C aplicado apenas à linha individual mais pesada. Limitar e redefinir o escopo dos agentes de resumo e sincronização — o caminho B para os intermediários. Manter os quatro agentes mais leves totalmente no modelo por consumo — o caminho A para a cauda longa.

Com o modelo híbrido, o custo mensal projetado cai para $45–$55 depois que a reconstrução entra em produção, além de um custo pontual de cerca de 7 horas. Na comparação com a projeção de $340 sem nenhuma mudança, isso representa uma economia aproximada de $290/mês pelo custo de uma sessão concentrada de desenvolvimento. A curva de custos em 30/60/90 dias fica assim: o primeiro mês absorve as horas de reconstrução e opera parcialmente no modelo medido ($110 em custo real equivalente, contando o tempo); o segundo mês chega perto do estado estável ($55); o terceiro atinge esse estado ($45).

O que eu faria diferente — e a parte que me deixa um pouco constrangido — seria medir os créditos por agente desde o primeiro dia do beta, não depois que a cobrança começou. O período beta era a janela gratuita em que eu poderia ter calculado com precisão quanto cada agente custaria sob o futuro modelo por consumo — o Notion publicou as tarifas de créditos com bastante antecedência —, mas tratei “gratuito” como “não é preciso medir”. Reconstruir o consumo por agente depois da mudança deu mais trabalho do que medi-lo em tempo real teria dado. Hoje, aplico essa regra em todo lugar.

A regra que aplico antes de deixar qualquer agente sempre ativo

A conclusão não é que “Notion Custom Agents são caros demais”. Alguns dos meus agentes continuam rodando em Custom Agents e permanecerão ali. A lição é mais específica — e mais útil: automação em beta gratuito é um passivo no seu grafo de dependências, não um recurso.

Quando um fornecedor oferece um recurso de automação sem cobrança por uso durante o beta, na prática ele está dando uma opção gratuita para que o workflow seja amarrado a um modelo de preços que ainda nem existe. Assim que esse modelo aparece, restam duas escolhas: aceitar os números que vierem ou reconstruir tudo sob pressão. O momento barato para fazer esse trabalho é antes de o contador começar a rodar, não depois.

Este é o teste que passei a aplicar antes de conectar qualquer automação beta gratuita a um caminho crítico:

1. Calcule o preço da versão medida antes que a cobrança exista. Se o fornecedor ainda não publicou as tarifas, modele um cenário plausível com base em produtos comparáveis e verifique se a conta do agente ainda fecha.
2. Meça o custo por execução desde o primeiro dia. Trate o período gratuito como uma janela de medição, não como almoço grátis.
3. Defina a rota de reconstrução antes de precisar dela. Saiba quais agentes seriam refeitos em infraestrutura própria se a lógica econômica mudasse e estime quantas horas esse desenvolvimento consumiria.
4. Limite a frequência permanente ao maior intervalo aceitável. Se um polling a cada 2 horas atende à operação, não o configure para 15 minutos só porque é possível. A frequência é um botão de custo: reduzi-la não custa nada durante o beta, mas sai caro depois, porque até lá as pessoas já criaram hábitos em torno da resposta mais rápida.

O modelo híbrido que adotei para o OS de clientes não é elegante. Manter três modelos de custo em paralelo dentro de um único workspace exige mais configuração do que eu escolheria em um projeto novo. Ainda assim, ele corresponde ao formato real do trabalho e traz o valor mensal de volta para dentro do teto que defini para esse workspace antes de a cobrança começar. Esse é o único teste que importa.

Automação em beta gratuito é um passivo, não um recurso. Calcule seu preço antes de conectá-la ao workflow — ou prepare-se para reconstruí-la sob pressão depois que outra pessoa tomar a decisão por você.

Quanto custam os Notion Custom Agents depois de 4 de maio de 2026?

$10 por 1.000 créditos do Notion, cobrados junto com a assinatura. O recurso está disponível apenas nos planos Business e Enterprise — Free e Plus nunca incluíram Custom Agents.

Posso manter os Custom Agents no plano Plus para evitar os créditos?

Não. Os Custom Agents nunca estiveram disponíveis nos planos Free ou Plus, portanto não existe downgrade que preserve o recurso. Ou o workspace está no Business+ e paga pelo consumo, ou fica sem os agentes.

O que acontece quando os créditos de um workspace acabam?

Os Custom Agents param. Outros recursos do Notion AI, como Meeting Notes e o Notion Agent padrão, continuam funcionando até o limite de uso justo do plano contratado.

Sai mais barato reconstruir agentes em infraestrutura própria?

Somente depois que o volume de execuções ultrapassa o ponto de equilíbrio. Abaixo dele, o custo dos créditos medidos é menor do que as horas de desenvolvimento e manutenção. Acima — especialmente para agentes sempre ativos que disparam muitas vezes por dia —, a infraestrutura própria amplia a vantagem a partir do segundo ano.