Claude Routines e Opus 4.7: Meu Primeiro Relato de Implementação

Claude Routines e Opus 4.7: Meu Primeiro Relato de Implementação

Eram 6h47 de uma sexta-feira e meu celular estava virado para baixo no criado-mudo. Na cozinha, algo que eu não executei, em uma máquina que não era minha, estava lendo meus últimos 24 horas de e-mails, separando-os em três pilhas, redigindo respostas para os cinco que precisavam, e lançando um resumo no Slack em #morning-brief com as linhas de assunto e uma pontuação de urgência em uma linha para cada um.

Quando cheguei para tomar café, o resumo já estava no Slack há 31 minutos. Dois rascunhos de resposta já estavam na minha pasta de rascunhos do Gmail, precisando de uns nove palavras de edição cada antes que eu apertasse enviar. Um terceiro rascunho foi sinalizado pela própria rotina como "precisa do seu contexto — não envie". O laptop na minha mesa estava fechado desde as 23h14 da noite anterior.

Esta foi a primeira semana em que pude dizer essa frase — "algo rodou enquanto eu dormia, em uma máquina que não era minha" — sobre um fluxo de trabalho que eu mesmo construí, em menos de três minutos, sem escrever uma linha de cron syntax ou subir uma caixa EC2. Isso foi o que entrou em produção quando a Anthropic lançou as Claude Routines em 14 de abril de 2026, dois dias antes de liberarem o Opus 4.7 em 16 de abril. Os dois lançamentos são inseparáveis. Routines é o contêiner. Opus 4.7 é o que faz o trabalho dentro do contêiner realmente útil, e não apenas agendado.

Já rodei seis Routines em sete dias. Duas coloquei em produção. Duas reconstruí do zero após falharem de maneiras que a documentação não alerta. Uma eu excluí totalmente. E uma está rodando agora, em segundo plano, enquanto escrevo esta frase.

O que segue não é um reanúncio. Se você quer o press release, o próprio post da Anthropic serve. O que segue é como realmente é construir com Claude Routines no Opus 4.7 na primeira semana em que existem — os padrões que funcionaram, os modos de falha que enfrentei, a postura de segurança que você precisa decidir antes de dar a uma tarefa agendada acesso à sua caixa de entrada, e os fluxos específicos que eu construiria a seguir se tivesse mais um fim de semana livre.

Deixe-me começar explicando o que realmente são Routines, porque metade da cobertura que li esta semana está errando consistentemente em um detalhe.

O Que São Realmente as Routines (E O Que Não São)

Uma Routine é uma configuração de Claude Code salva — um prompt, um conjunto de repositórios, um conjunto de conectores e um gatilho — que roda na própria infraestrutura da Anthropic, seja em uma agenda pré-definida, por chamada de API ou por evento de webhook do GitHub. Quando o gatilho dispara, a Anthropic inicia uma sessão nova do Claude Code, alimenta-a com seu prompt salvo, concede acesso aos conectores aprovados, permite que execute até o fim da tarefa e depois encerra a sessão. Sua máquina local não participa do processo. Seu laptop pode estar fechado. Você pode estar em modo avião dentro de um avião.

Esse último ponto mudou completamente minha forma de pensar sobre esse tipo de automação. Todo fluxo de IA agendado que já construí antes — todo cron job rodando um script Python chamando uma API, toda GitHub Action executando o Claude via SDK — dependia de uma máquina minha estar ligada, conectada e saudável. Pela primeira vez, com Routines, essa dependência desapareceu para mim.

Agora, o que Routines não são: não substituem o n8n. Não matam o Zapier. Não são um construtor de fluxos visual onde você arrasta caixas e conecta setas. Trata-se de um prompt salvo, mais gatilhos, mais permissões de ferramentas, mais um ambiente onde o Claude pode rodar enquanto a tarefa exigir. O visual está no painel Routines do app desktop. A inteligência real é o que quer que o Claude decida fazer ao ler seu prompt quando o gatilho dispara.

Essa diferença é fundamental porque toda a filosofia de design muda. Um fluxo do Zapier quebra no momento em que a resposta de uma API muda de formato. Já uma Routine, teoricamente, lê o novo formato e se adapta. Se isso realmente acontece na prática — é aí que entra o Opus 4.7.

Gatilhos, Ferramentas e os Três Números Que Definem o Recurso

As Routines aceitam exatamente três tipos de gatilho, e cada um deles exige atenção antes de você comprometer algum fluxo a eles.

Gatilhos de agenda rodam em uma cadência no estilo cron, com uma restrição importante: o intervalo mínimo é de uma hora. Você escolhe entre quatro predefinições na interface — a cada hora, diariamente, dias de semana, semanalmente — e, se precisa de uma cadência personalizada, tipo "a cada duas horas" ou "na primeira segunda-feira do mês", ajusta para a predefinição mais próxima e executa /schedule update no CLI para definir uma expressão cron exata. Agendas mais frequentes que uma vez por hora são rejeitadas. Se você queria rodar uma Routine a cada cinco minutos, como um job de polling, isso hoje simplesmente não acontece nas Routines.

Gatilhos de webhook disparam quando sua Routine recebe uma chamada de API com a chave correta. Este é o tipo ao qual recorro sempre. Significa que qualquer ferramenta capaz de dar um POST em uma URL pode disparar uma Routine — seu CRM, seu board de PM, seu formulário de contato, seus próprios scripts. É a saída de emergência universal. Se a cadência de agenda não serve, quase qualquer problema pode ser resolvido com algum outro sistema dando POST num webhook na cadência que você realmente precisa.

Gatilhos do GitHub disparam em eventos de webhook do GitHub — pushes, aberturas de PR, comentários, releases — nos repositórios conectados pelo Claude GitHub App. Durante o research preview, esses eventos estão sujeitos a limites horários por Routine e por conta. Se você fizer dez pushes em cinco minutos, nem todos vão disparar a Routine; parte será descartada até o próximo período horário. É bom saber disso antes de construir um fluxo "Claude revisa todo PR" e descobrir que metade ficou sem análise.

Três números determinam quanto das Routines você pode usar, conforme seu plano. Contas Pro podem rodar até 5 execuções de Routine por dia. Planos Max podem executar 15. Contas Team e Enterprise podem rodar 25. Excedentes podem ser faturados se você ativar a opção. Esses limites valem por dia, não por Routine, então um usuário Pro rodando cinco Routines diferentes que disparam uma vez por dia já atingiu o teto. Um Pro rodando só uma Routine, com execução horária, atinge o teto antes das 11 da manhã.

É aí que muita gente erra na primeira tentativa de escalar uma Routine além do estágio de demo. Se você está no Pro e quer execução horária, são 5 rodadas por dia, ou seja, um job realmente de hora em hora não é possível no Pro sem ativar faturamento excedente. É uma restrição do research preview, provavelmente temporária, mas é a regra atual.

É aqui que o recurso se torna interessante — e é aqui também que o modelo de IA começa a importar mais do que a infraestrutura por trás.

Opus 4.7 É o Motivo pelo Qual as Rotinas São Realmente Úteis

A Anthropic lançou o Claude Opus 4.7 em 16 de abril de 2026, dois dias após a abertura do preview de pesquisa das Rotinas. Não acredito que seja coincidência. Todos os benchmarks publicados apontam na mesma direção: o Opus 4.7 é superior em tarefas longas, com múltiplas etapas e intensivas em ferramentas do que qualquer modelo anterior. As Rotinas são, por design, tarefas longas, com múltiplas etapas e que exigem uso intenso de ferramentas.

Os números em que mais confio, porque provêm das avaliações feitas pelos próprios parceiros de engenharia da Anthropic e não de curvas de marketing, são estes. Nas avaliações internas de produção da Box, Opus 4.7 alcançou uma redução de 56% nas chamadas de modelo e de 50% nas chamadas de ferramentas em comparação com o Opus 4.6, respondeu 24% mais rápido nas mesmas avaliações e usou 30% menos AI Units no trabalho de ponta a ponta. No benchmark de produção de código da Rakuten, o Opus 4.7 resolve cerca de três vezes mais tarefas de produção do que o Opus 4.6, com ganhos de dois dígitos tanto em Qualidade de Código quanto em Qualidade de Testes. No CursorBench, que mede fluxos de trabalho reais integrados ao IDE em vez de resolução sintética de problemas, o Opus 4.7 salta de 58% (pontuação do Opus 4.6) para 70% — uma melhora de 12 pontos no benchmark que mais se assemelha ao trabalho real dos desenvolvedores.

O benchmark mais relevante para workloads agenciais, contudo, é o SWE-bench Verified. O Opus 4.6 marcou 80,8%. O Opus 4.7 atinge 87,6%. Isso representa um ganho de quase sete pontos em um ranking onde cada ponto no topo da curva é difícil de conquistar, colocando o Opus 4.7 à frente do Gemini 3.1 Pro (80,6%) e significativamente à frente do GPT-5.4 na mesma tarefa.

Há ainda um ponto importante a destacar, pois é a informação mais relevante antes de você configurar uma Rotina: o Opus 4.7 traz um novo nível de esforço chamado xhigh. Não é "extra high", nem "extended", nem "high-plus" — o nome literal do flag na API e CLI é xhigh. É o padrão recomendado para o Opus 4.7 em raciocínio complexo e tarefas agenciais, e já vem ativado por padrão no Claude Code para este modelo. O que o xhigh faz, por baixo dos panos, é alocar mais tokens para o raciocínio interno do modelo e para o loop de exploração de ferramentas antes de retornar qualquer resposta. Para um chat único, é exagero. Mas para uma Rotina que precisa puxar e-mails, categorizá-los, redigir respostas e enviar um resumo no Slack sem sua intervenção, este é exatamente o nível que você procura.

Um alerta que as postagens de blog não enfatizam: xhigh é caro. Combinado a um novo tokenizador no Opus 4.7 que conta aproximadamente de 1,0 a 1,35 vezes mais tokens para o mesmo texto em relação ao 4.6, e o aumento natural do output devido ao raciocínio interno mais profundo, suas faturas da API podem aumentar de 20% a 50% por tarefa equivalente em comparação à era 4.6. O trabalho é melhor. O trabalho é mais caro por execução. Ambas as coisas são verdadeiras. Se você estiver rodando Rotinas na API e não dentro da franquia de uso do Claude Code, faça as contas em um job de teste de baixo risco antes de acoplar xhigh em uma Rotina que executa 25 vezes ao dia.

Com o recurso e o modelo mapeados, deixe-me contar o que eu realmente construí.

A Rotina que Implementei: Triagem Matinal de E-mails que Realmente Funciona

Construi a Rotina de triagem de e-mails primeiro pelo mesmo motivo que todos os outros: o exemplo que a Anthropic demonstrou no lançamento era uma Rotina de triagem de e-mails e o formato do problema — entradas previsíveis, saídas limitadas, fácil de validar — faz dela a construção inicial mais limpa dentro do recurso. O que eu não esperava era quanto a qualidade do resultado dependeria de escrever o prompt como se estivesse repassando uma tarefa para um prestador de serviços que eu nunca conheci.

Aqui está o prompt com o qual finalizei após três iterações. Ele é longo, e esse é justamente o objetivo.

Você está executando uma triagem de e-mails não supervisionada às 6h45, horário local.
Não poderei responder perguntas enquanto você executa. Tome a melhor decisão
possível em cada ponto. Em caso de dúvida, redija um rascunho, não envie.

PASSO 1 — BUSCAR
Puxe todas as mensagens não lidas da minha caixa de entrada do Gmail recebidas nas últimas
24 horas. Exclua qualquer coisa das abas Promoções, Social ou Atualizações.

PASSO 2 — CATEGORIZAR
Classifique cada mensagem em exatamente um destes três grupos:
  - URGENTE — uma pessoa específica aguardando minha resposta está bloqueada, ou há
    um prazo em até 48 horas, ou envolve dinheiro/contratos
  - PRECISA_DE_RESPOSTA — espera-se uma resposta, mas nada está bloqueado
    e nada é urgente
  - SEM_AÇÃO — newsletters, recibos, informativos, não se espera resposta

PASSO 3 — REDIGIR
Para cada mensagem URGENTE ou PRECISA_DE_RESPOSTA, redija uma resposta e salve
no meu rascunho do Gmail. Não envie. Adote o meu tom a partir das
últimas dez respostas na pasta Enviados (frases curtas, sem "Espero que esteja bem", termine com "— M"). Se não conseguir redigir com confiança por
falta de contexto que eu possuo, redija uma resposta dizendo exatamente de que contexto precisa e marque o rascunho como [NEEDS_CONTEXT] no assunto.

PASSO 4 — RESUMIR
Publique uma mensagem no Slack no canal #morning-brief neste formato:
  URGENTE (N): uma linha com o remetente + uma linha com o assunto + seu veredito do rascunho
  PRECISA_DE_RESPOSTA (N): mesmo formato
  SEM_AÇÃO (N): apenas o total, sem detalhes

PASSO 5 — TRATAMENTO DE FALHAS
Se qualquer passo falhar, publique no Slack #morning-brief com @here e o
erro. Uma falha silenciosa é o pior resultado possível. Prefiro
ver uma mensagem vermelha do que não receber nada.

PASSO 6 — RECUPERAÇÃO DE CONTEXTO DAS EXECUÇÕES ANTERIORES
Antes de iniciar o Passo 1, leia a mensagem fixada no canal #morning-brief
da execução de ontem. Se algum item URGENTE de ontem ainda não estiver
resolvido na minha pasta Enviados, destaque-os no resumo de hoje como
CARRIED_OVER.

Seis passos numerados. Tratamento de falha explícito. Instruções claras para resgatar contexto da execução anterior. Sem suposições sobre o que o Claude irá deduzir sozinho.

Esse último passo — a recuperação de contexto das execuções anteriores — foi o que me obrigou a refazer duas vezes. Routines não têm memória entre execuções por padrão. Cada execução começa com uma sessão limpa. Se você quiser que o que foi feito ontem influencie o que será feito hoje, precisa dizer ao Claude exatamente onde buscar essa informação — seja um canal do Slack, um Google Doc, um gist do GitHub, uma página no Notion, onde ele possa ler e escrever via conector. Caso pule essa etapa, a Rotina irá alegremente redigir uma resposta para o mesmo e-mail três dias seguidos, porque do ponto de vista dela todo dia de manhã é o primeiro.

A instrução de tratamento de falha foi outra lição que me custou uma reconstrução. Minha primeira Rotina falhou por causa de uma mensagem MIME malformada e morreu em silêncio. Só descobri quando notei que não recebi o resumo no Slack às 7h. Quando refiz a Rotina com o callback de falha @here, já havia perdido dois e-mails realmente urgentes porque presumi que a manhã silenciosa significava ausência de respostas. Falha silenciosa é o pior resultado em qualquer fluxo não supervisionado. Escreva o callback de falha antes de pensar no caminho feliz.

Resultados da Primeira Semana

Veja como os dados realmente se apresentaram ao longo de sete dias utilizando apenas essa Rotina. Compartilho o que observei, não um estudo de caso selecionado.

Mensagens processadas: 294 e-mails não lidos em 7 dias (cerca de 42 por dia). Precisão da categorização, avaliada manualmente por mim às 9h da manhã: Em 91% dos casos, concordei com o agrupamento do Claude. Nos 9% divergentes, quase sempre o Claude superestimou o "URGENTE" — geralmente porque o tom do remetente parecia urgente, mas o conteúdo era apenas um informe de status. Qualidade dos rascunhos: Em 6 de cada 10 rascunhos eu enviei após editar menos de 15 palavras. 2 de cada 10 precisei reescrever substancialmente. 1 em cada 10 descartei e escrevi do zero. 1 em cada 10 foi corretamente sinalizado como [NEEDS_CONTEXT] e eu mesmo respondi. Falhas silenciosas: Zero após implementar o callback. Uma (o crash do MIME) antes. Tempo economizado, estimativa aproximada: Antes, minha triagem de e-mails levava cerca de 25-35 minutos toda manhã. Com a Rotina, a atividade de revisar e enviar dura uns 7-10 minutos. São cerca de três horas por semana recuperadas.

Um alerta importante: a Rotina só é tão boa porque o prompt é detalhado desse jeito. Testei uma versão curta — "Trie meus e-mails, redija respostas, poste um resumo no Slack" — e funcionou cerca de 60% do esperado. Prompts vagos produzem rotinas vagas. Trate o prompt como um documento de especificação, não como uma mensagem de chat.

A Decisão Entre Modo Confiável e Modo Completo Que Você Não Pode Ignorar

Antes que qualquer Routine possa utilizar suas ferramentas, você precisa escolher um de dois modos: confiável ou completo. Esta é, sem dúvida, a decisão de segurança mais importante de toda a configuração, e merece muito mais do que os dois parágrafos dedicados a ela na documentação.

No modo confiável, a Routine só pode acessar ferramentas que você aprovou explicitamente — Gmail, Slack, Google Drive, ou qualquer outra que você habilitou individualmente. Se o prompt pedir para o Claude fazer algo que exija uma ferramenta não aprovada, a Routine vai recusar a etapa ou falhar. Esse é o padrão, e também o ponto de partida correto para qualquer fluxo de trabalho que você criar.

No modo completo, a Routine pode acessar qualquer ferramenta que tenha um conector configurado na sua conta. Se, no meio da execução, ela decidir que precisa buscar algo na web, escrever um arquivo ou consultar uma nova API, pode fazer isso sem pedir permissão. O modo completo é como você libera os tipos mais ambiciosos de autonomia. É também como você, sem querer, dá autorização para um agente de IA não supervisionado enviar e-mails para toda a sua lista de clientes porque o prompt estava ambíguo e o modelo interpretou "entrar em contato" de forma mais ampla do que você imaginava.

Minha regra após uma semana: crie toda Routine primeiro no modo confiável, execute pelo menos três vezes, audite as chamadas de ferramentas e só promova para o modo completo se puder nomear uma capacidade específica que o modo confiável não atinge. Todas as minhas Routines em produção hoje estão em modo confiável. A única Routine que testei em modo completo foi deletada, porque fez justamente o tipo de coisa que faz você nunca mais querer rodar um agente não supervisionado — decidiu que a melhor forma de "fazer follow-up de leads inativos" era enviar e-mails para dezessete pessoas com quem eu não falava havia dois anos.

Não existe uma solução técnica eficaz para ambiguidade de prompts no modo completo. A única correção real é escrever um prompt mais preciso e rodar em modo confiável.

Se você já criou agentes de produção com o Agent SDK, boa parte disso será familiar — a mesma disciplina de delimitação de capacidades se aplica aqui, com menos código e uma superfície um pouco diferente. Para uma análise mais aprofundada desses limites, veja meu passo a passo sobre o Anthropic Agent SDK.

O que Quebrou e o que Precisei Reconstruir

Nem tudo o que tentei funcionou. As duas Rotinas que falharam mais seriamente são mais úteis de serem discutidas do que as que tiveram sucesso, porque os modos de falha são quase certamente os mesmos que outras pessoas vão encontrar na primeira semana.

Falha 1: A Rotina de revisão de PR que disparava com muita frequência.
Liguei um gatilho do GitHub em um repositório Laravel de porte médio — todo PR aberto, todo push em um PR aberto, rodar uma revisão de código e deixar o comentário direto no PR. Em uma terça-feira movimentada, fiz 11 commits em um único PR ao longo de cerca de 90 minutos. A Rotina disparou seis vezes e então parou silenciosamente. Achei que tinha quebrado. O que realmente aconteceu foi que atingi o limite horário por rotina de eventos do webhook do GitHub durante o preview de pesquisa, e os outros cinco eventos foram descartados. A documentação menciona isso em uma linha única; deixei passar na primeira leitura. Minha correção: debouncing do gatilho para “ao abrir PR” e “quando PR está pronto para revisão” em vez de “a cada push”, o que reduziu a frequência de disparos de seis por PR para uma por PR e eliminou completamente a perda de eventos.

Falha 2: A Rotina de relatórios semanais que buscava o período errado.
Montei uma Rotina para rodar toda segunda-feira às 8h, puxar meus pagamentos do Stripe e ganhos do Fiverr da semana anterior, resumir a tendência e postar tudo em um canal privado do Slack. Na primeira execução, o número voltou aproximadamente 40% abaixo do esperado. O modelo interpretou “semana passada” como “os últimos sete dias desde agora” em vez de “a semana completa anterior de segunda a domingo (calendário)”. Como cada execução de Rotina começa do zero sem memória do que foi a semana passada, faltava uma âncora para calibrar. A solução foi ser explícito: “Busque dados da semana do calendário começando na segunda-feira [cálculo de data em ISO-8601] e terminando no domingo [cálculo de data em ISO-8601]. Não dos últimos sete dias. Da semana do calendário anterior.” Depois disso, os números bateram exatamente com o dashboard do Stripe.

Ambas as falhas têm o mesmo padrão. As duas foram falhas de contexto presumido. Nos dois casos, escrevi um prompt que funcionaria bem para um colega humano que conhecesse meu trabalho, mas seria ambíguo para um contratado novo no primeiro dia. Routines estão sempre no primeiro dia, toda vez que rodam. Escreva os prompts pensando em um contratado novato e a maioria dessas falhas some antes mesmo de acontecerem.

Se você já escreve fluxos de trabalho agentivos de longa duração e quer um framework mais profundo para esse tipo de construção de prompts, o que usei esta semana foi o que escrevi em meu review prático sobre o Opus 4.6 — os princípios se traduzem bem para o 4.7, com o benefício extra de que o 4.7 tolera mais ambiguidade antes de sair do roteiro. “Tolera mais” não é “elimina”. Prompts bem definidos ainda são os vencedores.

Onde as Routines Ainda Ficam Aquém

Esta é a seção que a maioria das coberturas de lançamento vai pular, então vou me aprofundar nela. Existem quatro limitações reais que enfrentei na primeira semana e que merecem ser nomeadas claramente, pois devem informar o que você deve ou não construir.

1. Nenhuma memória entre execuções por padrão. Já abordei este ponto acima, mas vale repetir. Cada execução de uma Routine é uma sessão Claude Code completamente nova, sem qualquer noção do seu próprio histórico. A solução alternativa é a recuperação explícita de contexto — aponte Claude para um canal do Slack, um Google Doc, uma linha de banco de dados, qualquer lugar onde ele possa ler a saída de ontem antes de iniciar o trabalho de hoje. Isso é contornável, mas é manual, e esquecer de implementar resulta facilmente em três dias de respostas duplicadas.

2. Cadência mínima de uma hora. Se o trabalho real precisa rodar a cada cinco minutos — um job de checagem de status, um monitor de sinal em tempo real, qualquer tarefa do mundo do trading — as Routines não conseguem executar dentro do gatilho de agendamento padrão. A solução é disparar um gatilho via webhook controlado por um scheduler externo, mas aí você volta a administrar infraestrutura em outro lugar, o que compromete parte da proposta. Para cadência realmente inferior a uma hora, Routines ainda não são a ferramenta adequada.

3. Postura de segurança do modo completo ainda é imatura. O modo completo é poderoso e perigoso em medidas aproximadamente iguais. Não existe um modo sandbox que simule uma execução de modo completo antes de atingir ferramentas de produção. Não há limite de custo por ferramenta para evitar que um workflow descontrolado consuma tokens em um loop ruim. Não há limitador de taxa configurável por conector. Basicamente, a única proteção real é a qualidade do seu prompt, além de começar sempre no modo confiável. Times profissionais rodando Routines no modo completo com dados reais de clientes devem esperar construir seus próprios guardrails em torno da Routine — padrões de aprovação em fila, logs de auditoria por canal lateral, circuit breakers de gastos.

4. Preview de pesquisa significa que a API pode mudar. Tudo o que escrevi neste post é válido em 21 de abril de 2026. A Anthropic explicitamente sinalizou que formatos de requisição e resposta, limites de taxa e semântica de tokens podem mudar enquanto as Routines estiverem em preview de pesquisa. Se você construir infraestrutura crítica este mês usando Routines, reserve tempo para reescrever parte dela nos próximos seis meses. Isso não é uma falha — é uma consequência honesta de lançar em preview de pesquisa — mas vale nomear porque já vi times tratarem preview de pesquisa como API estável e perderem dias por não perceberem alterações de formato.

Nenhuma dessas questões inviabiliza o produto. Todas são pontos que você deve conhecer antes de comprometer um workflow com Routines e garantir a terceiros que ele continuará funcionando.

Se você já opera automações agendadas no app desktop do Claude Code em vez de nas Routines, pode achar útil a comparação que fiz entre os dois no guia de scheduled-tasks do Claude CoWork — as interfaces parecem parecidas por fora, mas o modelo de execução é fundamentalmente distinto, e isso importa dependendo de o seu laptop precisar ou não estar ligado.

As Cinco Rotinas Que Eu Construiria a Seguir

Se eu tivesse o fim de semana de volta e quisesse extrair o máximo de aproveitamento das Routines antes que o limite chegasse, aqui está a lista, classificada pelo retorno sobre investimento por minuto de configuração.

1. Triagem matinal de e-mails + rascunhos. A que já construí. Se você não fizer mais nada, construa esta. O tempo devolvido é imediato e os modos de falha são limitados.

2. Relatórios semanais do negócio. Stripe, Fiverr, qualquer que seja sua fonte de receita, puxada toda segunda-feira de manhã, resumida como tendência e postada em um canal privado do Slack. O benefício composto é que você para de pensar “Eu deveria olhar os números” porque os números vêm até você. Para operadores solo, isto é possivelmente mais valioso do que a triagem de e-mails.

3. Triagem automática de leads recebidos com rascunhos personalizados de primeira resposta. Gatilho webhook a partir do formulário de contato do seu site. Claude puxa a mensagem, pesquisa a empresa do remetente pelo domínio em cerca de quarenta segundos, redige uma resposta que referencia algo real sobre o negócio deles, salva o rascunho e avisa você no Slack. Você revisa e envia. O tempo de resposta cai de horas para minutos sem sacrificar o toque humano que fecha o lead.

4. Digest diário de changelog para um repositório público. Gatilho do GitHub a cada merge para a main. Claude puxa o diff, escreve uma entrada de changelog para o usuário com sua voz, adiciona ao CHANGELOG.md e abre um PR. Você revisa semanalmente. Horas de documentação por mês reduzidas a minutos de revisão.

5. Briefing de pesquisa para as reuniões de amanhã. Gatilho agendado diariamente às 20h. Claude lê sua agenda do dia seguinte, puxa os títulos do LinkedIn dos participantes, escritos públicos recentes e o último thread de e-mail com cada um, produz um briefing de uma página por reunião e coloca tudo em um Google Doc. Entre em cada reunião no dia seguinte com contexto que você não precisou gastar 30 minutos coletando.

Nada disso é uma ideia nova. Todas essas rotinas poderiam ter sido construídas tecnicamente há anos usando cron mais um modelo de linguagem mais um wrapper de API. O motivo de eu não ter construído nenhuma delas é que cada uma exigia uma infraestrutura que eu não queria administrar — um servidor para rodar o cron, um wrapper para chamar o modelo, uma fila para tratar falhas, um monitor para avisar quando a fila estivesse quebrada. Routines colapsa essa pilha em uma configuração salva que roda na infraestrutura de outra pessoa. O obstáculo para realizar não era a ideia. O obstáculo era a tarefa braçal.

Isso é o que realmente é novo aqui. Não a automação em si. A ausência da tarefa braçal. Para uma leitura mais aprofundada sobre como está o cenário dos modelos em abril de 2026 após esse lançamento, meu apanhado de modelos de IA de abril de 2026 traz o panorama completo sobre o Kimi K2.6, rumores do GPT-5.5 Spud, e como o Opus 4.7 realmente se posiciona frente ao restante do mercado em workloads reais.

Perguntas Frequentes

O que são Claude Routines e como funcionam?

Claude Routines são configurações salvas do Claude Code — um prompt, repositórios, conectores e um gatilho — que rodam na infraestrutura em nuvem da Anthropic quando um agendamento, chamada de API ou evento do GitHub ocorre. Sua máquina local não precisa estar online. Cada execução inicia uma nova sessão do Claude Code sem memória das execuções anteriores, a menos que você instrua explicitamente o prompt de onde buscar o contexto anterior. Para um passo a passo completo de configuração, veja a seção Morning Email Triage acima.

Qual é o intervalo mínimo de agendamento para uma Claude Routine?

Uma hora. Os gatilhos de agendamento suportam quatro predefinições — a cada hora, diariamente, dias úteis, semanalmente — e rejeitam qualquer expressão cron que execute com frequência maior que uma vez por hora. Para uma cadência inferior a uma hora, use um webhook disparado por um agendador externo, embora isso reintroduza o problema de infraestrutura externa que as Routines visam eliminar.

Opus 4.7 é melhor que Opus 4.6 para trabalhos agentivos?

Sim, de forma significativa. Nas avaliações de parceiros da Anthropic, Opus 4.7 fez 56% menos chamadas de modelo e 50% menos chamadas de ferramenta do que o Opus 4.6 para tarefas equivalentes, resolveu aproximadamente três vezes mais tarefas de produção no benchmark de codificação da Rakuten e saltou de 58% para 70% no CursorBench. O novo nível de esforço xhigh é o padrão para a 4.7 dentro do Claude Code e é a camada recomendada para trabalhos autônomos de múltiplas etapas.

O que é xhigh no Claude Opus 4.7?

xhigh é o novo nível de esforço topo de linha no Opus 4.7 — é o nome literal do flag usado na API e CLI. Ele aloca mais tokens para raciocínio interno e loops de exploração de ferramentas antes do modelo retornar a resposta. É o nível de esforço padrão do Opus 4.7 no Claude Code e é recomendado para raciocínios complexos e trabalhos agentivos. O custo por tarefa é maior devido ao ciclo de raciocínio mais profundo e ao novo tokenizador, então espere contas de 20% a 50% mais altas por tarefa equivalente em relação ao 4.6.

Quantas Routines posso rodar por dia no plano Pro?

Cinco execuções de Routine por dia no Claude Pro. Usuários do Claude Max recebem 15 por dia. Usuários Team e Enterprise recebem 25 por dia. É possível optar por cobrança adicional se precisar de mais, mas os limites são totais por conta, somando todas as suas Routines, e não por Routine — então um usuário Pro rodando cinco Routines diferentes diariamente já está no limite.

Devo usar o modo trusted ou full tool para uma nova Routine?

Sempre use o modo trusted para uma nova Routine. O modo trusted limita o Claude às ferramentas específicas que você aprovou individualmente para aquela Routine. O modo full permite que o Claude acesse qualquer conector da sua conta durante a execução, útil para fluxos de trabalho mais ambiciosos, mas também é assim que agentes autônomos acabam fazendo coisas que você não pretendia. Comece no modo trusted, execute três execuções limpas, audite as chamadas de ferramenta e promova ao modo full apenas se conseguir nomear uma capacidade específica que o modo trusted não alcança.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Estou pronto para ajudar.

• Fiverr (projetos personalizados & integrações): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções corporativas): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io