Agentes de IA com Trigger Dev: tarefas, limites e preços

Trigger Dev: o que ele substitui?

Trigger.dev reúne executor de tarefas, filas, agendamento, deploy e painel de execuções. Você escreve uma função assíncrona, envia um payload e deixa um worker separado executá-la enquanto seu aplicativo devolve uma resposta ao usuário. Ele pode substituir a infraestrutura que você precisaria montar para rodar tarefas em segundo plano; não substitui o banco de dados do aplicativo, as regras de negócio nem o modelo responsável pelas decisões de um agente de IA.

Verificado na documentação pública, nos preços, no changelog e no repositório GitHub em 11 de novembro de 2026. Esta avaliação se baseia na documentação, sem teste em uma conta autenticada nem benchmark de desempenho. A recomendação considera quem opera o ambiente de execução, os limites de recuperação de falhas, a facilidade de uso para quem opera o processo e as restrições de produção.

O changelog de lançamento da v4, de 18 de agosto de 2025, trouxe warm starts, waitpoints para aprovações e callbacks, filas com prioridade, mudanças no painel e hooks de ciclo de vida. A versão mais recente listada na verificação, v4.8.4, de 10 de novembro de 2026, acrescenta identidade de cargas de trabalho e publicação confiável de deploys. Esses recursos de identidade permitem que serviços e sistemas de deploy compatíveis se autentiquem com tokens de identidade de curta duração, em vez de armazenar credenciais de longa duração.

Para quem está construindo um produto, a mudança prática é que “gerar o relatório depois do upload” pode virar uma tarefa gerenciada em segundo plano, em vez de um endpoint web que fica aberto até o relatório ficar pronto. Seu aplicativo ainda precisa registrar a qual cliente cada relatório pertence e decidir o que acontece se a geração falhar.

Para quem vale a pena — e quem deve procurar outra opção?

Trigger.dev combina com produtos conduzidos pela engenharia, em que a lógica de segundo plano deve ficar junto do restante do código TypeScript. Quanto mais sua necessidade se resume a “executar esta função com confiabilidade e com suas dependências”, melhor o encaixe.

A comparação abaixo destaca onde você descreve o fluxo e o que fica sob sua responsabilidade. São escolhas de arquitetura, e não um ranking de fornecedores por quantidade de recursos.

n8n: quando operações é dona do fluxo

n8n faz mais sentido para quem cuida de operações de vendas e precisa conectar a entrada de leads, o enriquecimento de dados e os contatos seguintes. A abordagem visual permite inspecionar o processo sem transformar cada ajuste em uma alteração no código do aplicativo. Ele oferece suporte a IA e automação de negócios, portanto “precisamos de um agente” não basta para descartá-lo.

A contrapartida está em quem assume a responsabilidade. Se a parte difícil é a lógica personalizada do aplicativo, com bibliotecas e dependências de deploy, uma tarefa TypeScript pode ser mais fácil de manter do que um fluxo visual que não para de crescer. Se o desafio é permitir que alguém de operações altere as etapas de negócio, Trigger.dev torna essa pessoa dependente da engenharia. Veja a comparação de alternativas ao n8n para avaliar essa decisão de compra.

Inngest ou Trigger Dev?

Inngest é o concorrente mais próximo para desenvolvedores que procuram funções duráveis. Sua documentação atual descreve o salvamento dos resultados de cada etapa e a retomada a partir da etapa que falhou, com SDKs para TypeScript, Python e Go. Por isso, vale considerá-lo quando o aplicativo se divide naturalmente em etapas nomeadas ou quando uma equipe Python quer escrever seus workflows em Python.

O atrativo do Trigger.dev é reunir o ambiente de execução da tarefa e suas dependências com a orquestração. O modelo explícito de etapas do Inngest deixa visível no código o ponto a partir do qual ocorre a recuperação. Nenhuma das opções elimina a necessidade de tornar uma gravação externa segura para repetição. Escolha pela forma como pretende fazer o deploy da carga de trabalho e lidar com falhas, sem presumir que só uma delas oferece esperas ou agentes.

Temporal: quando a escolha envolve a plataforma inteira

Temporal merece entrar na lista quando um processo de negócio atravessa vários serviços e seu ciclo de vida importa mais do que colocar rapidamente uma função em segundo plano no ar. Sua documentação abrange SDKs em várias linguagens e o deploy do seu aplicativo junto de um serviço Temporal gerenciado ou hospedado por conta própria.

O custo aqui é o compromisso com uma arquitetura: sua equipe de engenharia assume o aplicativo de workflows e seu desenho operacional. Para um pequeno produto TypeScript que só precisa tirar a geração de relatórios do caminho da requisição, pode ser infraestrutura demais. Para uma equipe de plataforma que quer padronizar processos de negócio de longa duração, esse pode ser justamente o objetivo.

Como escrever, publicar e repetir uma tarefa em segundo plano

Trigger.dev transfere a parte lenta de uma requisição para uma tarefa que você consegue acompanhar separadamente. Pense em uma funcionalidade de importação de documentos: o aplicativo aceita o upload, registra a importação, dispara o processamento e devolve o controle ao cliente. A extração e a classificação podem continuar em segundo plano.

O código abaixo é o exemplo hello-world da documentação de tarefas, com os comentários removidos e um export acrescentado para permitir que a tarefa seja descoberta e importada:

import { task } from "@trigger.dev/sdk";

export const helloWorld = task({
  id: "hello-world",
  run: async (payload: { message: string }) => {
    console.log(payload.message);
  },
});

O ponto de separação é o payload: envie as informações necessárias para localizar e processar a importação, mantendo a requisição do cliente independente da conclusão da tarefa.

A documentação de novas tentativas distingue repetir uma tarefa de repetir um bloco menor com retry.onThrow ou uma requisição HTTP com retry.fetch. Uma nova tentativa da tarefa pode executar tudo novamente. Se o processamento da importação der certo, mas uma notificação posterior lançar um erro, repetir tudo sem critério pode refazer gravações anteriores.

A regra de projeto: trate falhas transitórias com novas tentativas próximas da operação que falhou e torne as gravações idempotentes, ou seja, repetir a mesma operação não deve produzir outro efeito no negócio. A plataforma de tarefas fornece os mecanismos de recuperação; as restrições do banco de dados e suas escolhas de APIs externas determinam se uma nova tentativa duplica uma fatura, um e-mail ou um registro.

Trigger Dev com Python

Trigger.dev pode executar scripts Python dentro de tarefas TypeScript por meio da sua extensão de build para Python. Isso é útil quando seu produto web usa TypeScript, mas o parser de documentos é escrito em Python. É uma ponte entre ambientes de execução, com uma experiência de desenvolvimento diferente da oferecida por um SDK nativo de workflows em Python.

Um detalhe de deploy merece atenção: a instalação via requirementsFile da extensão ocorre apenas em produção; as dependências de desenvolvimento precisam ser instaladas localmente. Um parser funcionar no notebook não comprova que suas dependências estão corretas no ambiente publicado.

Como pausar agentes de IA para aprovação ou callback

Os waitpoints do Trigger.dev permitem interromper um fluxo até que uma pessoa ou um serviço externo forneça o resultado que falta. Em um agente de reembolso, isso significa separar “recomendar um reembolso” de “efetuar o reembolso”. A tarefa pode preparar a recomendação, aguardar a aprovação e continuar apenas depois que o resultado da aprovação chegar.

O guia de waitpoints do fornecedor usa wait.createToken, wait.forToken e wait.completeToken para essa passagem de controle. Ele também mostra URLs de callback para serviços externos. Continua cabendo ao aplicativo decidir quem pode aprovar e o que uma aprovação autoriza.

Há controles separados para tempo e custo. A documentação atual de esperas informa que esperas temporizadas superiores a 5 segundos não entram no consumo de computação. Porém, uma espera temporizada só libera sua vaga de concorrência depois que a máquina tem seu estado capturado em um snapshot e é desligada, aos 60 segundos de espera. Assim, uma espera mais curta pode não gerar cobrança de computação e ainda ocupar uma vaga.

Essa diferença importa quando muitas execuções de agentes fazem pausas curtas ao mesmo tempo. Uma tarefa em espera não representa automaticamente capacidade disponível para outra. Planeje a concorrência considerando tanto o trabalho em execução quanto as esperas curtas, além das operações que exigem muito da CPU.

Para a camada de raciocínio do agente, veja a comparação de frameworks de agentes de IA. O ambiente de execução do Trigger.dev pode manter o trabalho avançando, mas a escolha dos prompts, das ferramentas e das regras de aprovação continua determinando o que o agente faz.

Agende sincronizações sem pressupor o horário de início

Trigger.dev oferece tarefas recorrentes por meio de schedules.task, com agendamentos definidos em código ou associados pelo painel e pelo SDK. Uma sincronização de dados de clientes é um bom exemplo: o agendamento inicia o processamento, a tarefa executa o trabalho e o histórico mostra se ele foi concluído.

A documentação de tarefas agendadas traz uma limitação mais relevante do que a palavra “cron”: novos agendamentos usam, por padrão, uma janela de distribuição de 60 minutos. Uma tarefa diária não precisa começar exatamente no horário nominal do cron. Quando o plano permite, window: "0m" desativa essa distribuição.

Novos agendamentos criados no Free ficam limitados à frequência máxima de uma execução por hora e a uma janela mínima de 60 minutos. Agendamentos antigos que mantêm condições anteriores são uma exceção. Fazer upgrade não altera imediatamente um agendamento restrito; salve-o novamente ou faça um novo deploy já no plano pago.

Para um resumo diário, essa distribuição pode ser aceitável. Para a promessa de entregar um relatório ao cliente em um horário exato, presumir que o padrão atende é um erro. Trate frequência, fuso horário e atraso permitido como requisitos separados antes de substituir um cron job existente.

Mostre o progresso aos usuários e as falhas aos desenvolvedores

Trigger.dev Realtime ajuda a transformar uma tarefa em segundo plano de um indicador de carregamento sem explicação em um fluxo visível. Em uma tela de importação, exiba o estado da execução e os metadados de progresso; para texto gerado, transmita a saída enquanto a tarefa trabalha. São caminhos de dados diferentes.

A visão geral do Realtime diferencia useRealtimeRun, que acompanha status e metadados, de useRealtimeStream, que consome os dados emitidos por streams definidos. Todos os hooks e funções do Realtime exigem autenticação. O cliente deve ver o progresso da própria importação, sem ganhar acesso às execuções dos demais.

Para os desenvolvedores, o painel e os logs das tarefas respondem a outra pergunta: onde a execução parou? Escreva mensagens de progresso claras e úteis para o usuário, sem copiar detalhes internos de erros para a interface do produto.

Trigger Dev e MCP

O servidor MCP do Trigger.dev oferece ao assistente de programação ferramentas para pesquisar a documentação, inicializar projetos, disparar tarefas, fazer deploy e inspecionar execuções. MCP, o Model Context Protocol, é a interface pela qual o assistente chama essas ferramentas.

Use-o para encurtar o ciclo de edição e depuração, mantendo a revisão do comportamento da tarefa. A capacidade de um assistente fazer o deploy de um fluxo não diz se uma nova tentativa pode repetir suas ações externas com segurança.

Preços do Trigger Dev: quando o plano limita a produção

Trigger.dev Hobby é um ponto de partida sensato para um pequeno aplicativo em produção cuja carga caiba nos limites: $10/mês com $10 em créditos de uso incluídos, 50 execuções simultâneas e retenção de logs por 7 dias. O Free custa $0/mês com $5 em créditos, 20 execuções simultâneas e logs de 1 dia; quando os créditos acabam, é necessário fazer upgrade para continuar executando tarefas. São os valores da página de preços, verificados em 11 de novembro de 2026.

A barreira antes do Hobby vai além do consumo. As restrições de agendamento do Free podem inviabilizá-lo antes que a computação fique cara. As conexões Realtime são outro limite: o Free inclui 10 conexões simultâneas; o Hobby, 150. O Pro custa $50/mês com $50 em créditos, inclui 200 execuções simultâneas e logs de 30 dias, tornando-se relevante quando a concorrência ou o histórico para depuração exigem o upgrade.

Para uma estimativa concreta, considere 10,000 tarefas concluídas com sucesso por mês, cada uma com 60 segundos de execução em Small 1x, sem novas tentativas. A $0.0000338 por segundo mais $0.000025 por invocação, o consumo é:

10,000 × ((60 × $0.0000338) + $0.000025) = $20.53.

No Hobby, a assinatura de $10 inclui $10 desse consumo, restando $10.53 adicionais: $20.53 de custo total da plataforma, ou $0.002053 por tarefa concluída nessas condições. É uma conta baseada nas tarifas publicadas, não uma carga de trabalho medida. Chamadas à API do modelo, armazenamento e outros serviços continuam sendo cobrados separadamente; novas tentativas acrescentam trabalho de execução.

Escolha o plano pela concorrência, pelo agendamento e pelo histórico de que precisa. Estime o consumo pelo tempo de execução e reserve margem para falhas e novas tentativas, em vez de tratar a estimativa de execuções bem-sucedidas como teto de gastos.

Limitações que podem mudar a escolha

Trigger.dev elimina boa parte da infraestrutura de workers, mas as responsabilidades que ficam com você são específicas e têm consequências.

Hospedagem própria não garante os mesmos recursos do Cloud

O repositório do Trigger.dev identifica a licença como Apache-2.0 e aponta para guias de deploy com Docker Compose e Kubernetes. Seu repositório GitHub é a fonte para consultar o código e a licença.

A comparação de hospedagem própria lista atualmente warm starts, escalabilidade automática, checkpoints e suporte dedicado como exclusivos do Cloud. A hospedagem própria também coloca sob sua responsabilidade o aplicativo web, Redis, Postgres, supervisores de workers, atualizações e confiabilidade.

Em fluxos com muitas aprovações, o comportamento dos checkpoints é um motivo relevante para preferir o Cloud. A versão mais recente também menciona limpeza de snapshots de microVMs em instalações próprias, portanto a comparação documentada e os detalhes de lançamento não estabelecem uma equivalência simples. Confirme o comportamento suportado na configuração pretendida e inclua a operação da infraestrutura na decisão.

Ausência de timeout da plataforma não dispensa uma política de falhas

Trigger.dev permite que execuções continuem sem um teto fixo de duração imposto pela plataforma, mas sua configuração ainda pode definir maxDuration, um limite de tempo de computação. A documentação de duração permite sobrescrever limites e usar timeout.None para execução por tempo indeterminado.

Ela também informa que cleanup, onSuccess e onFailure não são chamados quando a duração máxima é excedida. Isso é uma armadilha se o aplicativo espera que um hook de falha libere uma reserva ou marque uma importação como malsucedida. Mantenha uma forma de reconciliar registros incompletos no aplicativo, para que a recuperação não dependa de um único hook.

Uma nova tentativa não decide se uma ação de negócio é segura

Trigger.dev não consegue inferir se um reembolso parcialmente concluído, uma sequência de e-mails ou uma importação de dados deve ser repetida. Mesmo quando a recuperação da execução funciona, o resultado de negócio pode estar errado se repetir uma ação externa produzir um novo efeito.

Antes de adotá-lo, identifique a gravação que não pode acontecer duas vezes e o registro que comprova que ela ocorreu. Se seu fluxo não tem esse limite definido, trocar de plataforma de tarefas não resolve sua correção.

Credenciais no Cloud exigem uma decisão consciente de confiança

Trigger.dev relatou um incidente de segurança em 1 de novembro de 2026, com acesso não autorizado a variáveis de ambiente por meio de chaves de API raiz de clientes comprometidas em alguns ambientes. Segundo o relatório do incidente, os clientes afetados foram avisados e as chaves comprometidas, revogadas; instalações com hospedagem própria não foram afetadas.

Para quem está avaliando a compra, isso torna o escopo das credenciais e as medidas de correção do fornecedor parte da análise. O incidente não demonstra que todos os clientes foram afetados nem que uma instalação própria seria automaticamente mais segura. Revise quais credenciais seu worker teria e se as opções de identidade suportadas atendem aos seus serviços.

Veredito: escolha quando quiser workers gerenciados

Entre as opções avaliadas, Trigger.dev é o melhor encaixe para uma equipe de produto TypeScript que quer receber, em conjunto, código de segundo plano, infraestrutura de execução e painel de acompanhamento. Comece por uma carga problemática, como uma importação ou um gerador de relatórios, e defina o limite das novas tentativas antes de migrar o restante.

Escolha n8n quando alguém de operações precisar ser responsável pelo fluxo de integração e editá-lo. Considere Inngest pelo modelo explícito de etapas ou pelos SDKs nativos de workflows em Python/Go. Escolha Temporal quando uma equipe de plataforma quiser assumir deliberadamente a arquitetura de processos de negócio duráveis entre serviços.

Se sua necessidade é principalmente mover informações entre aplicativos de negócio, o guia de alternativas ao Zapier é um ponto de partida melhor do que adotar infraestrutura de tarefas.

Use o Checklist de Auditoria de Workflows de IA para Negócios para mapear a carga de trabalho, o responsável, o caminho de falha e a passagem de controle antes de migrar.

Perguntas frequentes