Claude consegue operar criptomoedas? — O que aprendi rodando um agente autônomo por 7 dias

Dei ao Claude R$203 e pedi para operar cripto por uma semana. Ele perdeu 4%.

Essa é a manchete. É também a coisa menos interessante sobre o experimento.

A parte interessante é que ao longo de sete dias, 708 decisões, 16 trades e um bug muito específico que fez o agente esquecer seus próprios planos a cada quinze minutos por dois dias seguidos, aprendi exatamente que tipo de pergunta um pequeno experimento de trading autônomo consegue e não consegue responder. A resposta para "o Claude é um bom trader?" é: essa execução não te conta, e aqui está o porquê. A resposta para "a infraestrutura do experimento expôs o comportamento do modelo de forma inspecionável?" é sim — e isso acaba sendo uma pré-condição que eu não sabia que estava construindo.

Este é o companion piece de portfolio para o writeup completo da Fase 1. Onde aquele é denso em gráficos e metodologia, este é o que eu te contaria tomando um café sobre os sete dias em que deixei um LLM operar dinheiro real.

O setup, em números

• Período: 2026-04-17 → 2026-04-24, sete dias.
• Capital: R$203,24 → R$195,18 (−3,97%).
• Cadência: EventBridge dispara a cada 15 minutos; uma invocação do Lambda = um tick de decisão.
• Volume: 708 decisões, 26 tentativas de compra (9 executadas), 15 tentativas de venda (7 executadas).
• Round-trips fechados: 7. Taxa de acerto: 2/7. Um de fato bateu o alvo ancorado.
• Custo de infraestrutura: ~US$ 0,075 em 729 invocações de Lambda.

Sim, a taxa de acerto é ruim. Não, o experimento não foi projetado para validar isso.

A arquitetura, em um diagrama

Antes de qualquer pergunta sobre trading, a primeira coisa que eu precisava acertar era não explodir. Isso significou colocar as chaves da corretora, o banco de dados e o dashboard em três workspaces separados, com fronteiras de confiança explícitas.

┌──────────────────────────────────────────────────────────┐
│  Agent Lambda (um tick por disparo)                      │
│  - Tem: chave da Anthropic, chaves da Binance            │
│  - NÃO tem: acesso ao banco                              │
│  - Outputs vão para a API só via contrato assinado       │
└──────────────────────────────────────────────────────────┘
              │                              ▲
              ▼                              │
┌──────────────────────────────────────────────────────────┐
│  API + Postgres no Railway                               │
│  - Tem: banco, regras de validação, camada de risco      │
│  - NÃO tem: chaves da corretora                          │
│  - Owns: ciclo de vida do Trade, target/stop, status     │
└──────────────────────────────────────────────────────────┘
              │
              ▼
┌──────────────────────────────────────────────────────────┐
│  Dashboard (somente leitura)                             │
│  - Tem: acesso de leitura à API                          │
│  - NÃO tem: nada que possa colocar uma ordem             │
└──────────────────────────────────────────────────────────┘

Se o agente sair do controle, o pior que pode fazer é mandar ordens que a API rejeitará (por causa da validação e da camada de risco) ou que a Binance rejeitará (por causa de filtros de LOT_SIZE e restrições de saldo). Ele não consegue ler o banco, não consegue reescrever seu próprio estado, não consegue cutucar o dashboard. O dashboard, por sua vez, não consegue colocar uma ordem mesmo se comprometido. Três chaves, três caixas, três raios de impacto.

Quero sinalizar isso não porque é brilhante — é o movimento óbvio — mas porque todo bug que peguei durante a semana apareceu porque construí assim. Se o agente fosse um único binário com as três responsabilidades, eu não teria conseguido te dizer se um fechamento que falhou foi culpa do Claude, do meu código ou da Binance. Com essas fronteiras, toda falha tem um endereço.

Cinco correções que entraram no meio da fase

A Fase 1 deveria ser uma execução limpa. Não foi. Cinco coisas distintas quebraram entre 2026-04-17 e 2026-04-24, e o padrão entre todas vale ser nomeado de cara: nenhuma delas foi falha de raciocínio do Claude. Todas foram meu código ou a corretora. O agente continuou fazendo a coisa certa. Eu fiquei movendo as traves do gol.

1. O bug do loop de memória (12,1% → 93,6%)

Nos primeiros dois dias, o Claude estava ancorando stops e targets nas suas teses ("stop BTC R$370k, target R$392k, horizonte 24h"), e depois esquecendo no próximo tick e produzindo um plano diferente sem reconhecer o anterior. Em 224 decisões pré-correção, só 12,1% das teses referenciavam um plano. O agente tinha uma visão de mercado mas nada de continuidade.

A correção foi para produção em 2026-04-19 14:04 UTC: passar as últimas vinte linhas de Decision de volta no prompt como um bloco de "Ticks recentes", mais um parágrafo de scaffolding no system prompt pedindo ao Claude para honrar compromissos que ele tinha feito consigo mesmo. Mesmo modelo. Mesmo corpo de prompt. Mesmo capital. Só um canal de contexto que estava faltando.

Depois da correção: 93,6% das teses referenciavam um plano. +81,5 pontos percentuais numa métrica em que dá para fazer grep.

Tem uma meta-lição aí. Não era falta de disciplina do Claude. Era falta de visão do próprio trabalho passado. O modelo já vem com atenção; a infraestrutura ao redor dele precisa alimentar os tokens certos.

2. Persistência de target/stop

Uma vez que o Claude estava ancorando targets, o próximo problema é que eu pedia para ele recalcular a cada tick. Isso é caro em tokens e frágil na prática. A correção foi prosaica: adicionar as colunas target_price, stop_price e horizon_at no modelo Trade. Computar uma vez na abertura, armazenar, e expor de volta a cada tick como uma tag de status determinística (TARGET_HIT, STOP_HIT, HORIZON_EXPIRED). O agente lê a tag; não precisa rederivar do tape de preços.

É o tipo chato de mudança arquitetural que desaparece no substrato. Vale nomear porque o lugar certo do estado é o banco, não o prompt — e me levou dois dias rodando o agente para internalizar isso.

3. Filtro LOT_SIZE da Binance

Cinco tentativas consecutivas de fechar ETH/SOL falharam em sequência com -1013 LOT_SIZE. O filtro de ordem da Binance rejeita quantidades que não estão alinhadas ao stepSize do símbolo. Eu estava só passando a quantidade que o Claude propunha, e "0,0234" não passa o filtro para um símbolo que exige incrementos de 0,001.

A correção foi uma utilidade pequena:

function floorToStepSize(qty: number, stepSize: number): number {
  const decimals = Math.max(0, Math.log10(1 / stepSize));
  const factor = 10 ** decimals;
  return Math.floor(qty * factor) / factor;
}

O que quero destacar nesse episódio é o que o Claude fez ao longo desses cinco fechamentos rejeitados. O raciocínio do agente não degradou. A convicção ficou consistente nas cinco tentativas. A tese não derivou para "bem, talvez eu não devesse fechar afinal" — ele continuou dizendo "fechar essa posição, eis o porquê" enquanto a camada de execução continuou recusando. É esse o comportamento que quero de um agente autônomo: manter o plano estável enquanto o operador (eu) descobre onde a execução está quebrando.

4. Semântica do validador de venda

Meu validador no lado da API estava rejeitando ordens de fechamento que não incluíssem target_price e stop_price. Claro que não incluíam — closes são saídas, não entradas. O validador estava aplicando uma regra de trade de abertura em trades de fechamento. Relaxei a regra para só abrir.

Esse foi 100% culpa minha, e é exatamente o tipo de bug que não apareceria num teste unitário limitado demais: o validador fazia a coisa certa para aberturas, que foi o que testei primeiro.

5. O misterioso cap de 500 caracteres na tese

Notei, depois do fato, que duas teses do Claude tinham sido truncadas em 500 caracteres e que o Claude tinha encurtado no retry as duas vezes. Não lembro de ter escrito um cap de 500 caracteres. Está em algum lugar do meu código. Foi imposto. O agente contornou com elegância. Trago isso porque é o tipo de coisa que, escalada, é a diferença entre um sistema que você consegue debugar e um que não. Todo limite precisa ser visível. O meu não estava.

O trade mais interessante

Dos sete round-trips fechados, exatamente um bateu seu target ancorado. Foi BTC, aberto em 2026-04-20 a R$371.329 com target R$385.000, stop R$363.000, horizonte 48 horas. A posição foi mantida por aproximadamente 60 ticks consecutivos. Os valores de target e stop não desviaram em um único desses 60 ticks. A posição fechou a R$385.309 — cerca de 1,5 hora além do horizonte original de 48 horas — e a tese de fechamento do Claude disse explicitamente "em vez de correr atrás" de um movimento maior.

Essa frase é para o que serviu a correção do loop de memória inteira. Pré-correção, o Claude no tick 60 não teria memória nenhuma do que ele tinha se comprometido no tick 1. Pós-correção, o plano permaneceu ancorado por 60 ticks e o agente honrou. O trade fez R$1,81. Ninguém vai se aposentar com R$1,81. Mas o comportamento — disciplina ao longo de um horizonte longo, saída no plano em vez de ganância — é o único comportamento com que me importo agora.

Os sete round-trips, para completude

Os três primeiros não são trades reais do Claude — são posições que já existiam antes do experimento e que o Claude herdou e fechou. As linhas relevantes são 4–7. Dessas: um target, dois vencimentos de horizonte (um positivo, um negativo), um stop. É uma amostra pequena por qualquer leitura honesta.

Quatro hipóteses, quatro respostas

Entrei na Fase 1 com quatro hipóteses de comportamento que queria testar. Onde cada uma terminou:

A linha "intestável" é a que quero sinalizar. Eu tinha construído um detector de regime que alimentaria o Claude com um prompt diferente quando o portfólio caísse abaixo de um limiar definido. O portfólio nunca cruzou. Então eu não sei se o prompt sensível a regime faz alguma coisa. A Fase 2 precisa de mais capital, mais dias ou um teste de estresse sintético — preferencialmente todos os três.

O que o P&L é e o que não é

O P&L não significa nada nessa execução. Quero ser bem clara nisso.

Dias 5–7 moveram um total de R$0,67. Não porque o Claude estava ocioso — ele tomou decisões em cada um desses ticks — mas porque o mercado não se moveu. Com uma banca pequena, em um tape de baixa volatilidade e numa janela curta, a qualidade do agente quase não tem alavancagem sobre o P&L. Dá para trocar o Claude por cara ou coroa e ter um resultado numericamente parecido. O número não é um veredicto sobre o modelo.

O número é um veredicto sobre o desenho do experimento, que é outra coisa. Uma execução de sete dias e R$203 em três criptos líquidas de alta capitalização num tape quieto é calibrada para expor comportamento, não para gerar alfa. O trabalho da Fase 1 foi construir o aparato. O trabalho da Fase 2 é apontar esse aparato para alguma coisa.

Algumas deficiências específicas que nomeio para mim mesma:

• Os targets raramente foram realistas. 1 de 7 trades bateu target. O modelo está ancorando em números que não refletem ação de preço alcançável.
• 4,9% dos ticks (35 de 708) reportaram "tape congelado". Não está claro se o fetcher de preço retornou dado velho ou se o tape estava genuinamente parado. Preciso de observabilidade ali.
• O agente nunca vê seu próprio custo de tokens. A Fase 1 tomou cada decisão de prompt sem feedback loop sobre gasto. Isso vai ser corrigido na Fase 2.

O que essa execução de fato mediu

Entrei querendo saber se o Claude conseguia operar. Saí sabendo se a infraestrutura do experimento consegue expor o que o Claude está fazendo bem o suficiente para essa pergunta fazer sentido. Parece uma reivindicação menor do que a inicial, e é. Também é uma pré-condição que eu não sabia que estava construindo.

A infraestrutura expôs:

• Um salto de 12,1% → 93,6% na taxa de referência ao plano, antes e depois de uma única correção de canal de contexto.
• 60 ticks de continuidade de plano ininterrupta no trade de target do BTC.
• Cinco falhas consecutivas de infraestrutura ao longo das quais o raciocínio do agente permaneceu coerente.
• 19 bloqueios da camada de risco que pararam exatamente o tipo de ordens que foram projetadas para parar, com duas regras redundantes disparando na mesma ordem em 20 de abril.

Sem esses sinais, eu não tenho como avaliar o agente. Com eles, "o Claude ganhou dinheiro?" deixa de ser a única pergunta — e passa a ser uma de várias menos interessantes.

O que vem a seguir

A Fase 2 vai rodar dois agentes em paralelo. A1 continua no universo atual de pares. A2 opera um universo diferente com consciência explícita de taxas, faixas de risco relativas ao capital (percentuais em vez de stops fixos em R$), um feed de notícias e sentimento (Massive, CryptoPanic) com guardrails contra overreaction e um piso mínimo de edge nas compras para que trades que não consigam cobrir taxas mais slippage não disparem. A observabilidade por tick vai incluir uso de tokens, nome do modelo e custo. Calibração de confiança também vai ser rastreada.

O ponto não é finalmente ganhar dinheiro. O ponto é continuar rodando a coisa em capital suficiente, em regimes suficientes, até que "o Claude é um bom trader?" se torne respondível. A Fase 1 disse que o aparato funciona. A Fase 2 diz: agora vamos de fato usá-lo.

Uma frase para lembrar

A coisa mais interessante que o agente fez a semana toda foi admitir que 97,4% em caixa no dia 3 de 7 era indefensável e agir em cima disso dentro do mesmo tick.

É uma frase sobre um LLM notando um viés no próprio comportamento e corrigindo sem ser estimulado. É também uma frase sobre um ganho de quatro centavos, mais ou menos, em R$203 de capital. As duas leituras são verdadeiras. Qual delas acaba sendo o fato mais importante sobre agentes autônomos é, eu acho, a pergunta que vale acompanhar nas próximas fases.

Código-fonte, dashboard e o resto dos dados vivem no writeup completo da Fase 1. Não é conselho financeiro. Apenas experimento.