Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork (github.com)

Hi HN, I was evaluating IDEs for a personal project and decided to test Trae, ByteDance's fork of VSCode. I immediately noticed some significant performance and privacy issues that I felt were worth sharing. I've written up a full analysis with screenshots, network logs, and data payloads in the linked post.

Here are the key findings:

1. Extreme Resource Consumption: Out of the box, Trae used 6.3x more RAM (~5.7 GB) and spawned 3.7x more processes (33 total) than a standard VSCode setup with the same project open. The team has since made improvements, but it's still significantly heavier.

2. Telemetry Opt-Out Doesn't Work (It Makes It Worse): I found Trae was constantly sending data to ByteDance servers (byteoversea.com). I went into the settings and disabled all telemetry. To my surprise, this didn't stop the traffic. In fact, it increased the frequency of batch data collection. The telemetry "off" switch appears to be purely cosmetic.

3. What's Being Sent: Even with telemetry "disabled," Trae sends detailed payloads including: Hardware specs (CPU, memory, etc.) Persistent user, device, and machine IDs OS version, app language, user name Granular usage data like time-on-ide, window focus state, and active file types.

4. Community Censorship: When I tried to discuss these findings on their official Discord, my posts were deleted and my account was muted for 7 days. It seems words like "track" trigger an automated gag rule, which prevents any real discussion about privacy.

I believe developers should be aware of this behavior. The combination of resource drain, non-functional privacy settings, and censorship of technical feedback is a major red flag. The full, detailed analysis with all the evidence (process lists, Fiddler captures, JSON payloads, and screenshots of the Discord moderation) is available at the link. Happy to answer any questions.

Is it just me or does the formatting of this feel like ChatGPT (numbered lists, "Key Takeaways", and just the general phrasing of things)? It's not necessarily an issue if you checked over it properly but if you did use it then it might be good to mention that for transparency, because people can tell anyway and it might feel slightly otherwise

(or maybe you just have a similar writing style)

[flagged]

Great analysis, well done ! Since you've already done VSCode, Trae, Cursor, can you analyse Kiro (AWS fork). I'm curious about their data collection practices.

They don't want telemetry ever disabled, even for a minority of people who do toggle it off. Why?

I so much like the fact that I've come back to TUI (helix editor) recently.

I'm trying ZED too, which I believe as a commercial product comes with telemetry too.. but yeah, learning advanced rules of a personal firewall always helpful!

Now imagine we trust this company with collecting psychological profiles of future western politicians ...

VSCode is extremely unsafe and you should only use it in a managed, corporate environment where breaches aren't your problem. This goes with any fork, as well.

I remind you, again, that vi, gcc, as, ld, and make have no telemetry, launch few (if any) processes, do not need GB of RAM, and work well.

Why isn't there a decently done code editor with VSCode level features but none of the spyware garbage?

Any recommendations?

This seems like an easy win for a software project

Great write up OP!

Your analysis is thorough, and I wonder if their reduction of processes from 33 to 20...(WOW) had anything to do with moving telemetry logic elsewhere (hence increased endpoint activity).

What does Bytedance say regarding all this?

Two thoughts:

1. Try using pi-hole to block those particular endpoints via making DNS resolution fail; see if it still works if it can’t access the telemetry endpoints.

2. Their ridiculous tracking, disregard of the user preference to not send telemetry, and behavior on the Discord when you mentioned tracking says everything you need to know about the company. You cannot change them. If you don’t want to be tracked, then stay away from Bytedance.

Come on over to neovim, the water is fine. Start with lazyvim if you like.

Gotcha, blacklisting ByteDance.

Why do people use obvious spyware when free software exists?

There's also the Eclipse VScode-look-alike-reimplementation called TheiaIDE

https://theia-ide.org/

It was rough a few years ago, but nowadays it's pretty nice. TI rebuilt their Code Composer Studio using Theia so it does have some larger users. It has LSP support and the same Monaco editor backend - which is all I need.

It's VSCode-with-an-Eclipse-feel to it - which might or might not be your cup of tea, but it's an alternative.

I see a lot of confused comments blaming Microsoft, so to clarify: This analysis is about TRAE, a ByteDance IDE that was forked from VSCode: https://www.trae.ai/

It's interesting that anyone is surprised by this.

Why would anyone use a "Bytedance VSCode fork" is beyond me

[dead]

props to OP for the screenshots and payloads—that’s how you do it. If any IDE wants trust, they know the recipe - make telemetry optin by default and provide a real kill switch.

Am i the only one that finds

    System Information: Hardware specs, OS details, architecture
    Usage Patterns: Active time, session duration, feature usage
    Performance Metrics: Response times, resource consumption
    Unique Identifiers: Machine ID, user ID, device fingerprints
    Workspace Details: Project information, file paths (obfuscated)

Not to really bad that obtrusive? Like i don't really see anything there that i'd be offended in them taking?

In the OP screen share, they toggle various telemetry options on and off, but every time a setting changes, there is a pop-up that says "a setting has changed that requires a restart [of the editor] to take effect" -- and the user just hits "cancel" and doesn't restart the editor. Then, unsurprisingly, the observed behavior doesn't change. Maybe I'm dumb and/or restarting the editor doesn't actually make a difference, but at least superficially, I'm not sure you can draw useful conclusions from this kind of testing...

edit: to be clear I see that they X-out the topmost window of the editor and then re-launch from the bottom bar, but it's not obvious that this is actually restarting the stuff that matters

I wonder how many of these telemetry events can sneakily exfiltrate arbitrary data like source code. For example, they could encode arbitrary data into span IDs, timestamps (millisecond and nanosecond components), or other per-event UIDs. It may be slow...but surely it's possible.