Skip to main content
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.

​
Native: Lightweight Iteration and Independent Verification

Native focuses primarily on “delivery goals and acceptance criteria”, leaving the concrete implementation path for the model to explore:
  • Focus on Core Deliverables: In the Shape phase, define goals, non-goals, and acceptance criteria upfront without drafting lengthy design documents.
  • Candidate Submissions: The model autonomously chooses testing and implementation strategies. The Builder cannot declare completion on its own; it can only submit implementation candidates.
  • Independent Read-Only Verifier: After the Runtime executes pre-flight checks, it spawns a fresh read-only Verifier Subagent to evaluate code and execution evidence against the acceptance list item by item.
  • Targeted Repair Loop: If any acceptance item fails, the Verifier returns the task to the Build phase with specific failure reasons, where the Builder performs targeted fixes until all acceptance criteria pass or the budget limit is reached.
For complex tasks, the model can load specific Skills on demand without being forced into rigid, multi-stage artifacts during early exploration.

​
Classic: Full Phase Governance and Specification Constraints

Classic suits teams requiring strict engineering governance with an auditable, phased state machine:
  • Document-Driven Phases: Sequentially advances through Open (proposal), Design (technical architecture), Build (task implementation and TDD), Verify (spec verification), and Archive (delivery and knowledge retention).
  • Strict Guard Enforcements: Every phase has rigorous artifact formats and Guard scripts; later phases cannot be entered until prerequisite artifacts pass verification.
  • Unified Engineering Practices: Rules and standards from OpenSpec and Superpowers are injected into the agent context, enforcing structured task breakdowns and reviews.
Full phase governance ensures process consistency across the team, while introducing additional phase context overhead, intermediate artifacts, and interactive confirmation rounds.
Selection Guide and Context Considerations:
  • Strong Models (such as Fable 5, GPT-5.6): Native is strongly recommended. It requires fewer interaction rounds, consumes fewer tokens, and delivers faster end-to-end completion.
  • Smaller or Private Models (such as 20B/30B tier or below GLM 5.1-equivalent): Classic is recommended. With limited context windows, Classic’s structured file checkpoints prevent mission drift during context truncation and guide the agent step-by-step.

​
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 .
Last modified on October 22, 2026