My last post about how my AI workflow is built under the hood generated countless comments on Reddit and other social media platforms about the configuration of each model for each SSD phase.
Honestly, that wasn’t the point of that post, since ultimately, it’s about configuration and will depend on what you want to do. However, it gave me a good starting point to delve a little deeper into each phase: what it is, what it aims to achieve, and which models might be compatible (as of June 1, 2026).
Quick recap. The Problem With “One Model Does Everything”
Most AI coding setups look like this: one model, one context window, one giant session that slowly degrades as the complexity grows. You ask it to explore a codebase, propose an architecture, write a spec, design the solution, implement it, and then verify the output.
All in the same thread, with the same model, accumulating noise with every turn.
The result is predictable. By the time you’re implementing, the model has forgotten half of what it explored. By the time you’re verifying, it’s defending its own code instead of critiquing it.
The fix isn’t a better model. It’s a better workflow.
Enter SDD: Spec-Driven Development
Gentle-AI is an open-source ecosystem configurator (in which I use to contribute with issues and PRs), built around a workflow called Spec-Driven Development (SDD). The idea is simple: break a feature into discrete phases, give each phase its own agent with its own context, and persist artifacts between them via Engram (a SQLite-backed memory layer).
Phases:
- Init: Bootstraps the skill registry, maps the repo, and detects conventions
- Explore: Reads the codebase deeply (dependencies, patterns, etc)
- Propose: Generates architectural approaches with trade-off analysis.
- Spec: Produces the formal tech spec: contracts, interfaces, edge cases.
- Design: Translates the spec into a concrete architecture. Classes, patterns, diagrams, and all the necessary stuff.
- Tasks: Decomposes the design into ordered, atomic implementation tasks
- Apply: Executes the tasks. Writes and edits real code in the repository
- Verify: Adversarial review. Run tests, validates diffs, checks against spec
- Archive: Persists artifacts and decisions to the persistent memory (called Engram) for future sessions.
Each phase is a dedicated sub-agent with its own model, tools, and permissions. The orchestrator (the orchestrator agent) coordinates handoffs and approval gates. You review and approve at key decision points. Everything else is automated.
The key insight: different phases need different capabilities. A phase that maps files doesn’t need the same model as a phase that designs an architecture. Treating them the same is expensive and often counterproductive.
The Model Landscape in Mid-2026
I want to make a disclaimer here. A lot of LLMs, companies, and versions are appearing every single day. The analysis below takes into account costs, so you won’t see Opus 4.8 or GPT 5.5 here
Before getting into the configuration, it helps to understand why the open-weight ecosystem is now competitive enough to build on.
Four models matter for this stack:
GLM-5.1 (Z.AI): A 754B MoE model, MIT-licensed, with the highest SWE-Bench Pro score of any model at launch (58.4), beating GPT-5.4 and Claude Opus 4.6. Its distinguishing characteristic is sustained reasoning over long horizons. It doesn’t plateau early on complex agentic tasks the way most models do. Strong on NL2Repo and Terminal-Bench 2.0. The only one of the four with a publicly confirmed Code Arena Elo (1530).
Kimi K2.6 (Moonshot AI): A 1T MoE model with a native Agent Swarm primitive: 300 sub-agents, 4,000 coordinated steps. Highest open-weight score on the Artificial Analysis Intelligence Index (54). Its strength is parallel, large-scale code comprehension, reading many files simultaneously rather than reasoning sequentially.
DeepSeek V4 Pro (DeepSeek): 1.6T total / 49B active parameters, 1M context, MIT license. Leads open-weight models on GDPval-AA (agentic real-world work benchmark: 1554), ahead of GLM-5.1 (1535) and Kimi K2.6 (1484). SWE-Bench Verified at 80.6%. The go-to model when you need the highest quality output on real-world tasks.
DeepSeek V4 Flash (DeepSeek): 284B total / 13B active. Within 1.6 percentage points of Pro on coding benchmarks, at roughly 12x lower cost. 128 tokens/second throughput. The workhorse for high-frequency, low-reasoning phases.
Qwen3-Coder 480B (Alibaba): 480B MoE, 35B active, optimized specifically for agentic coding workflows. What separates it: 94% first-attempt accuracy on tool calls, vs. 87% for DeepSeek V4 Pro. That gap is significant for verification tasks where a failed tool call means a missed bug.
But, most importantly here… I’ve tested dozens of models, the prime-tier, the low-tier, expensive, cheap, and all you are seeing in this post is based in my analysis. I recommend making yours so you are happy with your specific case.
The Cost Equation: OpenCode Go Changes Everything
The entire stack runs at a predictable cost because of OpenCode Go, a 5) that gives you access to GLM-5.1, Kimi K2.6, DeepSeek V4 Pro, DeepSeek V4 Flash, and more via a single API key. No per-token billing for these models under the subscription (like the good old days when Copilot gave you tons of premium requests).
The thing here is that OpenCode uses to give you low-tier models (that actually work pretty well if you use a good harness).
The only model outside Go in this stack is Qwen3-Coder 480B, available via OpenRouter at 1.80/M output, used only for sdd-verify, so the volume is low.
Total estimated monthly cost: $10–15, regardless of how many features you run through the harness.
Compare that to running everything on Claude Opus 4.7 or GPT-5.5, where a single large feature could cost $5–10 in tokens alone.
OpenCode Go frequently updates its models or adds new ones. New models often come with a 50% discount, which translates to twice the limits for more intensive sessions:)
My final recommendation here is: Get your OpenCode Go subscription (10 per month), and add some money to OpenRouter (since it also has all the most powerful models, and makes sense, for example, for the orchestrator agent, or any model not included in Go that you might want).
The Final Configuration
This is the setup I arrived at after analyzing each phase against the benchmarks that actually matter for its workload, plus a bunch of tests on each one:
- Orchestrator: OpenRouter / Claude Sonnet 4.6 [high]
- Init: OpenCode Go / DeepSeek V4 Flash
- Explore: OpenCode Go / Kimi K2.6
- Propose: OpenCode Go/ GLM-5.1
- Spec: OpenCode Go/ Deepseek V4 Pro [high]
- Design: OpenCode Go/ Deepseek V4 Pro [high]
- Tasks: OpenCode Go/ Deepseek V4 Flash [high]
- Apply: OpenCode Go/ Deepseek V4 Pro [high]
- Verify: OpenRouter / Qwen3-Coder 480B A35B
- Archive: OpenCode Go/ Deepseek V4 Flash [high]
The Reasoning Behind Each Assignment
sdd-init → DeepSeek V4 Flash
Init is pure mapping: run the skill registry, detect project conventions, build context. No reasoning required, the model needs to read fast and organize output correctly. Flash does this at 128 tokens/second with a 1M context window. GLM-5.1 here is overkill.
sdd-explore → Kimi K2.6
Explore reads the codebase (potentially hundreds of files, multiple dependency trees, test suites, and config layers). Kimi K2.6’s Agent Swarm architecture is uniquely suited here: it can parallelize file reads across sub-agents rather than processing sequentially. Its 262K native context and high first-pass code comprehension make it the strongest model for this workload.
sdd-propose → GLM-5.1
Propose is the most reflective phase in the pipeline. The model isn’t executing anything; it’s evaluating approaches, weighing trade-offs, and building an argument for a chosen direction. GLM-5.1’s deep sequential reasoning and confirmed human-preference signal (Code Arena Elo 1530) make it better at this than Kimi K2.6, which shines at execution rather than deliberation.
sdd-spec → DeepSeek V4 Pro [high]
The spec is the most critical artifact in the entire SDD flow. Everything downstream (design, tasks, implementation) derives from it. An inconsistency or ambiguity here propagates to every subsequent phase. DeepSeek V4 Pro at high reasoning effort is the strongest open-weight choice for producing a formally correct, complete specification. This is the one phase where you never trade down.
sdd-design → DeepSeek V4 Pro [medium]
Design is more operational than spec; it’s translating decisions into concrete structures, class diagrams, and component boundaries. The GDPval-AA benchmark (real-world agentic work) is the most relevant signal here, and V4 Pro leads at 1554 vs. Kimi K2.6 at 1484. Medium reasoning effort is sufficient since the spec already contains the hard decisions.
sdd-tasks → DeepSeek V4 Flash [high]
Task decomposition is mechanical: take the design and produce a numbered, dependency-ordered list of atomic implementation steps. Format consistency matters more than raw intelligence here. Flash at high effort handles this at maximum throughput with negligible cost. The pro would be wasted.
sdd-apply → DeepSeek V4 Pro [high]
Apply is where tokens accumulate fastest and where quality failures are most expensive to fix. Terminal-Bench 2.0 is the benchmark that captures real autonomous coding sessions, and Pro leads Flash by ~11 points on that benchmark. High reasoning effort here directly reduces the number of revision cycles. Don’t optimize cost on the implementation phase.
sdd-verify → Qwen3-Coder 480B (OpenRouter)
Verify is an adversarial review: the model runs tests, inspects diffs, checks the implementation against the spec, and must correctly invoke shell and file-read tools on the first attempt. Qwen3-Coder 480B achieves 94% first-attempt tool call accuracy vs. 87% for DeepSeek V4 Pro. In a verification context, a failed tool call is a missed defect; that 7-point gap matters. This is the only phase outside OpenCode Go, and the low volume keeps costs minimal.
sdd-archive → DeepSeek V4 Flash [high]
Archive writes structured artifacts to Engram. It’s the most mechanical phase in the pipeline. Flash, maximum speed, minimum cost.
Why the Orchestrator Stays on Claude
The orchestrator (Claude Sonnet 4.6) doesn’t write code. It coordinates: reads phase outputs, decides whether to approve or loop back, and manages the approval gates before sdd-apply and sdd-archive, and maintains the global coherence of the feature across phases.
For that role (judgment, coordination, and understanding of your intent) Claude Sonnet 4.6 at medium effort remains the strongest option. The orchestrator’s token usage is also relatively low, so the cost impact is minimal.
This might change as open-weight models continue closing the gap on general reasoning. But for now, the orchestrator is the one place where a proprietary model earns its place.
All the Gentle AI harness + Engram memory looks for a controlled session context on the orchestrator. I worked for hours, AND THE CONTEXT WAS BELOW 15%. It sounds incredible, but it is true.
What This Looks Like in Practice
A typical flow for a new feature, like a transport layer with multiple sender clients:
- I describe the feature in plain language to the orchestrator
sdd-initboots in ~10 seconds, builds the registrysdd-exploremaps the relevant codebase like services, interfaces, and existing patternssdd-proposecomes back with 2–3 approaches; I pick one or ask for a revisionsdd-specproduces the formal spec; I review and approvesdd-designgenerates the architecture; I approvesdd-tasksproduces the numbered task listsdd-applyexecutes task by task, persisting progress to Engramsdd-verifyruns the adversarial reviewsdd-archivecloses the loop
Total token cost: covered by the $10 Go subscription for 8 of the 9 phases. The verify phase costs cents on OpenRouter as well as the orchestrator.
The Bigger Picture
The open-weight ecosystem in mid-2026 has crossed a threshold. GLM-5.1 beats GPT-5.4 on SWE-Bench Pro. DeepSeek V4 Pro competes with Claude Opus 4.6 on coding at $0.87/M output tokens. Kimi K2.6 ties GPT-5.5 on the same benchmark.
The argument that you need a proprietary frontier model for serious engineering work is no longer empirically supported; at least not for the workloads that make up most of a software engineer’s day.
The remaining advantage of proprietary models is on the orchestration and reasoning layer: judgment, ambiguity handling, and the kind of soft architectural thinking that’s hard to benchmark. That’s why Claude stays as the orchestrator. But for the execution pipeline? The open-weight stack is there.
The SDD harness I’ve described costs $10–15/month, covers production-grade.NET 8 microservice work, and produces better output than a single-model session because the phases don’t pollute each other’s context.
The setup takes 20 minutes. The savings start immediately.