Análise de desempenho e telemetria do Trae IDE, fork do VSCode da ByteDance

 (github.com/segmentationf4u1t)
2 pontos por GN⁺ 2025-07-28 | 1 comentários | Compartilhar no WhatsApp
  • O Trae IDE é baseado no VSCode, mas foram identificados consumo excessivo de recursos e problemas de privacidade
  • Independentemente das configurações do usuário, ele envia continuamente dados de telemetria para servidores da ByteDance
  • O uso de recursos é 6 vezes maior que o do VSCode, e o número de processos também é significativamente mais alto
  • Na comunidade, ao levantar questões de segurança/privacidade, ocorre censura automática e sanções
  • Há problemas de falta de explicação transparente ou de controle do usuário sobre o caminho e a finalidade da coleta de dados

Análise de desempenho e telemetria do Trae IDE: uma visão interna do fork do VSCode da ByteDance

Resumo executivo

Esta análise foca nos problemas de desempenho e privacidade do Trae IDE (um fork do Visual Studio Code feito pela ByteDance).
As principais descobertas foram o consumo excessivo de recursos (9 processos no VSCode vs. 33 processos no Trae), a transmissão contínua de dados mesmo quando o usuário bloqueia a telemetria, e problemas de censura na gestão da comunidade.

1. Contexto e metodologia da análise

Durante a avaliação de ambientes de desenvolvimento para projetos pessoais, foi feita uma análise comparativa entre três IDEs: VSCode, Cursor e Trae.
O ambiente de teste foi configurado da mesma forma para todos, com foco na verificação das diferenças de desempenho e comportamento de rede.

  • SO: Microsoft Windows 11 Pro
  • CPU: Intel Core™ i7-14700KF
  • RAM: 64GB
  • Projeto de teste: a mesma base de código carregada nos três IDEs
  • Ferramentas de monitoramento: System Informer e Fiddler Everywhere

2. Análise do consumo de recursos

Número de processos e uso de memória

No primeiro teste, foi confirmado que o consumo de recursos de cada IDE era bastante diferente.

IDE Número de processos Uso de memória Impacto no desempenho
VS Code 9 aprox. 0,9 GB referência
Cursor 11 aprox. 1,9 GB 2,1x de memória
Trae 33 aprox. 5,7 GB 6,3x de memória
  • O Trae apresenta 3,7x mais processos e 6,3x mais uso de memória em relação ao VSCode.

Feedback da comunidade e solução parcial

Após relatar esse problema no servidor Discord do Trae, a equipe de desenvolvimento reconheceu a questão e iniciou melhorias.
Na versão 2.0.2 houve alguma melhora, como a redução de cerca de 20 processos, mas o nível ainda continua alto.

  • Após a atualização (2.0.2): cerca de 13 processos e uso de memória de aproximadamente 2,5GB.

3. Investigação de tráfego de rede e telemetria

Análise inicial de rede

O monitoramento mostrou que o Trae IDE está se comunicando continuamente com servidores da ByteDance.

Experimento com as configurações de telemetria

Tentativa de desativar a telemetria

Mesmo usando a função de bloqueio de telemetria na tela de configurações, não houve mudança no comportamento de rede.

Resultado inesperado
  • As conexões com os servidores existentes continuaram mesmo após desativar a telemetria
  • Pelo contrário, foi observado um aumento na frequência de transmissão de dados

4. Análise do conteúdo transmitido

Payload de telemetria em lote

Mesmo com a telemetria desativada, dados detalhados de uso continuaram sendo enviados em tempo real, como abaixo.

  • Informações do sistema: especificações de hardware, detalhes do SO, arquitetura etc.
  • Padrões de uso: tempo em que a IDE está ativa/inativa, histórico de uso de funções
  • Métricas de desempenho: velocidade de resposta, uso de recursos etc.
  • Identificadores únicos: machine ID, user ID, informações de identificação do dispositivo
  • Informações do workspace: dados do projeto, caminhos de arquivos (parcialmente mascarados)

Rastreamento da atividade do usuário

Por meio de endpoints adicionais, também eram transmitidas informações de interação detalhada do usuário.

  • Incluindo detalhes como conexão/desconexão, tempo de atividade, foco do editor e arquivo em uso

5. Problemas na gestão da comunidade

Censura automática

  • Ao mencionar o assunto no servidor Discord, foram aplicados imediatamente blacklist automática e mute de 7 dias
  • Palavras-chave como "track" foram definidas como termos sujeitos à censura automática
  • Houve resposta repressiva a questionamentos técnicos

6. Implicações de privacidade e segurança

Problemas de soberania dos dados e controle de uso

  • Mesmo quando o usuário recusa, ocorre coleta e transmissão contínuas de dados
  • Informações muito detalhadas sobre dispositivo e atividade são enviadas a servidores externos
  • Falta clareza sobre o caminho e a finalidade do processamento dos dados coletados, e não há controle do usuário

Falta de confiabilidade e transparência

  • A configuração de telemetria não exerce função prática real
  • Faltam aviso oficial e explicação suficientes sobre a coleta de dados
  • A censura de críticas/denunciantes dentro da comunidade reduz a transparência

Resumo principal

  • O Trae IDE apresenta uso de recursos cerca de 6 vezes maior que o VSCode
  • A configuração de bloqueio de telemetria, na prática, é apenas uma opção de fachada que não funciona de verdade
  • A discussão técnica saudável na comunidade é limitada por causa da censura
  • Há falta de explicação sobre coleta/processamento de dados e ausência de escolha por parte do usuário

Esta análise foi realizada com as versões PRE-2.0.2 e 2.0.2 do Trae IDE, com base em julho de 2025.
O tráfego de rede foi capturado com ferramentas padrão de monitoramento, e todos os resultados são reproduzíveis.
Recomenda-se que os membros da comunidade façam seus próprios testes e compartilhem os resultados por canais de comunicação mais adequados.

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-28
Comentário no Hacker News
  • Também existe o TheiaIDE, uma reimplementação do tipo Eclipse parecida com o VSCode: site oficial do TheiaIDE. Alguns anos atrás ele deixava a desejar, mas agora está bem decente. A TI reconstruiu o Code Composer Studio com base no Theia, então já existe até usuário grande. Tem suporte a LSP, usa o backend do editor Monaco e tem tudo de que preciso. É parecido com o VSCode, mas com uma sensação mais “Eclipse”. Pode combinar com o seu gosto ou não, mas vale considerar como alternativa.
    • O motivo de eu continuar usando o vscode é o suporte a markdown. Em especial, uso muito o recurso de arrastar e soltar arquivos e imagens para inseri-los como links, e nenhum outro editor que conheço oferece isso. Descrição desse recurso
    • Em vez de fazer um fork do vscode, acho melhor usar o Theia, já que ele é difícil de modificar. O Theia é mantido de forma modular e permite montar a IDE que você quiser como se fosse uma biblioteca.
    • O Google Cloud Shell também é baseado em Theia. Pelo que sei, ele é bastante popular.
    • Surpreende que o eclipse ainda esteja vivo.
  • Mesmo com a coleta abaixo, eu não fico muito incomodado:
    • Informações do sistema: especificações de hardware, informações do SO, arquitetura
    • Padrões de uso: horário de atividade, duração da sessão, histórico de uso de recursos
    • Métricas de desempenho: tempo de resposta, uso de recursos
    • Identificadores únicos: ID da máquina, ID do usuário, impressão digital do dispositivo
    • Informações do workspace: informações do projeto, caminhos de arquivo (ofuscados) Fico me perguntando se sou a única pessoa que não acha isso invasivo a ponto de incomodar.
    • No meu computador, eu não quero que programa nenhum — nem mesmo o SO — faça comunicação de rede, a não ser quando isso estiver diretamente relacionado a algo que eu pedi explicitamente via GUI/CLI. Só quero permitir comunicações excepcionais quando eu tiver feito opt-in de forma explícita. Acho que o padrão atual para comunicação remota (a janela de Overton) está errado.
    • Não quero compartilhar identificadores únicos (ID da máquina, ID do usuário, impressão digital do dispositivo), nem informações do workspace (informações do projeto, caminhos de arquivo), nem informações do SO. Prefiro não compartilhar nada.
    • Mesmo com a opção de “desativar telemetry” ligada, senti que ainda era enviada muito mais informação do que eu esperava.
    • Quero sempre ser eu a decidir se forneço informações ou não. Uma vez tentei aprender a linguagem Dart, mas desisti quando o instalador disse que o Google coletava telemetry. Não consegui entender por que até uma linguagem de programação precisava disso. Nunca mais olhei para isso depois.
  • Ótima análise sobre VSCode, Trae e Cursor. Também tenho curiosidade sobre uma análise do Kiro (fork da AWS). Quero saber como as práticas de coleta de dados diferem.
    • Pela experiência prática, o Kiro passa por processos de compras corporativas de forma muito mais simples e rápida do que produtos equivalentes (dias vs meses). Não é porque o produto seja melhor, nem há evidência de que seja mais privado ou mais seguro. A maioria das empresas já tem acordos de compartilhamento de dados com a AWS, então os TAMs conseguem orientar a adoção do Kiro com facilidade. Em relação à privacidade/segurança de dados pessoais, aceito as coisas como elas são, mas no caso corporativo é interessante ver como o nível de divulgação muda o que é considerado aceitável.
  • Ótima análise. Fico curioso se a redução no número de processos, de 33 para 20, foi efeito de mover a lógica de telemetry para outro lugar (e, por isso, aumentar a atividade dos endpoints). Também queria saber o que a Bytedance tem a dizer sobre isso.
  • Eles não querem que a telemetry seja desativada; mesmo que só uma minoria a desligue, ainda assim parece importar. Fico me perguntando por quê.
    • Desativar telemetry pode ser visto como um sinal de “alguém que está escondendo alguma coisa”, então isso pode ser interpretado como motivo para coletar ainda mais dados.
    • Também pode ser um bug não corrigido, e não um comportamento intencional.
    • Acho que o próprio toggle de telemetry adiciona ruído aos dados. Por isso, sou da opinião de que seria melhor nem ter telemetry no lado do cliente. Claro, os fornecedores pensam exatamente o contrário.
    • É a teoria da navalha de Ockham em ação (a explicação mais simples, isto é, a intenção essencial).
  • Tenho ficado bem satisfeito por ter voltado recentemente para TUI (helix editor). Também estou testando o ZED e imagino que, por ser um produto comercial, ele provavelmente tenha telemetry. Mesmo assim, aprender regras avançadas de firewall pessoal sempre é útil.
  • Fico me perguntando por que as pessoas usam spyware tão explícito quando existe software livre.
    • Também existem editores excelentes que não são gratuitos, como o Sublime Text, mas que não enviam seu código/trabalho para fora (por exemplo, para o governo chinês), ou seja, são relativamente livres desse problema de telemetry.
    • Também questiono por que as pessoas usam produtos de empresas como Microsoft, Apple, Google, Amazon etc.
    • Acho que há um volume enorme de dinheiro sendo investido para difamar o software livre.
    • Software livre também tem muita telemetry. Só que, na maioria dos casos, esses dados pertencem ao GitHub.
    • Telemetry não é sinônimo de vigiar o usuário. Em muitos casos isso não se enquadra como vigilância do usuário, então entendo por que as pessoas usam esses produtos.
  • Tenho dois pensamentos:
    1. Tente usar pi-hole para bloquear esses endpoints (forçando falha de resolução DNS); pode valer o experimento para ver se o programa continua funcionando direito sem conseguir acessar os servidores de telemetry.
    2. Pelo rastreamento excessivo, por ignorar a configuração de desativar telemetry e pela reação no Discord, já dá para tirar conclusões sobre a Bytedance. Você não vai mudar essa empresa, então, se não quer ser rastreado, a resposta é evitar produtos da Bytedance desde o começo.
    • Em vez de pihole, na maioria dos SOs basta editar o arquivo hosts para bloquear domínios específicos com facilidade.
    • Fico curioso sobre quais outras empresas deveriam preocupar a gente por causa de rastreamento de dados.
    • Se a preocupação é conexão de rede, também dá para recomendar OpenSnitch ou Portmaster. No meu caso, eu nunca confio em opt-out; não vivo sem essas duas ferramentas.
  • Consegui confiar por causa dos screenshots e payloads fornecidos pelo OP. Para uma IDE ganhar confiança, o certo é oferecer telemetry desativada por padrão (opt-in) e um kill switch confiável.
  • Não entendo por que alguém usaria um fork do VSCode da Bytedance.
    • Os recursos de IA custam metade do preço em relação a outros editores (US$ 10/mês), e o plano gratuito também é bem generoso. Parece que essa diferença está sendo paga de outra forma.
    • Na prática, fora quem é funcionário interno, não parece haver motivo para usar. O principal diferencial em relação à versão da MS é a adição de recursos de IA, então isso não chega a ser surpreendente.