Running Open Models at Frontier Level

Something changed in the second half of 2026, and the pricing pages show it more clearly than the launch posts do.

GLM-5.3 reports 88.2 on Terminal-Bench 2.1. Qwen3.8-Max reports 86.6. Claude Fable 5 reports 84.6. Those three numbers sit inside four points of each other, and one of them costs $1.40 per million input tokens while another costs $10.

That does not mean open models have won, and this piece is not an argument that they have. It means the remaining difference between a good open model and the best proprietary one is now small enough that the system you build around the model matters more than which model you picked. That is a solvable engineering problem, and this is how we solve it.

Where the field actually stands

Four of those five ship open weights or are close to it. DeepSeek-V4-Pro is MIT with 1.6 trillion parameters and a 1M context. GLM-5.3-Flash is MIT, natively multimodal, 320B with 18B active, at fifteen cents per million input.

Two honest qualifications before going further.

Weights availability is a spectrum, not a checkbox. GLM-5.3 was announced as open-weights with a release promised roughly two weeks later; treat any model as open only once you can download it. Qwen3.8-Max has not published a licence at all and is API-only at launch, so it belongs in this table as a capable model rather than an open one.

Every score in that table is vendor-reported, from different harnesses. Nobody is refereeing. Four points of separation between vendor-run evaluations is noise, which is precisely why the argument here rests on price and architecture rather than on a leaderboard position.

The gap that remains

Open models still trail on the hardest reasoning. On Humanity's Last Exam with tools, Claude Fable 5.1 reports 65.0% against GLM-5.3's 62.5%. That margin is narrow but it is consistent, and it shows up on the tasks with the longest chains of inference.

The pattern we see in practice matches: for the routine majority of engineering work, a good open model is indistinguishable from an expensive one. For the genuinely hard case — the migration nobody has attempted, the bug that spans four services — the frontier proprietary models still finish more often.

The mistake is treating that as a reason to run everything on the expensive model. Most work is routine, and paying frontier prices for routine work funds nothing.

The system that closes the gap

Four parts, in the order they pay off.

1. Route by difficulty

A single model for all traffic is the most expensive possible choice, because it prices the easy majority at the rate of the hard minority.

Send routine work to a cheap fast model. GLM-5.3-Flash at $0.15 and $0.50 handles a large share of everyday engineering: the dependency bump, the test that needs writing, the endpoint that follows the pattern of the four beside it. Escalate the rest.

The router does not need to be clever to start. File count, diff size, whether the task touches a subsystem your test suite covers well, and whether a cheap attempt already failed will take you a long way. Refine it once you have data.

2. Verify before you trust

This is the part that turns a cheap model into a reliable one, and it is the part most often skipped.

Put a gate between the model and anything irreversible. Run the tests. Run the linter and the type checker. For work without good test coverage, a judge model scoring the diff against the ticket catches a useful fraction of nonsense.

The economics here are excellent and worth stating plainly. A verification pass on GLM-5.3-Flash costs cents. Failing verification and retrying costs cents. Both together stay far below one attempt at frontier prices, which is why the cheap-model-plus-verifier arrangement often ends up both cheaper *and* more reliable than a single expensive call with nothing checking it. The expensive model can also be wrong; the difference is whether anything notices.

3. Give the model the context it needs

A frontier model with a bad harness loses to a mid-tier model with a good one. The scaffolding is the multiplier: retrieval that finds the right files, tool definitions the model can actually use, conventions and skills loaded when they are relevant, and a context window managed so the useful material survives to the end of a long run.

This is where the harness choice pays. Whether you build on Strands, Mastra, Flue or a graph, all of them keep the model choice open, which is exactly what makes the routing above possible.

4. Measure on your own work

Published benchmarks build a shortlist. Your success rate on your codebase decides the winner.

Take twenty tickets your team has already closed, with the diffs that resolved them. Run each candidate through your real harness. Score with your real test suite. It is an afternoon, and it produces the number that predicts your bill, because cost per solved task divides by exactly that rate.

It also protects you from the benchmark churn. Terminal-Bench shipped 2.1, 3.0 and 4.0 inside a year, and the versions are not interchangeable. A local eval is stable across all of that because it never changes unless you change it.

What this buys beyond price

Cost is the obvious win: 76× on cost per solved task between the cheapest capable open model and a frontier proprietary one, and still 34× once you give the expensive model the full benefit of prompt caching.

Two others matter more to some teams than the money.

Where inference happens becomes your decision. Open weights can run in the region you choose. For regulated work, that turns a procurement blocker into a deployment detail. It is why the model layer of the stack we build treats frontier endpoints, open weights in your region, and fully on-premises as the same slot with different settings. See also our notes on data residency and open models on Western infrastructure.

The model stops being a dependency you cannot replace. A downloadable checkpoint under MIT does not get deprecated on someone else's schedule, reprice overnight, or change behaviour under you between releases. For a workflow you intend to run for years, that stability is worth real money on its own.

Being straight about the limits

Open models are not the right answer for everything, and a few things are worth saying plainly.

Running weights yourself is real work: GPUs, serving, batching, upgrades. Most teams should start with a hosted endpoint for an open model and treat self-hosting as a later option that stays available rather than a first move.

The hardest reasoning still favours the frontier proprietary models, which is why the routing diagram keeps an escalation path rather than pretending one model covers everything.

And the field moves fast enough that any table here has a shelf life measured in weeks. The parts that age well are the four in the system above, because they are about how you use a model rather than which one is ahead this month.

The short version

Open models reached the point where the difference in output quality is small and the difference in price is enormous. Route by difficulty, verify before you trust, invest in the harness, and measure on your own tickets. Do those four and open weights will do frontier-level work, at a fraction of frontier cost, in a region you choose.

That routing arrangement is one layer of a larger picture: see the stack for the other four, or talk to us if you want help standing it up. It is most of what we do.