Claude Code usa Bun reescrito em Rust

• A partir do Claude Code v2.1.181, ele passou a incluir uma versão do Bun portada para Rust, o que deixou a inicialização no Linux 10% mais rápida, embora a maioria dos usuários quase não perceba a mudança
• Ao inspecionar as strings do executável, é possível confirmar Bun v1.4.0, que ainda não tem tag oficial, além de caminhos de arquivos-fonte em Rust
• Em ~/.local/bin/claude, foram encontrados 563 nomes de arquivos .rs, incluindo src/runtime/bake/dev_server/mod.rs
• Também é possível verificar que a versão embutida é 1.4.0 pré-carregando um arquivo TypeScript com BUN_OPTIONS para exibir Bun.version
• A versão em Rust foi distribuída como Bun canary e já roda em produção em milhões de dispositivos por meio do Claude Code

---

Bun em Rust embutido no Claude Code

• Segundo Rewriting Bun in Rust, o Claude Code v2.1.181, lançado em 17 de junho, passou a usar o port para Rust
  • A inicialização no Linux ficou 10% mais rápida
  • Fora isso, os usuários quase não perceberam diferenças, e Jarred Sumner avaliou isso como “Boring is good”
  • Já está rodando em produção em milhões de dispositivos por meio do Claude Code
• É possível encontrar a versão embutida do Bun nas strings do executável do Claude

strings ~/.local/bin/claude | grep -m1 'Bun v1'

• Em um ambiente macOS arm64, a saída é Bun v1.4.0 (macOS arm64)
• Na época, a release estável mais recente no GitHub era a Bun v1.3.14, de 12 de maio, então o Claude Code incluía uma prévia da v1.4.0 que ainda não havia sido lançada oficialmente
• A versão em Rust foi disponibilizada como Bun canary e pode ser instalada com bun upgrade --canary

Código-fonte em Rust e verificação de versão

• Ao extrair os caminhos do código-fonte Rust do executável, é possível ver 563 nomes de arquivos

strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'

• A lista inclui os seguintes caminhos

src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs

• O método compartilhado por Ajan Raj usa BUN_OPTIONS para pré-carregar um arquivo TypeScript e fazer o Claude Code exibir diretamente Bun.version embutido

cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version

• Esse comando também mostra 1.4.0
• No commit de 17 de maio, a versão no package.json foi alterada para 1.4.0 e permaneceu assim desde então, mas ainda não foi incluída em nenhuma release com tag fora do canary

[GN⁺]

Opiniões do Hacker News

• É difícil entender por que uma TUI precisa passar por JavaScript e rodar em React para terminal. O fato de a Anthropic ter adquirido até o runtime para melhorar a TUI faz duvidar ainda mais da qualidade de engenharia. Se a reescrita fosse tão fácil, teria sido muito mais barato portar o Claude Code para uma linguagem nativa

  • Como já é um negócio que funciona bem e gera uma receita enorme, “por que esta tecnologia?” parece mais uma decisão de negócio do que técnica. A tecnologia escolhida no início está cumprindo seu papel, então há poucos motivos para trocá-la mesmo que a arquitetura não seja perfeita
    Reescrever nem mesmo o Bun é fácil, e uma ferramenta de desenvolvimento não UI, com contratos de API e testes claros, é mais fácil de confiar depois de reescrita do que uma ferramenta de UI com funcionalidade ambígua e poucos testes
  • Usar Claude, OpenCode e Ghostty juntos faz programas interativos de terminal consumirem CPU e bateria de forma intensa, e até deixa quente um notebook que passou a noite em suspensão. Com mais de 40 anos de precedentes como curses/ncurses, Emacs, Vim e MS-DOS, fico curioso sobre por que forçaram a entrada de tecnologias web
  • Vi um texto dizendo que uma empresa famosa de Haskell migrou para Python por causa da velocidade de desenvolvimento iterativo com LLMs. Há muitos dados de treinamento de React, e o tempo de compilação de TypeScript também é curto em comparação com Rust etc.
    É provável que o código voltado ao usuário e a camada de UX que muda rapidamente migrem para sistemas dinâmicos que permitem iteração rápida, enquanto a camada de infraestrutura vá para ambientes de sistemas seguros como Rust. Java/C# ficam no meio-termo, mas daqui para frente TypeScript/Python devem bastar para UX, enquanto Rust é mais adequado para trabalho de sistemas, então seu espaço tende a diminuir
    https://avi.press/posts/2026-07-10-after-7-years-in-producti...
  • Se considerarmos que a Anthropic escreve o Claude Code com IA, JavaScript não é uma escolha ruim. Há muitos dados de treinamento e ele também evita problemas de multithreading e gerenciamento de memória que podem confundir a IA em outras linguagens de alto desempenho, o que o torna bom para criar software rapidamente com IA
  • A OpenAI decidiu há cerca de um ano reescrever em Rust o Codex. Se reescrever é realmente fácil, também é preciso perguntar por que o Bun é necessário e por que não portar todo o código JavaScript para Rust
    https://github.com/openai/codex/discussions/1174

• Pelo texto original de Jarred, parece claro que o motivo da transição é que coisas que eram manuais em Zig passam a ser automatizadas em Rust. Como humanos e agentes são ambos não determinísticos, rastrear manualmente o tempo de vida da memória e liberações explícitas em Zig faz com que bugs por omissão se acumulem por muito tempo, enquanto Rust elimina essa classe de erros e se torna um bom compromisso do ponto de vista da gestão de engenharia
  Em especial, erros do compilador são uma proteção determinística necessária para agentes de código, e funciona bem quando você dá ao Claude uma forma de testar a correção e o objetivo de “fazer compilar”. A abordagem generalizada de transformar saídas probabilísticas em garantias firmes por meio de testes determinísticos está resumida em https://michael.roth.rocks/blog/verification-surface/

  • Zig e C não são adequados quando se criam muitas pequenas alocações cujos tempos de vida são independentes entre si. Para usá-las de forma robusta, é preciso gerenciar diretamente os tempos de vida, agrupando alocações em uma arena ou usando buffers fixos
    Fazendo isso, Zig também pode ser tão robusto quanto Rust, mas, se você quer padrões de alocação no estilo de linguagens gerenciadas, que LLMs preferem, Zig não é a escolha certa
  • Quem cuida disso automaticamente são linguagens com garbage collection. Mesmo em Rust, é preciso pensar e rastrear tempos de vida de memória, mas o borrow checker impede tratamentos incorretos e dá feedback imediato para correção, então é bom para LLMs usarem. Parâmetros de referência imutáveis por padrão também ajudam a prevenir grandes problemas de desempenho
  • Como atualmente há muito Rust unsafe no Bun, fico em dúvida se dá para dizer que ele elimina automaticamente classes de erros: https://news.ycombinator.com/item?id=48967630
  • Pela minha experiência, LLMs detectam bugs de memória com bastante facilidade. Isso parece apenas um evento de marketing bem-sucedido da Anthropic
  • Pelo que me lembro, esta reescrita em Rust foi toda unsafe, então é bem possível que ela não elimine automaticamente esse problema

• Independentemente da avaliação de Jarred ou de Simon Willison, vejo isso de forma bastante negativa. O problema maior do que a aquisição do Bun pela Anthropic ou a reescrita por IA é a forma imatura como tudo foi conduzido: começou com a atitude de “é só meu branch, vocês estão exagerando” e acabou com a mesclagem de um PR com mais de 1 milhão de linhas em menos de um mês
  A comunicação foi muito malfeita, prejudicou a confiança e aumentou a divisão, e fico me perguntando se era tão difícil seguir a abordagem que a equipe do TypeScript adotou no 7.0

  • No fim, a maioria dos usuários do Claude Code não percebeu ou não se importa, e quem problematiza isso é uma minoria minúscula, então talvez, na prática, não importe
  • O TS7 também é um exemplo típico de portar linha por linha para outra linguagem, em vez de revisar seriamente a arquitetura

• O Bun v1.4.0 incluído no Claude parece ser uma versão de preview ainda não pública. Se for esse o caso, parece que o projeto FOSS Bun se transformou silenciosamente em outra coisa, então fico feliz por ter deixado a investigação apenas como TODO e não tê-lo adotado
  Não consigo encontrar documentos de governança do Bun, e fico me perguntando se agora a estrutura é, na prática, que a Anthropic decide tanto o trabalho quanto o que será mesclado

  • É difícil entender a conclusão de que mudar para Rust mata o projeto
  • O PR é público, então qualquer pessoa pode compilar e usar, e a equipe da Anthropic apenas decidiu usá-lo primeiro
  • Pelo que sei, na prática a estrutura depende de Jarred estar disposto a aceitar aquilo naquela semana. O changelog do Claude Code já mencionava a mudança para a versão Bun 1.4.0 havia quase um mês, mas, como o registro foi escrito por IA, não seria estranho se a maioria não tivesse lido
  • Eu também investiguei adotar o Bun e decidi não usar por causa da instabilidade; vendo este caso, parece que foi a decisão certa

• Não entendo por que complicaram tanto em torno do Bun. Se um agente consegue portar Zig para Rust, o Claude Code também poderia ter sido reescrito diretamente em Rust a partir de JavaScript, eliminando a dependência de runtime e melhorando o desempenho.

  • Se você considerar que a reescrita do Bun em Rust praticamente não tem relação com a estratégia de produto da Anthropic, não há motivo para confusão.
  • Olhando apenas para o Claude Code, uma reescrita direta em Rust teria sido melhor, mas isso reduziria bastante o valor da aquisição da Bun/oven.sh.
    O Bun provavelmente tem usuários fora do Claude Code, tanto externos quanto internos à Anthropic, e garante um runtime JavaScript e um ecossistema de ferramentas que modelos de programação podem preferir. No futuro, a Anthropic poderia até oferecer uma nuvem especializada em executar e gerenciar esses apps; só de conquistar a comunidade de desenvolvedores, já teria uma influência muito maior do que portar apenas o Claude Code para Rust.
  • Também é questionável se o Claude Code realmente tem gargalos de desempenho. Um runtime JavaScript tem um ecossistema grande de ferramentas e facilita o desenvolvimento de plugins, então é suficientemente adequado.

• Tirando especulação e emoção, a qualidade real de execução é o que desperta curiosidade. É preciso verificar não só a velocidade de inicialização, mas também uso de RAM e CPU, loops infinitos e deadlocks; se estiver igual ou melhor que antes, é bastante impressionante.
  Como desenvolvedor, não gosto da possibilidade de a IA tomar empregos, mas, se qualquer pessoa puder criar o software que deseja com pedidos simples, isso pode melhorar o mundo. Se você não gosta da coleta de dados da Microsoft, poderia mandar a IA criar um sistema operacional; se não gosta da escuta do Google, poderia mandar criar um celular — uma forma de autossuficiência tecnológica pode se tornar possível, e diante disso a estabilidade de emprego individual fica pequena.
  Por isso é ainda mais importante manter a tecnologia como open source; caso contrário, repetiremos as estruturas monopolistas existentes e ainda perderemos empregos.

  • A parte mais difícil no desenvolvimento de software é obter requisitos claros. Mesmo com uma AGI perfeita, as pessoas não conseguem expressar com clareza o que querem, então não virá um mundo em que todos criem exatamente o software que desejam.
  • Boas ferramentas só produzem resultados excelentes nas mãos de artesãos experientes. Bons desenvolvedores fazem as perguntas certas, criam mecanismos de segurança e conseguem ajustar manualmente os resultados onde for necessário.
  • Chamar de democratização da tecnologia modelos fechados atrás de paywalls pagos e subsidiados é ingênuo demais. Parece que a estratégia de usar o porte do Bun para Rust principalmente como marketing funcionou muito bem.

• Recentemente, usando o Claude Code dentro de uma aba do Kitty, tive uma falha de segmentação e, depois disso, a aba inteira parou de responder a entradas. Aparece um link de denúncia, mas não dá para clicar, e ele está codificado, então nem dá para verificar quais informações seriam enviadas.

  • Em termos de ideias e recursos, o Bun é esmagadoramente melhor do que outros runtimes JavaScript, mas a estabilidade é péssima, e ele teve cerca de 20 vezes mais falhas de segmentação do que o Node. Esse número se baseia em dados de telemetria do New Relic.
  • Se o shell não exibiu Segmentation fault, é bem provável que tenha sido um travamento, não uma falha de segmentação. Se fosse um erro real, depois de voltar ao shell você poderia digitar reset, mesmo sem aparecer na tela, para recuperar a aba.
  • Uso Ghostty e Claude Code no MacBook do trabalho, mas ainda não passei por esse problema. Antes, um vazamento de memória descontrolado travava o sistema e exigia reinicialização, mas isso desapareceu nas últimas semanas; embora seja cedo para afirmar, é possível que o porte para Rust tenha reduzido os vazamentos de memória.
  • No Ghostty, ao usar a interface interativa de perguntas do Claude, há travamentos parecidos: além da rolagem, nenhuma entrada é aceita, incluindo seleção ou cancelamento. Ainda assim, não acho que tenha relação com o Bun.
  • A versão em Zig também tinha falhas de segmentação e, se isso foi portado linha por linha para unsafe Rust, o código que causava o problema também continua lá. Isso não será resolvido antes de uma refatoração para Rust idiomático e seguro em memória.

• Eles parecem engenheiros péssimos, embora muito bem-sucedidos, que descrevem bem o problema e têm um orçamento de tokens ilimitado. Se tivessem de pagar diretamente o custo dos tokens, teriam incentivo financeiro para melhorar a eficiência do software.
  A realidade oculta dos data centers de IA é que, mesmo quando a eficiência dos clusters de GPU é de apenas 40 a 60%, eles compensam comprando mais equipamentos com dinheiro. Talvez temam concorrentes chineses justamente porque eles não têm margem para desperdiçar desse jeito.

• Este trabalho é transpilação, e a qualidade também não é boa. O código gerado está longe de Rust idiomático e pode ser considerado uma aberração.

  • Ainda assim, parece funcionar corretamente. Desta vez, é basicamente uma etapa inicial de conversão mecânica linha por linha; como a próxima etapa deve refiná-lo para Rust idiomático, não parece uma boa ideia continuar apostando contra essa reescrita.
  • Pensando em estabilidade, eficiência e custo, teria sido muito mais razoável usar ou escrever um conversor source-to-source que preservasse ao máximo a estrutura original.
    Normalmente, uma reescrita incorpora as lições aprendidas com a base de código existente, mas, ao portar arquivo por arquivo com agentes, não há esse benefício. De qualquer forma, o resultado vira uma tradução não idiomática, mas usar LLM ainda adiciona não determinismo e um custo enorme.
  • É preciso ver exemplos concretos do código Rust considerado aberrante.
  • Fico curioso por que não transpilaram diretamente para LLVM IR.
  • Se o projeto atingir o objetivo de segurança de memória, é discutível se o código ser idiomático realmente importa.

• Recentemente, o Claude Code está muito mais instável do que antes, e erros de renderização na TUI frequentemente corrompem o histórico da conversa.

  • Uso Claude a contragosto desde fevereiro e, desde o começo, ele foi a pior TUI que já usei, com falhas de renderização, erros de entrada pelo teclado e afins. Mesmo assim, na última semana piorou ainda mais, a ponto de começar a quebrar a sessão do terminal, com alguns caracteres digitados não aparecendo.
    Colocar em segundo plano, executar reset e trazer de volta ao primeiro plano corrige. Quando pedi ao Claude para diagnosticar, ele disse que não tinha esse bug e que era culpa de outro programa, mas só estavam rodando tmux e Claude. Se a versão em Rust foi aplicada recentemente, o momento da queda de qualidade bate mais ou menos.
  • No Windows, sempre que redimensiono a janela, a saída fica completamente corrompida e preciso pedir novamente a resposta que acabou de ser dada. Não é um problema novo, mas sinto que piorou recentemente.
  • Não sou contra IA em si, mas a Anthropic foi longe demais e está entregando código de baixa qualidade feito por IA. Engenheiros reais deveriam continuar intervindo e guiando as ferramentas, mas a Anthropic parece querer deixar 100% do código nas mãos da IA.