1
gracefullight
4 min de leitura ·

Por que o timeout do seu agent de código reinicia a cada retry

Você dispara três agents de código em paralelo antes do almoço e embrulha cada um em timeout 1800. Meia hora deveria sobrar. Quando você volta, um deles ainda está rodando: os testes falharam, o wrapper fez retry, o retry rodou as verificações de novo, e cada processo novo ganhou mais 30 minutos zerados. Nada quebrou. O limite valia por processo, e o que você queria limitar era a execução inteira.

O Ctrl-C tem um buraco parecido. Se o seu script de orquestração sobe cada CLI de agent no próprio process group (o que faz sentido, para a queda de um agent não derrubar os outros), matar o script não chega nesses grupos. Os agents continuam editando arquivos e gastando tokens sem ninguém olhando.

O que um orçamento de execução precisa cobrir

Uma execução de agent é uma sequência de etapas que, isoladas, parecem curtas:

  • setup (instalar dependências, subir um servidor MCP)
  • o trabalho do agent em si
  • retries depois de uma verificação que falhou
  • comandos de verificação, como a suíte de testes
  • retomar uma sessão que parou no meio

Um timeout em qualquer uma delas não limita a soma. O que limita é um único prazo absoluto, gravado quando a sessão começa, que todas as etapas seguintes consultam em vez de iniciar o próprio relógio.

Como o oh-my-agent resolve isso agora

Eu desenvolvo o oh-my-agent (OMA), uma CLI com um conjunto de skills para rodar agents de código como Claude Code e Codex em paralelo. A versão 20.13 adicionou um orçamento de execução por sessão para esse caso. Você configura uma vez em .agents/oma-config.yaml:

session:
  execution:
    timeout_seconds: 1800

ou por comando:

oma agent parallel tasks.yaml --timeout-seconds 1800
oma agent resume <session-id> --deadline 2026-11-01T18:00:00+11:00

spawn, parallel, review, resume, begin e verify aceitam --timeout-seconds ou --deadline. Existe um prazo por sessão, salvo em .agents/state/executions/. Se a configuração, o processo pai e uma sessão já salva definirem prazos diferentes, vale o mais cedo. Retry e resume só leem esse prazo, não conseguem empurrá-lo para frente. As CLIs filhas que o OMA inicia herdam o prazo via OMA_EXECUTION_DEADLINE, então um oma agent spawn aninhado dentro da tarefa de um agent fica no mesmo orçamento.

Quando o prazo estoura ou você cancela, o OMA para de aceitar trabalho novo naquela sessão: nada de novos agents, retries, reviews ou verificações. Depois ele encerra os process groups que ele mesmo criou, com SIGTERM e um curto período de tolerância antes do SIGKILL. O comando sai com 124 no timeout (o mesmo código do timeout do GNU) e 130 quando você cancela com Ctrl-C, e o motivo da parada fica registrado na sessão.

Se o OMA não consegue confirmar que um processo morreu, ele mantém o registro de posse e reporta o processo sobrevivente, em vez de dizer que a sessão está limpa. oma cleanup --dry-run lista o que seria parado, e ele só mexe em processos cuja identidade ainda bate com o registro. Assim não mata um processo qualquer que por acaso reutilizou o mesmo PID.

Parar também não apaga nada. Logs, resultados, worktrees e caches continuam onde estavam, então dá para ver até onde cada agent chegou antes de o tempo acabar.

Limitações

  • Vale para agents que o OMA inicia pelo próprio caminho da CLI. Subagents nativos dentro do Claude Code, ou um job de shell que você mesmo subiu, dependem do mecanismo de cancelamento do host.
  • Limita só o tempo de relógio. Limites de CPU, RAM e disco dependem do host ou do container.
  • Os limites de tokens (session.quota_cap) não interrompem um processo filho que já está rodando. Quem de fato para um filho em execução é o orçamento de tempo.
  • Definir as variáveis de ambiente na mão não faz um programa que não as lê respeitar o prazo.

Para testar

Eu criei o OMA e quero saber como você limita execuções longas de agents hoje, ou onde isso não resolve o seu caso.

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash

# Windows (PowerShell)
irm https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.ps1 | iex

Texto original (em ingles): https://dev.to/gracefullight/why-your-coding-agents-timeout-resets-every-time-it-retries-gka

https://github.com/first-fluke/oh-my-agent?utm_source=tabnews

Carregando publicação patrocinada...