Arquitetura do Claude Code em Profundidade: O que o Código-Fonte Vazado Revela
O código-fonte vazado do Claude Code expôs 512 mil linhas de TypeScript em produção. Aqui está a análise completa da arquitetura — sistema de ferramentas, mecanismo de consulta, padrões multi-agente e compressão de contexto.
Olá a todos, sou a Dora. Não estava procurando uma toca de coelho em março de 2026. Uma mensagem apareceu no meu feed: “O código-fonte do Claude Code vazou através de um arquivo map no registro npm deles.”
Fechei a aba em que estava e não olhei para trás.
O que se seguiu foi uma das tardes genuinamente mais interessantes que passei estudando como uma ferramenta de IA de produção é realmente construída. Não por causa do drama do vazamento — isso envelhece rápido — mas porque o código é algo raro: um CLI agêntico real, lançado e comercialmente dominante, examinado com 512.000 linhas de detalhe.
Aqui está o que percebi.
Por Que o Código-Fonte Vazado É uma Oportunidade Rara de Estudo de Arquitetura
Após o vazamento do Claude Code, o código-fonte emergiu — exposto por meio de um arquivo .map mal configurado no próprio pacote npm da Anthropic — os desenvolvedores rapidamente perceberam que não se tratava de um wrapper em torno de uma API de chat. De acordo com a análise do cybersecuritynews.com sobre o incidente, a exposição incluiu aproximadamente 1.900 arquivos e mais de 512.000 linhas de TypeScript estrito, com o ponto de entrada principal sozinho pesando 785KB.
A stack em si já é interessante: Bun como runtime (não Node.js), React com Ink para renderização de UI no terminal, e Zod v4 para validação de esquema em toda parte. Usar padrões de componentes React em um CLI significa gerenciamento de estado, re-renderizações e componentes de UI combináveis dentro do seu terminal. É uma escolha deliberada e ousada.
O que torna isso digno de estudo além dos memes: os padrões de arquitetura do Claude Code aqui se aplicam a qualquer equipe que esteja construindo sistemas agênticos sérios.

O Sistema de Ferramentas — Mais de 40 Módulos Auto-Contidos com Controle de Permissão
A primeira coisa que me chamou atenção foi como o sistema de ferramentas está limpo e isolado. Cada ferramenta define seu próprio esquema de entrada, nível de permissão e lógica de execução — de forma independente. Não há estado mutável compartilhado infiltrando-se entre as ferramentas.
BashTool e FileReadTool estão no mesmo registro, mas têm perfis de risco fundamentalmente diferentes. A execução do Bash pode alterar o estado do sistema; a leitura de arquivos é somente leitura. A arquitetura os trata de acordo, bloqueando cada um atrás de seu próprio nível de permissão em vez de aplicar uma política geral. Essa separação importa enormemente em sistemas agênticos de produção, onde um modelo de permissão que vaza entre ferramentas é um problema de segurança e confiabilidade esperando para acontecer.
AgentTool é o inteligente. Ele permite que o sistema gere sub-agentes como apenas mais uma chamada de ferramenta — sem camada de orquestração especial, sem modelo de processo separado. Sub-agentes são cidadãos de primeira classe no mesmo registro de ferramentas. Essa decisão de design mantém a arquitetura plana e previsível.
A definição base da ferramenta sozinha abrange cerca de 29.000 linhas de TypeScript. Isso não é inchaço — é como a validação de esquema rigorosa, a aplicação de permissões e o tratamento de erros realmente parecem nessa escala. A documentação oficial do Claude Code da Anthropic confirma essa filosofia centrada em ferramentas: as ferramentas são o que tornam o sistema agêntico.
O Motor de Consulta de 46K Linhas — O Verdadeiro Cérebro do Claude Code
QueryEngine.ts tem 46.000 linhas. Deixe isso assentar por um momento.
Este é o módulo que lida com todas as chamadas de API LLM, streaming, cache e orquestração. Em um único arquivo. Isso pode soar como um sinal de alerta — e dependendo das convenções do seu código, você estaria certo em questioná-lo — mas o raciocínio é coerente: tudo que toca a API do modelo está em um único lugar, o que significa que a lógica de retry, o tratamento de limite de taxa, o gerenciamento de orçamento de contexto e os erros de streaming são todos raciocinativos juntos.
O loop de consulta auto-recuperável é a parte que me pegou desprevenida. Quando o orçamento de contexto se aproxima do seu limite, o motor não trava nem pede ajuda. Ele aciona a compressão automaticamente, abrindo um buffer antes do teto e gerando um resumo estruturado do que foi discutido. Isso não é um hack — é um comportamento projetado. Para qualquer pessoa construindo sessões de agente de longa duração, esse padrão vale a pena ser estudado diretamente.

Orquestração Multi-Agente — Coordenador, Workers e o Padrão Mailbox
O sistema multi-agente usa o que o código-fonte vazado chama de padrão mailbox para operações perigosas. Veja o que isso significa na prática: um agente worker executando uma tarefa não pode aprovar independentemente uma operação de alto risco. Em vez disso, ele envia uma solicitação para o mailbox do coordenador e aguarda. O coordenador avalia e aprova ou rejeita.
O mecanismo de claim atômico impede que dois workers lidem com a mesma aprovação simultaneamente — um detalhe sutil, mas crítico em qualquer sistema com execução paralela. O espaço de memória compartilhada entre todos os agentes significa que a equipe mantém contexto coerente sem re-busca redundante.
Isso é uma divergência significativa dos designs multi-agente ingênuos onde cada agente opera com total autonomia. A divisão coordenador/worker com gates de aprovação é como você obtém paralelismo sem caos. Equipes construindo camadas de orquestração para seus próprios sistemas agênticos fariam bem em ler a documentação de padrões agênticos da Anthropic antes de projetar os seus próprios.
Compressão de Contexto em Três Camadas — Engenharia para Sessões Longas
Esta é provavelmente a peça de engenharia mais diretamente útil em toda a base de código para qualquer pessoa construindo aplicações de IA em produção.
O Claude Code usa três estratégias de compressão distintas, cada uma acionada em um ponto diferente:
MicroCompact edita o conteúdo em cache localmente, sem chamadas de API. Saídas antigas de ferramentas são aparadas diretamente. Rápido, barato, transparente.
AutoCompact é acionado quando a conversa se aproxima do teto da janela de contexto. Ele reserva um buffer de 13.000 tokens e então gera até um resumo estruturado de 20.000 tokens da sessão. Há um circuit breaker integrado — após três falhas consecutivas de compressão, ele para de tentar novamente. Sem loops infinitos.
Full Compact comprime toda a conversa e, em seguida, reinjecta arquivos acessados recentemente (limitados a 5.000 tokens por arquivo), planos ativos e esquemas de habilidades relevantes. Após a compressão, o orçamento de trabalho é redefinido para 50.000 tokens.
O que é notável é o que essa arquitetura implica para ferramentas que ignoram a compressão completamente. Ferramentas agênticas que não gerenciam o orçamento de contexto simplesmente falharão em escala — degradando silenciosamente ou atingindo erros graves. A abordagem em três camadas é um exemplo raro de projetar para longevidade de sessão desde o início, não adicioná-la depois.

Feature Flags como Arquitetura — 108 Módulos Que Não Existem em Produção
Uma das descobertas menos discutidas do código-fonte vazado: 108 módulos controlados por feature flags, removidos de builds externos via eliminação de código morto em tempo de compilação do Bun.
KAIROS, VOICE_MODE, DAEMON — estes não existem na versão que você instala. O código está lá no código-fonte, mas o Bun o elimina em tempo de compilação com base na configuração de feature flags. O bundle de produção é enviado limpo. É assim que você itera sobre novas capacidades sem tocar no que já está nas mãos dos usuários.
A ironia é bem documentada: o Undercover Mode, um subsistema projetado especificamente para impedir que codinomes internos apareçam em commits git ou saídas, estava presente no código-fonte vazado. O sistema construído para evitar vazamentos não conseguiu evitar o próprio vazamento. Não é uma falha catastrófica de segurança, mas uma instrutiva sobre onde o risco realmente se acumula nos pipelines de entrega de software.
Telemetria Integrada ao Loop Principal
Dois sinais de telemetria no código-fonte vazado que continuam me fazendo pensar:
Uma métrica de frustração rastreia a frequência de palavrões como um sinal de UX. Se os usuários estão xingando a ferramenta, algo está quebrando — um indicador antecedente, não tardio.
Um contador de “continue” rastreia com que frequência os usuários digitam a palavra “continue” no meio de uma sessão. Para um CLI agêntico, isso é um proxy para travamentos — momentos em que o agente perdeu o momentum e o humano teve que empurrá-lo para frente.
Nenhuma delas é uma métrica de vaidade. Ambas revelam modos de falha específicos que a análise padrão perderia. Se você está construindo qualquer produto de IA com sessões de interação estendida, instrumentar o comportamento do agente dessa forma vale o tempo de engenharia.
O Que Isso Diz a Construtores Sobre Decisões de Stack
A conclusão honesta de estudar esta arquitetura do Claude Code: construir um CLI agêntico de produção do zero é um compromisso substancial de engenharia. O sistema de ferramentas, o motor de consulta, a orquestração multi-agente, a compressão de contexto e a telemetria juntos representam anos de iteração, não meses.
Isso não é um argumento contra a construção. É um argumento por ser claro sobre o que você está assumindo. Padrões como o sistema de aprovação mailbox e a compressão em três camadas são exportáveis — você não precisa de 512.000 linhas para implementar as ideias principais.
Onde o cálculo de construir vs. comprar muda está no acesso e agregação de modelos. A arquitetura assume acesso direto a um único provedor de modelo. Equipes trabalhando com múltiplos provedores de modelo, ou construindo produtos que precisam permanecer agnósticos de modelo, enfrentam um conjunto diferente de trade-offs inteiramente.
Os padrões aqui valem ser emprestados. A complexidade vale a pena ser entendida antes de se comprometer a replicá-la.

FAQ
Como o sistema de ferramentas do Claude Code difere da chamada de função padrão?
A chamada de função padrão trata as ferramentas como uma lista plana. O Claude Code adiciona gates de permissão por ferramenta, contextos de execução isolados e validação de esquema em cada limite — evitando vazamento de estado entre ferramentas e aplicando acesso de menor privilégio, o que importa quando o BashTool pode modificar o estado do sistema.
O que é o padrão mailbox e quando os construtores devem usá-lo?
Ele roteia operações perigosas de agentes worker para um coordenador para aprovação, em vez de executar autonomamente. Use-o sempre que tiver execução paralela de agentes e precisar de um mecanismo de aprovação humano no loop ou hierárquico para ações de alto risco. Custo de throughput, ganho de segurança.
Como o Claude Code lida com limites de janela de contexto em escala?
Compressão em três camadas: MicroCompact (edições locais, sem custo de API), AutoCompact (acionado perto dos limites, gera um resumo estruturado com buffer de token reservado) e Full Compact (compressão completa da conversa com reinjeção seletiva de arquivos). Projetado para sessões longas sem intervenção manual.
O que são feature flags em tempo de compilação e por que ferramentas de IA de produção as usam?
Elas permitem que o código para recursos não lançados exista na fonte sem aparecer em builds de produção. O Bun elimina o código desativado em tempo de compilação, para que usuários externos nunca encontrem recursos que não estão prontos — separando o envio da prontidão.
É legal estudar e referenciar o código-fonte vazado para inspiração de arquitetura?
Vale tratar com cuidado. O código-fonte vazado é propriedade intelectual da Anthropic. Estudar padrões arquitetônicos para fins educacionais está em território diferente do que copiar código diretamente. A documentação oficial da Anthropic permanece a referência apropriada para qualquer coisa que você construa em cima dos sistemas deles. Em caso de dúvida, consulte seu próprio advogado.

O que continuo voltando é o quanto dessa arquitetura se trata de gerenciar falhas com elegância. Os circuit breakers na compressão, o padrão mailbox para operações perigosas, o isolamento de permissão entre ferramentas — esses não são designs otimistas. Eles foram construídos por pessoas que viram as coisas darem errado e decidiram projetar em torno disso.
Isso é um tipo diferente de maturidade do que velocidade de recursos.
Ok, o compartilhamento de hoje terminou. Até a próxima.
Posts Anteriores:
- Compare GPT-5, DeepSeek e outros modelos em desempenho e custo no mundo real
- Entenda o cache de contexto do DeepSeek V4 e como ele melhora a eficiência de sessões longas
- Aprenda sobre os limites de taxa do DeepSeek V4 e restrições de escalabilidade para sistemas de produção
- Explore os preços do DeepSeek V4 e o custo por milhão de tokens para aplicações em grande escala
- Veja quanto VRAM de GPU o DeepSeek V4 requer para implantações reais
