Not every development phase needs a frontier model. Spending top-tier tokens on generating a changelog entry, or using a cheap model to make security-critical architectural decisions, are both wasteful in opposite directions. dbv-specs-ops encodes a Model Routing Guidelines table directly inDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/davidbuenov/dbv-specs-ops/llms.txt
Use this file to discover all available pages before exploring further.
project.config.md so that both you and your AI assistant have a shared, auditable source of truth for which model class to reach for at each step of the SDD lifecycle. The result is lower token costs on routine phases, and the full reasoning power of frontier models where specification quality and architectural correctness actually matter.
Why model routing matters
AI development costs fall into two economic buckets that mirror traditional software CapEx vs. OpEx thinking:- CapEx-equivalent (specification and planning phases): Decisions made here propagate forward into every line of code. A vague specification or a flawed architecture plan is expensive to undo. Spending on frontier model quality at
/specand/planis an investment — it prevents rework downstream. - OpEx-equivalent (build, test, and ship phases): These phases execute a plan that has already been validated. The work is well-defined, the risks are understood, and a fast, cost-efficient model is entirely capable of handling it correctly.
The Model Routing Guidelines live in the
## Model Routing Guidelines section of your project.config.md file. They are read by the AI at session start alongside the rest of the project identity block. Framework version 2.1.0 introduced this table.Routing table
The table below is reproduced directly from theproject.config.md template (v2.1.0). The Recommended Model Class column describes a capability tier, not a specific vendor — use the Example Models as a starting point and substitute equivalents from your preferred provider.
| Development Phase | Required Reasoning Complexity | Recommended Model Class | Example Models |
|---|---|---|---|
/spec — Specifications | Very High | Advanced Reasoning / Frontier Models | Gemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o |
/plan — Planning / Architecture | Very High | Advanced Reasoning / Frontier Models | Gemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o |
/build — Code Implementation | Medium | Fast, high-accuracy coding models | Gemini 1.5 Flash, Claude 3.5 Sonnet, GPT-4o |
/test — Conventional Tests / Evals | Medium-Low | Fast & cheap models | Gemini 1.5 Flash, Claude 3 Haiku, GPT-4o-mini |
/code-simplify — Security & Refactor | High | Security-conscious reasoning models | Gemini 1.5 Pro, Claude 3.5 Sonnet |
/ship — Documentation, Changelog | Low | Fast, text-optimized models | Gemini 1.5 Flash, Claude 3 Haiku, GPT-4o-mini |
Phase-by-phase rationale
/spec and /plan — Very High reasoning (Frontier)
Both phases involve open-ended synthesis: the AI must reconcile ambiguous user requirements into a coherent specification (/spec), or validate that specification for edge cases and decompose it into an executable plan (/plan). The mandatory Adversarial Architect Review in /plan — where the AI must articulate risks using concrete terms from SPECIFICATIONS.md — requires the kind of nuanced, multi-step reasoning that only frontier models reliably deliver. Errors here are systemic: a missed security requirement in /spec or an overlooked race condition in /plan will surface as expensive bugs in /build or /test.
/build — Medium reasoning (Fast coding models)
By the time /build begins, the specification and plan have been approved. The AI is executing a known task against a defined structure. A fast, high-accuracy coding model handles this well, and the incremental approach (one slice at a time) means each individual code generation call is scoped and verifiable. Note that some coding assistants (e.g., Claude 3.5 Sonnet) sit at the intersection of “fast coding” and “frontier” — they are a reasonable default for /build when you want to avoid a model switch.
/test — Medium-Low reasoning (Fast & cheap)
Test generation for deterministic unit and integration tests is a well-structured task: given a function signature and a specification, produce assertions. The reasoning load is low. For non-deterministic Evals (LLM Judges, hallucination scans), the evaluation rubric is defined in SPECIFICATIONS.md and the model simply applies it — again, a fast model is appropriate.
/code-simplify — High reasoning (Security-conscious)
This phase is the Security Review Gate. The AI must identify credential leaks, validate that all imported packages are real (guarding against dependency confusion and slopsquatting), and audit input sanitization on critical endpoints. These tasks require careful, adversarial reasoning over code that was just written — stepping back down to a frontier or security-conscious model class is warranted here even though the phase produces no new features.
/ship — Low reasoning (Fast, text-optimized)
Updating README.md, writing walkthrough.md, formatting CHANGELOG.md, and proposing a semantic-version commit message are all well-structured text tasks. A fast, text-optimized model handles them efficiently with no quality tradeoff.
When to override the default routing
The table provides sensible defaults, but there are legitimate reasons to reach for a frontier model outside of/spec and /plan:
- Security-critical
/buildwork — if the feature you are implementing touches authentication, payments, or sensitive data storage, treat the/buildphase as if it were/planreasoning-wise. Theimplementation_plan.mdYAML frontmatter already calls for ariskskey in these situations; match your model choice to that risk level. - Novel integrations during
/build— if the task involves integrating an unfamiliar external API, an MCP server, or a new language/framework, the lack of strong priors in a fast model may cost you more in correction cycles than the savings on tokens. - Ambiguous refactors in
/code-simplify— if the codebase is large and the relationships between modules are complex, the Security Review benefits from the same frontier reasoning used in/plan.
Configuring model routing in project.config.md
The routing table ships pre-populated in the template. You do not need to edit it to start using the framework — the AI reads it as advisory guidance for which model class to recommend when switching phases. If you want to customize it for your team’s model portfolio (for example, substituting an internal LLM for a specific phase), edit the ## Model Routing Guidelines section in project.config.md directly:
The CapEx vs. OpEx summary
| Economic analogy | Phases | Rationale |
|---|---|---|
| CapEx — invest now, pay dividends later | /spec, /plan, /code-simplify | Decisions made here define the entire project shape. Frontier quality prevents systemic rework. |
| OpEx — recurring execution cost | /build, /test, /ship | Well-defined, repeatable work. Fast, cheap models reduce per-cycle cost without quality loss. |