Como Ter Seu Claude Rodando Sem Parar No Plano Mensal

Para quem não trabalha com API, e sim com os planos mensais da Anthropic, sabe que o Claude Code tem dois limites: o de 5 horas/semanal, e o de tokens (que todo agente vai ter, com ou sem API). O limite de 5 horas é forma inteligente de fazer você "usar a plataforma com responsabilidade", que na verdade quer dizer "esperamos muito que isso atrapalhe você o suficiente para não gastar o limite semanal".

Então você abre o terminal, começa um trabalho, monitora os tokens e quando o limite das 5 horas acaba, você deixa ele lá quietinho, até que alguma hora você lembra, digita continue, e o trabalho continua, até acabar o limite de novo.

Seria muito bom poder deixar meu plano mensal do Claude rodando sem parar, de forma autônoma, até completar todas as tasks do trabalho.

E dá pra fazer isso. Você só precisa do terminal e boa vontade pra fazer isso acontecer. Vou explicar como eu faço esse fluxo, quando preciso de sprints "rápidos" de um ou dois dias sem parar. Eu vou explicar da forma que eu faço, você pode adaptar da sua forma de acordo com sua necessidade, é realmente muito simples. A stack que eu uso é:

• Terminal Linux (direto no Linux ou WSL2 do Windows, com o Claude Code instalado)
• um arquivo .sh na raiz do seu projeto
• AIPIM, meu MCP local para gerenciar as tasks de agentes
• Qualquer plano mensal/anual do Claude, obviamente!

Entendendo a Metodologia

Antes de pôr a mão na massa, é importante entender a metodologia de como isso será feito. Tem duas dores que precisam ser saciadas:

• Não usar o limite de tokens: usar os tokens até perto do limite traz dois problemas, o primeiro é que fica mais caro, e o segundo é que a chance de alucinação aumenta consideravelmente. O ideal é não ter /clear tão cedo, pois o próprio agente vai gastar ~30k de tokens para organizar o contexto, e nem tão tarde para não ter os problemas que citei no começo.
• Continuar sempre que goddamn limite das 5 horas estourar automaticamente: As tasks estão prontas, o worktree está criado, eu só quero ter uma noite tranquila, dormir, acordar, fazer meus exercícios, sem ter que me preocupar se a task está ok ou não.

Então precisamos de um loop contínuo para avaliar essas duas condições de forma não bloqueante.

Para fazer essa bruxaria, usaremos uma famosa ferramenta do pinguim chamada tmux, que nos vai dar o poder de criar uma sessão e ter controle total sobre ela.

Passo A Passo Para Criar o Script

Se quiser pular essa parte, no final tem o código completo e pronto pra copiar. Mas entender o que é feito é importante, não seja preguiçoso!

Criação do Arquivo

Crie primeiro o arquivo, que você pode adicionar no .gitignore para não poluir o repo:

nano scheduler.sh # para editar e salvar o arquivo direto no terminal
# ou
touch scheduler.sh # para só criar o arquivo e editar no seu ide favorito
# depois:
chmod +x scheduler.sh # permissão de execução necessária

O nome do arquivo é um exemplo prático, use o nome que preferir.

Criando as Variáveis

Vamos criar as principais variáveis dentro desse arquivo:

SESSION="claude_task" # O nome da sessão
MAX_TOKENS=300000 # O limite de tokens, eu deixo 300k para o Opus 1M, você pode testar 400k
PROMPT_CLOSE="" # Texto de encerramento para quando chegar no limite de tokens
PROMPT_RESUME="" # Texto de continuidade para um agente vazio
CALLBACKS=() # Datas e horários exatos, se minha sessão reseta as 17h, eu gosto de adicionar cinco minutos, use o formato YYYY-MM-DD HH:MM:SS

Transformando segundos em Epoch

Com os parâmetros prontos, vamos acrescentando os verificadores, esse é um script que vai rodar a cada {n} segundos, então a verificação é constante e importante para fazer tudo funcionar. Vamos agora converter os callbacks para epoch (segundos), facilitando a comparação dentro do loop:

declare -a CALLBACKS_EPOCH
for target in "${CALLBACKS[@]}";
  do CALLBACKS_EPOCH+=($(date -d "$target" +%s))
done

NEXT_CALLBACK_IDX=0

echo "[*] Iniciando automação do Claude Code na sessão tmux: $SESSION"
echo "[*] Monitorando limite de tokens: $MAX_TOKENS"

Criando o Loop verificador

Faça o loop:

while true; do
  CURRENT_EPOCH=$(date +%s) # segundo atual
  # Gatilho 1 vai estar aqui
  # Gatilho 2 vai estar aqui
  sleep 30 # intervalo de execução do script para fazer sua CPU viver mais
done

Configurando o Primeiro Gatilho

O gatilho 1 vai ser responsável pelo famoso continue dentro do chat, ele irá verificar o horário, e se for correto, vai enviar para o Claude continuar, já que o saldo voltou:

if [ $NEXT_CALLBACK_IDX -lt ${#CALLBACKS_EPOCH[@]} ]; then
  TARGET_EPOCH=${CALLBACKS_EPOCH[$NEXT_CALLBACK_IDX]}

  if [ $CURRENT_EPOCH -ge $TARGET_EPOCH ]; then
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Horário atingido! Injetando 'continue'..."
    tmux send-keys -t "$SESSION" "continue" C-m
    ((NEXT_CALLBACK_IDX++))
  fi
fi

Note que você não precisa entender como escrever arquivos .sh para entender o que foi feito, nesse gatilho o script verifica a hora, se está no tempo certo, ele gera um log em um terminal, escreve e envia no terminal do Claude.

Configurando o Segundo Gatilho

O gatilho 2 vai precisar ler a tela do terminal do Claude, extrair o consumo de tokens, para poder enviar o comando de encerramento de sessão:

# Busca "123456 tokens", pega a última linha e extrai só o número
CURRENT_TOKENS=$(tmux capture-pane -t "$SESSION" -p | grep -oE '[0-9]+ tokens' | tail -n 1 | awk '{print $1}')

# If maroto checando se passou do limite
if [[ "$CURRENT_TOKENS" =~ ^[0-9]+$ ]] && [ "$CURRENT_TOKENS" -ge "$MAX_TOKENS" ]; then
  echo "[$(date '+%H:%M:%S')] Limite de $MAX_TOKENS tokens atingido (Atual: $CURRENT_TOKENS)."
  echo "Injetando prompt de encerramento/contexto (AIPIM)..."
  tmux send-keys -t "$SESSION" "$PROMPT_CLOSE" C-m
  echo "Aguardando 20 minutos (1200 segundos)..."
  sleep 1200
  echo "[$(date '+%H:%M:%S')] Injetando prompt de retomada..."
  tmux send-keys -t "$SESSION" "$PROMPT_RESUME" C-m
  sleep 600
fi

O campo sleep 600 é um cooldown de 10 minutos, eu gosto de ser conservador aqui para poder dar espaço para o Claude fazer tudo que eu quero.

Ritual de execução

Ok, agora você tem a metodologia e o script, vamos para a parte final: como encaixar tudo isso em um processo só.

Organizar as Tasks

A primeira coisa que eu faço é instalar AIPIM no meu projeto:

npm i -g aipim # Primeiro, caso não esteja instalado globalmente
aipim install # Segundo, para instalar AIPIM no seu projeto
claude mcp add aipim http://localhost:3141/mcp # Adicione AIPIM no MCP do Claude
aipim ui # Inicializa AIPIM MCP no meu projeto, com uma UI para acompanhar - se quiser!

Nota: AIPIM aqui não é regra, você usa a metodologia que quiser, eu uso AIPIM porque é o que melhor funciona pra mim, e porque eu que fiz, hah! Gerencie seu processo da forma que achar melhor, os textos dos prompts são dinâmicos justamente pra isso.

Com AIPIM instalado e inicializado, eu abro o chat do Claude e começo a conversar com ele sobre o projeto e sobre a organização de criação de tasks, ele já vai entender o AIPIM pelo MCP conectado, quando eu acertei o que quero, peço para ele organizar diversas tasks curtas, para ele não se preocupar com o contexto agora, quero tasks bem feitas e bem estruturadas. É melhor gastar agora, para economizar muito depois.

O Claude vai cantar, e vai criar as tasks, uma por uma, pode demorar, você pode acompanhar tudo via UI se quiser, há muito mais opções que isso, mas não vem ao caso nesse post. Quando ele terminar todas as tasks, estamos prontos para o agente criar código.

Inicie a Sessão do tmux e Claude

Crie a sessão com tmux new -s claude_task, dentro dessa sessão inicie o processo do Claude com claude --dangerously-skip-permissions, se você pretende deixar ele rodando enquanto vive a vida, essas permissões são obrigatórias. A beleza do tmux é manter a sessão do terminal em background, se a janela fechar sem querer, o processo continua sendo executado. Tem alguns atalhos interessantes:

• Sair da sessão sem interromper o processo (detach): Pressione Ctrl + B, solte as teclas e pressione D. Você voltará para o seu terminal normal. O Claude continuará rodando isolado.
• Voltar para a sessão: tmux attach -t claude_task
• Matar a sessão: tmux kill-session -t claude_task
• Matar o script: pkill -f scheduler.sh, ou o nome que você usou no script

Saia da sessão fazendo o detach, e rode no seu terminal principal nohup ./scheduler.sh > scheduler.log 2>&1 &, o script vai ser executado em background, gravando todas as saídas no log.

Você agora tem dois processos rodando: o sistema de logs e o de automação. Para ver as decisões do script de automação em tempo real, use tail -f scheduler.log, para ver o Claude trabalhando e o consumo de tokens na tela, use tmux attach -t claude_task (nunca se esqueça de fazer o detach de forma correta, se não você encerra o processo).

Nota Importante Sobre --dangerously-skip-permissions

Tome cuidado para ele não apagar seu Linux todo. Brincadeira, em partes. Rodar assim é o que eu, na minha bolha, mais vejo. Você não quer ficar aceitando coisas bobas, já que tem todas as tasks definidas e bem organizadas. Mas, por algum motivo qualquer, o agente pode (embora raramente) usar um rm ou um push errado. Sim, isso é possível.

"Então, por que cargas d'água devs experientes usam assim mesmo?" Há formas de mitigar esse problema. Jamais, nunca, em hipótese alguma, use um agente autônomo (ou qualquer agente) no main; use um branch ou um git worktree descartável — no pior caso você perdeu o worktree, e não o projeto. Ah, obviamente, não use tokens de produção em projetos locais.

Se você quer ser mais paranoico (eu te entendo) e vestir o chapéu de alumínio, isole seu projeto em um container, sem permissão de sudo e sem acesso a ~/.ssh, chaves de produção ou .env de outros projetos. Aí sim, você vai estar 100% tranquilo.

O script final

Copiar e colar é muito melhor! Eu te entendo. O script final foi feito para rodar a cada 30 segundos, verificando a hora e os tokens em passagens independentes. Altere os parâmetros, e faça o teste você mesmo.

É importante ressaltar que o script continua em execução mesmo após a conclusão das tarefas. Você, como usuário humano, precisará fechar tudo manualmente em seguida. Em uma versão futura, posso considerar uma maneira de contornar isso, mas até agora não me incomodou.

#!/bin/bash

SESSION="claude_task"

MAX_TOKENS=300000

PROMPT_CLOSE="encerre a sessão, atualize a memória, o AIPIM MCP, o CLAUDE.md (se necessário) e crie um `.project/last-session.md` com o prompt para o próximo agente"
PROMPT_RESUME="leia o prompt em `.project/last-session.md` e continue o trabalho de onde parou. Sempre atualizando a memória, AIPIM MCP e o CLAUDE.md entre as tasks para manter a consistência do projeto"

CALLBACKS=(
    "2026-06-11 17:05:00"
    "2026-06-12 17:05:00"
    "2026-06-13 17:05:00"
)

declare -a CALLBACKS_EPOCH
for target in "${CALLBACKS[@]}"; do
    CALLBACKS_EPOCH+=($(date -d "$target" +%s))
done

NEXT_CALLBACK_IDX=0

echo "[*] Iniciando automação do Claude Code na sessão tmux: $SESSION"
echo "[*] Monitorando limite de tokens: $MAX_TOKENS"

while true; do
    CURRENT_EPOCH=$(date +%s)

    if [ $NEXT_CALLBACK_IDX -lt ${#CALLBACKS_EPOCH[@]} ]; then
        TARGET_EPOCH=${CALLBACKS_EPOCH[$NEXT_CALLBACK_IDX]}

        if [ $CURRENT_EPOCH -ge $TARGET_EPOCH ]; then
            echo "[$(date '+%Y-%m-%d %H:%M:%S')] Horário atingido! Injetando 'continue'..."
            tmux send-keys -t "$SESSION" "continue" C-m
            ((NEXT_CALLBACK_IDX++))
        fi
    fi

    CURRENT_TOKENS=$(tmux capture-pane -t "$SESSION" -p | grep -oE '[0-9]+ tokens' | tail -n 1 | awk '{print $1}')

    if [[ "$CURRENT_TOKENS" =~ ^[0-9]+$ ]] && [ "$CURRENT_TOKENS" -ge "$MAX_TOKENS" ]; then
        echo "[$(date '+%H:%M:%S')] Limite de $MAX_TOKENS tokens atingido (Atual: $CURRENT_TOKENS)."
        echo "Injetando prompt de encerramento/contexto (AIPIM)..."

        tmux send-keys -t "$SESSION" "$PROMPT_CLOSE" C-m

        echo "Aguardando 20 minutos..."
        sleep 1200

        echo "[$(date '+%H:%M:%S')] Injetando prompt de retomada..."
        tmux send-keys -t "$SESSION" "$PROMPT_RESUME" C-m

        sleep 600
    fi

    sleep 30
done

Informação curiosa, e totalmente irrelevante, se você chegou até aqui (obrigado por isso): esse texto foi integralmente escrito por um humano, mesmo sendo focado em IA.