Você inicia uma refatoração às quatro da tarde e fecha o notebook às seis. Na manhã seguinte, a execução terminou, ainda está em andamento ou parou às 21h40 para fazer uma pergunta que ninguém estava presente para responder. Três situações totalmente diferentes que, do lado de fora, pareceram idênticas a noite inteira.
A Anthropic afirma que o Claude Opus 5.5 consegue manter o foco na tarefa por 18 horas ou mais. Leve isso ao pé da letra. Uma execução iniciada no fim de um dia de trabalho não termina quando o próximo começa. O modelo passou onze horas tomando decisões sem você, e a única barreira entre ele e uma decisão ruim é o que você deixou documentado antes de sair.
Uma execução que cabe no seu expediente é supervisionada. Uma execução que ultrapassa o seu expediente exige que você retome o contexto depois. São sistemas completamente diferentes, e a maioria das equipes ainda opera no primeiro.
TL;DR
Uma execução longa de agente é aquela que continua após o momento em que há alguém presente. Por isso, toda decisão que ele não puder tomar precisa aguardar como um estado registrado, em vez de ficar como um prompt em um terminal que ninguém está lendo. Três condições precisam ser atendidas para que isso seja seguro: uma condição de parada que o agente aplique sozinho, um estado de espera por humano visivelmente distinto de "em execução" e "com falha", e uma caixa de entrada que uma pessoa específica abra pela manhã. Agentes pesquisam, executam, testam e relatam. Pessoas definem o direcionamento, concedem autorizações e aceitam o resultado. A Sharkly reúne essas três etapas na Task.
O que mudou em 22/09/2026
Dois laboratórios lançaram novidades no mesmo dia e, juntos, transformaram tanto a duração quanto o custo de uma execução.
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| API id | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| Entrada / saída por milhão de tokens | $4 / $20 | $2 / $10 | $0.10 / $0.50 |
| Entrada em cache | $0.20 leitura, $5 gravação | 90% de desconto em leituras | 90% de desconto em leituras |
| Contexto | 1M | 872k | 1M |
A Anthropic afirma que o Opus 5.5 custa 40% menos para rodar do que o Opus 5, gera respostas cerca de 30% mais rápido, tem saída máxima de 128k e mantém o foco na tarefa por 18 horas ou mais. A OpenAI afirma que o Sol e o Luna são, cada um, 50% mais baratos do que o preço promocional do GPT-5.6; “promocional” é a palavra usada pela própria OpenAI, ou seja, a comparação é feita contra uma tarifa com desconto, e não de tabela. A OpenAI também relata um desconto de 90% em leituras de entrada em cache para o GPT-6 e diz que alterar o esforço de raciocínio ou a disponibilidade de ferramentas não invalida mais o cache — o que faz toda a diferença justamente para execuções que duram a noite inteira.
Portanto, uma execução agora pode ser longa e barata ao mesmo tempo. Mas o expediente de trabalho não aumentou para acompanhar isso, e nem a capacidade de qualquer pessoa para absorver e avaliar os resultados.
A dinâmica de revisão se inverte
Quando você acompanha uma execução de perto, você atua como o tratador de erros dela. Você vê o modelo abrir o arquivo errado e o interrompe. Essa correção nunca chega a nenhum log, porque nunca precisou chegar.
Durante a noite, nada disso existe. Toda correção que você faria precisa ser uma regra prévia do agente ou uma parada. Não existe uma terceira opção. Um agente de longa duração não é um agente autônomo que simplesmente finalizou a tarefa. É um agente que chegará a uma decisão que depende de você enquanto você dorme. Projete para a parada, não para a conclusão.
A Anthropic também relata 85% menos tentativas bem-sucedidas de burlar restrições no Opus 5.5. Probabilidades menores não são uma condição de parada. Um modelo mais resistente a desvios de instruções ainda precisa de um lugar para registrar uma dúvida às 2 da manhã.
Três requisitos indispensáveis
1. Uma condição de parada que o agente consiga aplicar sem você
Duas frentes: um limite rígido imposto pela plataforma e condições explícitas que o próprio agente aplica.
O teto é uma questão de configuração. Um Sharkly Agent tem um número máximo de Tasks em execução paralela e um tempo limite por Task, definido no próprio Agent e não por execução. Configure o timeout acima da execução mais longa que você deseja e abaixo da mais longa que você está disposto a pagar. Trata-se de um disjuntor de segurança, não de um cronograma.
As condições escritas são a parte que as equipes costumam ignorar. Um agente que nunca para não é diligente, é desgovernado.
Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.
When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.
Use um timeout longo quando a Task for uma alteração delimitada, acompanhada de testes capazes de indicar ao agente se o trabalho está concluído. Mantenha em uma ou duas horas quando a Task for exploratória, quando os critérios de aceitação ainda gerarem debate ou quando a execução puder alterar partes que você não queira modificadas sem revisão prévia. Os portões de aprovação cobrem os momentos em que um agente deve parar, mesmo quando estiver confiante.
2. Um estado de espera que não se confunde com execução ativa
Na Sharkly, o status do ciclo de vida da Task e o estado de trabalho do Agent são registros separados. Uma Task pode permanecer como In Progress enquanto o Agent está em Working, Waiting for human reply, Waiting for human review ou Error. A execução subjacente possui estados próprios: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.
Isso parece preciosismo até você ter oito execuções rodando durante a noite. Sem essa distinção, o painel às 9h exibirá In Progress tanto para um agente editando código quanto para um que parou há onze horas esperando uma resposta. Você terá que abrir as oito para descobrir o que está acontecendo em cada uma.
| O que você vê | O que significa | O custo de ignorar |
|---|---|---|
| Working | O Runtime está operando ativamente na Task | Nada por enquanto |
| Waiting for human reply | O agente pausou e fez uma pergunta | Cada minuto representa capacidade ociosa |
| Waiting for human review | O trabalho está concluído e pendente de aceite | A alteração não foi lançada |
| Error / Failed | A execução foi encerrada com falha | Uma nova tentativa que você ainda não iniciou |
O log de execução torna qualquer parada perfeitamente compreensível na manhã seguinte: por que a execução entrou na fila, quando começou e terminou, as chamadas de ferramentas e eventos do Runtime, a origem do acionamento e os detalhes de falha ou cancelamento. É isso que você lê a frio, sem precisar depender da memória do que pediu. Consulte status, logs e sinais de falha para entender o que registrar caso decida construir isso por conta própria.
3. Uma caixa de entrada com responsável definido
Um estado de espera sem dono aguarda para sempre. Execuções noturnas falham em silêncio de um jeito que não acontece durante o dia, pois ninguém está presente para notar a inatividade.
A Inbox da Sharkly funciona como uma fila pessoal de atividades das tarefas, e a aba Primary concentra os sinais que demandam intervenção humana: aguardando sua resposta, aguardando sua revisão, itens bloqueados ou com falha, menções diretas e atribuições a você. Falhas de execução e avisos de bloqueio vão diretamente para o responsável designado, em vez de serem disparados para todos os inscritos — assim, uma falha às 3 da manhã chega para alguém específico, em vez de cair na vala comum de todo mundo (que equivale a ninguém).
Duas Views salvas resolvem a manhã: tarefas aguardando revisão e tarefas atribuídas a Agents que estão atualmente bloqueadas. Defina nominalmente a pessoa responsável por abri-las. "A equipe" não abre caixa de entrada.
A triagem matinal
A ordem de atendimento importa, e não é a mesma sugerida pelo quadro de tarefas.
- Primeiro, as que aguardam resposta humana (Waiting for human reply). Responder reativa um agente parado; revisar não reativa nada. Se a SH-312 está esperando desde as 21h40, a ação mais produtiva do seu dia é responder em um comentário, o que enfileira uma execução complementar na mesma Task.
- Em segundo lugar, as com falha ou bloqueadas (Failed e blocked). Leia o título do log de execução e os detalhes técnicos antes de reiniciar. Um código de status HTTP isolado é apenas uma pista, não um diagnóstico.
- Em terceiro lugar, as que aguardam revisão (Waiting for review). Esta é a fila de verdade, e é ela que se acumula quando as execuções ficam mais baratas.
- Por último, as que ainda estão rodando (Still running). Deixe continuar ou cancele. Uma execução cancelada não é retomada de onde parou, mas a Task e seu histórico permanecem intactos; portanto, cancele sem hesitar se a direção estiver incorreta. Leia o log antes de tomar a decisão.
O que essa mudança não resolve
Execuções mais longas não reduzem o volume de revisão; elas o concentram. Uma execução de 18 horas devolve um único resultado carregado com uma noite inteira de decisões, e uma pessoa ainda precisa ler, avaliar e aceitar esse trabalho. Os próprios pesquisadores da OpenAI demonstram onde isso vai dar: na mediana, um pesquisador consome mais de US$ 600 por dia em inferência a preços de API, e o percentil 90 ultrapassa US$ 7.000 diários, enquanto a quantidade de pessoas disponíveis para ler as entregas permaneceu a mesma. Nós fizemos as contas quando a OpenAI publicou esses dados, e absolutamente nada neste lançamento altera o denominador.
Execuções mais baratas e prolongadas compram mais tentativas simultâneas, não menos decisões. A revisão humana é o gargalo, e uma redução nos preços piora o cenário antes de melhorá-lo. A automação interrompe o fluxo exatamente onde o discernimento da equipe é indispensável e, ao parar, retorna uma entrega acompanhada de contexto completo e evidências auditáveis.
Perguntas Frequentes (FAQ)
Qual deve ser o timeout por Task para um modelo de 18 horas? Mais longo do que a execução desejada, mais curto do que uma execução da qual você vá se arrepender. Comece com algumas horas para trabalhos convencionais e aumente por Agent nas Tasks que genuinamente demandem a noite inteira. O timeout serve para interromper uma execução em loop; ele não dita o tempo que um trabalho bem-feito leva.
O que acontece com uma dúvida levantada pelo agente às 2 da manhã? Ela deve ser convertida no estado de espera por resposta humana (waiting-for-human-reply) e gerar uma notificação na Inbox da pessoa designada, em vez de se perder como uma linha no histórico do terminal. Se a sua infraestrutura atual deixaria isso passar, resolva essa lacuna antes de ampliar qualquer timeout.
O que fazer a partir daqui
Nenhum fornecedor oferece de fábrica a parte que realmente importa aqui, porque o essencial é onde a parada fica registrada e quem assume a responsabilidade pela manhã. A questão é rigorosamente a mesma no Claude Code, no Codex ou em qualquer outra ferramenta, e é por isso que a responsabilidade deve pertencer ao nível da tarefa, e não ficar restrita à sessão de um fornecedor específico.
Se você já roda agentes durante a noite, o teste é simples. Abra seu quadro às 9h e veja se ele distingue um agente que está processando de um que está esperando desde ontem à noite. Se não distinguir, essa é a primeira coisa a consertar, e é exatamente nessa camada que a Sharkly atua: a Task centraliza o objetivo, o estado da execução, os bloqueios, o resultado e a decisão humana, desde a solicitação inicial até o lançamento final.
