Trae is ByteDance's entry into the AI-IDE race, and its pitch is blunt: a Cursor-style editor with frontier models attached, for $0. That gets attention in a category where Cursor's Pro tier runs $20/month and GitHub Copilot starts at $10. We spent a working week running Trae against a real TypeScript codebase — not a to-do app demo — to see whether "free" comes with the usual asterisks.
The short version: the editor itself is competent because it isn't really new, and the AI features are good enough to do daily work. The questions worth slowing down for are about who routes your code and where, not about whether the autocomplete works.
What Trae actually is
Trae is a fork of VS Code. If you have used VS Code, the layout, keybindings, command palette, and extension model are all where you expect them. You can import your existing VS Code settings and most extensions install from the Open VSX registry without complaint. That familiarity is the whole point — ByteDance didn't build a new editor, it bolted an AI layer onto the one most developers already know, the same architectural decision Cursor and Windsurf made.
The AI surface has three parts. There's inline completion that behaves like Copilot. There's a side-panel chat that can read your open files and selected code. And there's Builder mode, Trae's agentic feature: you describe a change in plain English, it plans a set of edits across multiple files, runs terminal commands, and shows you a diff to accept or reject. Builder is the part that competes directly with Cursor's Composer/Agent and Windsurf's Cascade.
Model access is the headline. Trae routes to Claude and GPT-class models rather than a weaker in-house model, and during our testing that access carried no metered per-request charge on the free plan. That is a genuinely different offer from Copilot's older default models or Cursor's request quotas.
Trae ships in two distinct builds: an international version (trae.ai) and a China-market version (trae.com.cn). They are not the same app — they differ in available models, default endpoints, and the backend that requests are sent to. Download the build that matches your jurisdiction and check which one your team is actually running before you standardize on it.
Where it holds up, and where it doesn't
For scoped, well-described tasks, Builder mode is legitimately useful. We pointed it at a request like "add a Zod schema for this API response and wire it into the existing fetch wrapper," and it located the right files, wrote a schema that matched the shape, and updated the call site. The diff was reviewable and mostly correct. This is the same loop Cursor users will recognize, and Trae executes it without obvious dropped frames.
Where it slips is multi-step work that crosses several unrelated modules, and recovery after a failed edit. When Builder's first plan was wrong, it sometimes doubled down — re-applying a variation of the same broken change rather than backing out. Cursor's agent, in the same kind of dead end, more often re-reads the file state and corrects course. Trae also leans on you to keep context tight: the more files you leave open and unrelated, the noisier its suggestions got.
Inline completion was the least differentiated part. It's fine. It is not noticeably better or worse than Copilot for routine line completion, and it occasionally over-suggested whole blocks you didn't want, which is a paper cut you'll learn to dismiss with a keystroke.
The question that should come first
Because Trae is free and routes to expensive models, the real cost is paid in data flow. Your prompts, the code context Trae attaches to a request, and the files Builder reads are sent to a backend to be processed. On the international build that backend is ByteDance's infrastructure. That isn't a scandal — every cloud AI IDE, Cursor and Copilot included, sends code context to a server. But ByteDance is under specific regulatory scrutiny in the US and several other markets, and several large organizations restrict or ban ByteDance-operated software on work devices.
That makes the decision contextual rather than universal. For a personal project, a side project, or open-source code that already lives in public, the data path is a non-issue and the price is unbeatable. For a private commercial repository — especially one under an employer's security policy — you should treat "can we send this code to ByteDance's servers?" as a question for whoever owns that policy, answered before install, not after.
Do not point Trae's Builder mode at a repository containing secrets, credentials, or proprietary code without confirming your organization permits ByteDance-operated tooling. Builder reads files to plan edits, which means that content leaves your machine. Read the privacy terms for the specific build you downloaded — the international and China versions document different data handling.
If that check fails, or you simply don't want a third question mark over where your code goes, a paid tool with clearer data-residency commitments is the safer default for commercial work.
Who Trae is for
Trae makes the most sense if you want frontier-model assistance at zero cost and your code isn't sensitive: students, hobby builds, learning a new framework, throwaway prototypes, open-source contributions. In those cases the value is real and the trade-off is mild.
It makes less sense as the default editor for a team shipping a private commercial product, where the data-routing question and the weaker agent recovery both cut against it. There, the $20/month you'd spend on a competitor buys clearer terms and a more reliable agent loop — and that's cheap relative to the time a confused agent burns.
The honest summary is that Trae is a well-built VS Code fork with a generous free model offer and one large governance asterisk. Try it on something you'd be comfortable posting publicly. Decide on the data path before you point it at anything you wouldn't.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)