Cards and Trae — a comparison

Trae is an AI IDE whose honest claim is on starting and guiding through real-time visibility during execution. Cards is a VS Code extension whose honest claim is on guiding and checking through a durable work object built for re-entry. They overlap on guiding from opposite directions — Trae through live session visibility, Cards through persisted context — and both have nothing to claim on formal approval.

The companion piece to this page lays out person-and-agent work as a pipeline with five steps — starting new attempts, guiding them, checking them, fitting them into the larger project, and sometimes approving them through a real authority gate — plus how many attempts become accepted work, how much accepted work holds up later, and how much cleanup the workflow creates. This page walks Cards and Trae through those steps without ranking them. In the marketplace ontology, Trae is primarily an interactive agent workbench operating across the execution mode layer, with a secondary multi-agent control plane role; Cards is primarily a control artifact and memory/continuity system, with a secondary presence in the verification layer through cheaper human access to intent.

Cards is a VS Code extension for building with coding agents from plan to commit. It keeps one coding-agent job organized around description, plans, comments, attachments, sessions, transcripts, commits, changed files, and attribution; actions launch configured agents from that job context. The operator is a developer who reads diffs and makes technical decisions; the unit of work is one coding-agent job — a bug, feature, cleanup, or investigation — held as a durable object on disk that survives the session, the harness, and the editor window. Cards does not run the agent: the coding tool the developer already runs and the model behind it do that. But Cards is not a passive notebook either — its default configuration ships actions and skills that direct how a plan is drafted, stress-tested, implemented, and merged. The boundary is execution, not direction.

Trae is an AI IDE, built on a fork of VS Code, with two ways of working. In IDE mode the AI sits in a chat panel next to the code and the developer stays in control. In SOLO mode the developer describes what they want in natural language and the agent plans, writes code, runs tests, and often deploys, while the developer watches through a unified view of editor, terminal, browser preview, documentation, and Figma. Trae markets SOLO as "The Responsive Coding Agent" that "responds to your ideas, adapts to your context, and keeps up with your workflow," and frames the loop as "define the task, review the results, and AI handles the rest." SOLO splits into SOLO Builder (rapid end-to-end execution, design to running product) and SOLO Coder (methodical planning and sub-agent coordination). The operator is a developer; the unit of work is a task described in natural language. Cards is organized around keeping one job intelligible from plan to commit. Trae is organized around running the work and keeping it visible while it runs.

Starting is the question of how cheaply a serious attempt can be launched. The two products attack different costs.

Trae's effect on starting is the developer's own front-end time. Where launching a feature used to mean writing code file by file, SOLO turns it into describing what the feature should do; the agent converts that into a plan and then into running code. SOLO Builder takes a Figma design and produces a working application; SOLO Coder takes a refactoring goal and executes a plan against the codebase. Parallel agents let several tasks run at once, and the mobile app dispatches a task from a phone. The relevant ontology layer is execution mode: Trae spans interactive local, background local, and remote cloud execution. What Trae does not do is lift starting capacity without bound — concurrency is capped by plan tier and, on desktop, parallel agents compete for local resources.

Cards' effect on starting is seriousness rather than speed. The default intake interview draws vague intent into a written description and a plan before any code is written, so what reaches the agent is a serious attempt rather than a loose idea, and the ones that get through are better-formed. The ontology layer is control artifact: the description and plan become durable, inspectable objects that exist before execution. Cards does nothing for raw session spin-up. If the bottleneck is compute capacity or how fast agents start, Cards has no answer, and if the team already scopes work tightly upstream, the interview duplicates effort.

Both products assume the developer is the operator who defines the work and decides what counts as done; neither is built for hands-off delegation where the agent picks its own tasks. A developer whose constraint is "I cannot turn ideas into running code fast enough" gets more from Trae; a developer whose constraint is "half my started attempts get abandoned because the task was never clear" gets more from Cards. The two can stack: Trae to generate and run, Cards to shape and retain.

Guiding is the human work of pointing the agent at the right thing and keeping it pointed there across interruptions. This is where the structural difference between the two products is sharpest, because they lower the same cost from opposite directions.

Cards lowers the cost of guiding through re-entry. The card holds the description, plan sequence, comments, attachments, and the running map of what changed. When the developer returns after a meeting, a context switch, or a week away, they read the picture instead of rebuilding it. The per-attempt steering cost falls because the job context is already on disk, structured and human-readable, whether or not any agent session is still alive. The ontology layer is memory and continuity: Cards provides durable local state that persists independently of any agent session. A smaller secondary effect — glancing at a card on a second monitor or terminal without opening the heavy editor — is real but modest, and same-machine only.

Trae lowers the cost of guiding through visibility during execution. SOLO surfaces everything the agent is doing in one view — code, terminal output, browser preview, the plan — so the developer sees each decision as it is made and can redirect mid-execution. Trae calls this responsive review, and when the developer steps away and comes back the full session history is preserved without scrolling through transcripts. The ontology layer is attention and supervision: the unified view and parallel-agent context sharing keep the developer oriented while work runs. Where Cards keeps job context on disk as a structured object the human reads cold, Trae keeps the session alive and visible so the human never leaves context in the first place.

The two approaches fit different gaps. Cards absorbs longer and harder interruptions: close everything, return a week later, pick up from the card. Trae is strongest when the gap is short and the session is still live; preserved history is session-shaped — a replay of what happened — rather than a forward reference of what the work is and why. Trae also extends across desktop, web, and mobile, so a developer can check progress from a phone; a Cards user must be at their computer. Both share a risk: information that is available can become information that is pushed. Trae's real-time view can demand constant attention; a Cards setup that fires a notification on every comment or agent tick can invert the gain. Both depend on the team holding the line between available and pushed — Trae mitigates with Max Mode for long autonomous stretches, Cards with a posture of pull rather than push.

Checking is the question of whether produced work is actually verified before it counts. Both products face the same structural limit: the person who defined the work is the person reviewing it, and neither builds independent adjudication into the product.

Cards makes the checking context cheaper for a reviewer who was not present. The description and plans were written before and during the work, not retrofitted, and the running map shows at a glance which parts of the project the change touched. The hidden cost of review — reconstructing what the change was supposed to be and what it actually touched — is largely paid by the card. The ontology layer is verification, but only the human-access part of it: Cards lowers the cost of a real human check; it does not perform one.

Trae makes checking cheaper for the developer who defined the task. The DiffView shows every change, and code review settings offer three options: review all changes, review the latest changes, or skip review entirely. The developer watches the work unfold and approves or redirects as it runs. Trae also has one verification mechanism Cards lacks: a sandbox security system that intercepts destructive commands and requires explicit permission for operations outside defined boundaries. That is a real check on operations, not on correctness — it stops the agent deleting files it should not touch; it does not confirm the code does what it should.

Both carry the rubber-stamping risk, and it has to be named plainly. In Cards, advisory markers such as "plan approved" or "merge approved" can manufacture the appearance of review without the substance. In Trae, the agent has done all the work, the result looks plausible, and the skip-review option makes approving frictionless. In both, the checking step is only as strong as the team's willingness to wire real independent checks — tests, separate review, evaluation suites — behind the surface. The difference here is narrow: Cards makes a cold reviewer's job cheaper because the card is self-contained; Trae's DiffView most helps the developer who already watched the work, less so a second reviewer who has only the final diff and the original prompt.

Fitting in is the work of merging a finished piece into the larger project without breaking adjacent work. Here the two products are closer than anywhere else.

Both use worktree isolation to lower the integration cost per task. Cards ships this in its default setup; Trae added a worktree feature in May 2026 in which each task runs in an isolated Git environment with its own files, dependencies, and changes. In both, parallel pieces of work do not collide at the file level because they operate on separate trees. The ontology layer is isolation and boundary: code isolation through worktrees, with the limitation that anything outside the file system — release coordination, external dependency management, migration ordering, cross-team rollout — is untouched by either product.

The divergence is in coordination. Trae's worktree sits inside a broader multi-agent system where parallel agents share context across the same workspace, so one agent can see what another has changed and contradictory edits are reduced. Cards' isolation is simpler: cards are independent and the running map, not agent-to-agent context sharing, is the coordination mechanism. Both carry the same high-concurrency warning — coordination cost eventually grows faster than per-task isolation can absorb — and neither solves integration that spans many worktrees, shared configuration, or cross-cutting architectural decisions.

Approving is a recurring authority gate — a separate party who must formally sign off on each piece of work because of policy, regulation, or data rules. Neither product has anything to claim here, and both say so.

Cards states it explicitly: its workflow markers are advisory, not enforceable, and it has no compliance dashboard, approval queue, or role-based authority system; the card lives on the developer's machine with no place for a compliance officer to log in. Trae provides a sandbox allowlist and code review settings, but these are developer-level decisions about what runs without oversight, not organizational authority gates, and the editor runs on the developer's machine with no surface for an external approver. The ontology layer is authority, identity, and trust, and both products are deliberately absent from it. For a team whose binding constraint is a recurring sign-off gate, neither is the right category, and that is a choice about what each is for rather than a missing feature.

Both can raise the fraction of attempts that survive to acceptance, through different mechanisms. Cards reduces context-loss rejections: because the description and plan travel with the work, reviewers reject for substantive reasons rather than because they cannot reconstruct intent, and the upfront interview keeps vague ideas out of the started pool entirely. Trae reduces abandoned work by catching direction mismatches early — the developer reviews the plan before the agent writes code — and its shared context across parallel agents lowers rejections caused by one agent not knowing what another did. Both effects are conditional on the team's failure modes matching the mechanism: neither moves rejections driven by changing requirements, wrong implementation, or business decisions. Rather than lean on Trae's own published acceptance-rate figure, the way to judge this is to run a handful of real tasks from your own backlog through Trae and see how many plans and diffs survive review unchanged — a high rate from someone else's small team says little about whether the same holds for your codebase and your review bar.

Cards has the stronger claim on durability. The attribution tree projects cumulative changes against the current state of the project, which makes "is this work still in place a month later?" answerable at a glance rather than through forensic history work, and keeping the why attached means a later reader is less likely to undo the change for the wrong reason. Trae's preserved session history helps a future developer understand why a change was made, and its worktree isolation produces cleaner merges with fewer regressions from badly resolved conflicts, but the gap between "here is the history" and "here is whether this still holds up against the current codebase" is wider for Trae than for Cards. Neither makes work durable against shifting requirements, weak architecture, or code that does not scale; both preserve the record, neither verifies the soundness.

Each product reduces some cleanup and creates some. Cards reduces cleanup through default agents that look for failure modes in plans and implementations before they cause downstream work, and through an intact on-disk record that makes rescuing a stuck job faster. Trae reduces cleanup through worktree isolation that keeps one task's mistakes out of another's environment, the sandbox that blocks destructive commands, and shared context that lowers contradictory output between agents. Both create the same dominant cleanup risk: rubber-stamping. Half-checked work that merges because an advisory marker was clicked or a plausible-looking diff was waved through fails later and lands on someone uninvolved in the original task, and that downstream cost usually exceeds the savings from isolation and context preservation. For both, the cleanup equation only turns positive when the team maintains independent verification discipline behind the surface. Neither reduces cleanup created by the agent looping inside a single session; both act on the human side of the load.

Trae's honest claim is on starting and guiding: it makes converting intent into running code cheaper and keeps the steering relationship visible while the agent works, which matches a team whose constraint is moving from ideas to implementation and whose verification and integration capacity can absorb that output. Cards' honest claim is on guiding and checking: it makes re-entry cheap and a cold reviewer's job cheaper by pairing intent with actual work, which matches a team whose constraint is losing context between sessions or reviewing output without knowing what it was for. They are not substitutes — Trae is stronger on starting and real-time supervision during execution, Cards on long-interval re-entry, cold review, and durability of intent — so a team could plausibly use Trae to generate and steer and Cards to shape, keep readable, and support review. Both leave approving untouched and share the rubber-stamping risk; neither substitutes for independent verification discipline.

Adopting Cards costs one VS Code extension install; it does not ask you to leave Trae or migrate anything out of it. Cards runs on your existing local Git repository with no daemon, no account, and no code uploaded to a new service; card data lives locally at `~/.cards/cards-repos/<card-id>/`, alongside your repository rather than inside it, so there is nothing to import from Trae and nothing Trae produced that has to be rebuilt to use Cards. Uninstalling Cards removes the extension; your repository and git history are unaffected either way. There is no formal side-by-side trial program.