Use Native with Fable 5, GPT-5.6, or a similar model when you do not require a fixed engineering process. Choose Classic when Comet must define the design, planning, TDD, and review steps.
Native manages the goal and completion standard while the model chooses implementation methods. Classic also manages the implementation process and stage artifacts. They support different development approaches.
Complete the selection in 30 seconds
If the model’s capabilities are sufficient and the team does not have a fixed development process that must be followed, Native should be given priority. If you place more emphasis on process consistency or require the model to strictly adhere to specified methods, choose Classic.
When to choose Native
Native is suitable for situations where you focus on “what you ultimately want to achieve” and are willing to let the model decide “exactly how to do it”.
Choosing Native usually means:
- You confirm the goal, scope, and decisions that affect the outcome.
- The model independently selects the design approach, testing strategy and related engineering skills.
- The Runtime manages the workspace, status, interrupt recovery, and phase advancement.
- Builder only submits candidate implementations and cannot declare completion on its own.
- After the Runtime runs the necessary checks, it will start a brand-new read-only Verifier Subagent to verify the acceptance criteria item by item.
- If the acceptance fails, it returns to Build with failure reasons, gets repaired, and is re-verified.
The main process of Native is:
It does not force the model to use a fixed design template, implementation plan or TDD process. When these methods are needed, the model can select the corresponding Skill according to the task.
When to choose Classic
Choose Classic when every development must follow a clear, reviewable engineering process.
Choosing “Classic” usually means:
- The requirements first enter the Open stage and establish a formal change.
- The Design stage organizes specifications, designs, and task boundaries.
- The Build phase is carried out as planned, and TDD, debugging, and review methods are used according to the configuration.
- The Verify stage checks whether the implementation is consistent with the specifications.
- Each stage has a clear product and Guard, which cannot be skipped at will.
The main process of Classic is:
These constraints make the process more unified and also bring about more stage contexts, process products and interaction rounds.
Classic has extra overhead: it incrementally loads a large set of OpenSpec and Superpowers Skills into system context. As engineering rules increase, task runtime is usually much longer than Native mode. Use Classic when model capability is lower or your team requires a fixed process. For privately deployed models around 20B to 30B, or models below GLM 5.1-equivalent capability, Classic’s staged records help preserve goals and progress when context windows are limited.
The actual differences between the two workflows
Suppose you want to add the ability to upload avatars to the user profile page.
When using Native, Comet will first confirm key decisions such as file restrictions and failure behaviors, and then let the model complete the implementation and testing independently. The Runtime then runs the necessary checks and hands them over to the new read-only Verifier Subagent for judgment against the complete acceptance list. If any acceptance item does not pass, it returns to Build; when all pass, it archives.
When using Classic, the same requirement will go through Open, Design, Build, Verify and Archive in sequence. The design documents, task plans, implementation methods and review processes all have clear boundaries. The model can only proceed after completing the corresponding products in each stage.
The same project can be used simultaneously
If different tasks require different methods, two sets of workflows can be enabled simultaneously
The default_workflow in .comet/config.yaml determines which workflow /comet enters by default. This setting only affects new entries and does not convert existing changes from Native to Classic, nor does it convert Classic Changes to Native. Both sides respectively manage their own changes, states, guards and products.
Still not sure what to do
- If the model’s capabilities are sufficient and you want to obtain independently accepted results more quickly: Choose Native.
- ** The team requires a fixed design, planning, TDD or review process ** : Select Classic.
- Both situations will occur in the project: enable simultaneously and set the more commonly used one as the default.
The model name is only a reference for capabilities. Comet does not read the model name and automatically switch workflows. The final choice is determined by the project configuration.
Continue reading: Native Quick Start , Native Workflow and Classic Workflow . 
