The open-weight frontier got loud in 2026. Reflection is paying $150M a month to train an openly-released frontier model; Kimi K3, GLM, and DeepSeek-class open coders are already callable today. So the question lands on every builder's desk: do I make one of these load-bearing in my product, or do I wait?

Skip the ideology. Here's the decision, as four gates and three staging patterns.

The four gates#

A model doesn't get to carry product weight until it clears all four. Any failure that touches your critical path is a wait.

Gate 1 — Shipped. Are the weights publicly released today? Announced, funded, and demoed is not shipped. If your launch depends on a model that doesn't exist yet, you've imported a stranger's release schedule into your roadmap and you can't even begin evaluation. Bet on what you can call; treat the unreleased frontier model as an upgrade path, not a launch plan.

Gate 2 — Callable. Can you use it the way you'll actually use it? An open model with a cheap hosted endpoint is a different proposition from one where "open" means downloading 1.4TB of weights and standing up a vLLM cluster you now have to operate. Both can be right — but price the serving path honestly before you commit.

Gate 3 — License. "Open weights" is not one thing. Some ship Apache/MIT-permissive; many are source-available with real teeth — no-compete clauses, field-of-use limits, region or entity restrictions. Read the actual terms against your actual customers, especially if you sell into regulated or cross-border markets. A license surprise after launch is the expensive kind.

Gate 4 — Fallback. If the model degrades, gets pulled, or its economics move, can you swap to a closed API in an afternoon? That requires one abstraction over every model so nothing is welded to a single vendor's quirks. No escape hatch, no bet.

The three staging patterns#

Clear all four gates and you still don't bet the whole surface at once. Stage it.

1. Route by stakes and volume. Send the repetitive, low-risk 80% to the open model; keep a closed frontier model for the hard or high-stakes tail — with automatic fallback. This is the cost-aware router pattern, and it's where most of the savings live.

2. Shadow first. Run the open model in eval-only mode against real traffic until it beats your current default on **cost per correct result** — not per token — then promote it. You get proof before you get exposure.

3. Adopt only where open wins. Reach for open weights where a closed API structurally can't follow: on-prem / data-residency, fine-tuning on your data, or simply price-floor leverage to negotiate your closed bill down. If none of those apply to a given call, the open model has to win on raw cost-per-correct-result alone — and often the closed API is fine.

The bottom line: the choice is almost never "open vs closed" as a creed. It's which slice of my workload, staged how, with what exit. Run every candidate through the four gates, adopt in stages behind a fallback, and you capture the upside of a cheaper, more sovereign model without ever betting the company on weights you don't control.