The one-line distinction
- Native: a strong model does not need to be taught methods by hand. Native hands the choice of planning, implementation, testing, and review methods entirely to the model, and locks only the outcome with a hashable requirement contract, content-addressed verification evidence, and a recoverable archive.
- Classic: a model needs explicit process constraints. Classic provides five-phase governance (open -> design -> build -> verify -> archive) through OpenSpec and Superpowers, explicitly organizing design, planning, TDD, debugging, and review.
The most fundamental difference: who owns the completion verdict
This is the core dividing line between the two workflows. Classic relies on guard scripts to check task/state fields — if the process was walked end to end and the fields are filled in, it passes. Its reliability rests on “completing all five phases by the method.” Native takes the completion verdict back from the model into the Runtime. It does not trust self-reported completion: one Agent turn, one checkpoint, or the Agent saying “complete” is never the finish line. The Runtime uses a machine-verifiable evidence system to judge whether completion is real — an acceptance matrix, typed receipts, and freshness fences. The reliability bottleneck of a strong model is precisely “whether it can be trusted to have actually finished,” not “whether it can write code,” so Native spends all its engineering effort on verification and evidence. The cost: Native’s Runtime is heavier than Classic’s. This evidence system — content hashes, failure signatures, stall detection — is the foundation that makes Native “light process yet trustworthy.”Execution overhead: tokens, turns, duration
Binding a strong model to a methodology is the biggest waste there is. Native presets no TDD/review/subagent pattern and has zero external Skill dependencies (Classic depends on OpenSpec + Superpowers), so its execution overhead is markedly lower. The alignment experiment between Native and 0.4.0 Classic (16 tasks, 3 runs per task, taking the 41 paired samples where both passed):
This shows that both workflows cover the tasks and finish at comparable quality, while Native ran lighter in this experiment. Note: the experiment supports this conclusion, but on its own it cannot prove that Native holds a causal advantage across all models, repositories, and tasks. See Comet Native vs. 0.4.0 Classic evaluation.
Phase trade-offs: why 4, not 5
Classic uses five phases, each a distinct cognitive step:
Native merges open and design into Shape — a strong model can do clarification and design decisions on its own, with no need to split them into two forced phases. Native’s four phases map to four non-mergeable cognitive boundaries: Shape makes the goal clear (contract), Build makes the thing (implementation), Verify proves it was made right (evidence), Archive fixes the result into the baseline (transaction).
One fewer phase does not mean you can skip requirements or verification. Native’s Runtime likewise checks the brief, target spec, user confirmation, implementation scope, and verification evidence — it just does not force you to walk a fixed method into place.
When to choose Native
Prefer Native if any of the following holds:- your primary model is Fable 5, GPT-5.6, or a strong model in the same tier;
- the task needs the model to choose its implementation method on its own, and you do not want it bound to a TDD/plan/review process;
- you want lower token and turn overhead;
- the team trusts the model’s execution and cares more about “whether the result is truly complete.”
When to choose Classic
Prefer Classic if any of the following holds:- your model’s capability tier is below Fable 5 / GPT-5.6 and needs finer step-by-step guidance to reduce omissions;
- the task carries strong compliance requirements and needs explicit five-phase records and a decision-point protocol;
- the team prefers explicit methodological constraints (enforced TDD, review depth, isolation mode);
- the repository is complex or unfamiliar to the team, and you want process as a backstop rather than model autonomy.
The two can coexist
A project can enable both workflows at once./comet enters the default side named by default_workflow; the two do not migrate or replace each other: