Z.ai shipped GLM-5.2 in mid-June: MIT-licensed weights, a win over GPT-5.5 on SWE-bench Pro (62.1 to 58.6), and the top open-weights score on the Artificial Analysis index. It arrived less than two weeks after Nvidia's Nemotron 3 Ultra was rated the strongest US open model. By fall, some other model will hold the crown. If your AI architecture is a bet on which model is best this month, you have signed up to re-architect monthly.
I run local models every day on a Mac Studio with 64GB of unified memory (Qwen-family workhorses on MLX and llama.cpp), and I send plenty of work to frontier APIs too. People sometimes read that as local-model advocacy, but what I advocate is the router. The model at the end of any given route changes with the leaderboard; the routing pattern survives those changes.
Classify the work, not the model
You can sort almost any AI workload with four questions: what breaks if the output is wrong (risk), what data rides in the prompt (privacy), how fast the answer has to come back (latency), and how many times a day it runs (volume).
Score a lane on those four axes and in most cases the split is clear. The boring, high-volume lanes go local: summarizing transcripts, classifying and tagging inbound documents, extracting structured fields, first-pass triage, the enrichment jobs that run all night. That work is high-volume, low-stakes, and soaked in raw internal data: the profile where a 30B-class model on hardware you own is enough. Escalate the hard lanes to frontier models: multi-document synthesis someone will act on, difficult reasoning, gnarly debugging, anything customer-visible where the quality of the output is the product.
Be honest about the quality gap when you draw that line. Vicki Boykis's six-month verdict from real-world local-model use on a 64GB Mac, relayed through a community digest, put local agentic coding at roughly 75% of frontier accuracy and speed. Seventy-five percent falls short for the work you escalate; for the lanes where the model's job is to compress, sort, and label, it is more than enough.
I open-sourced my version of this pattern as Cerebellum, a local AI router that sends lower-risk work to local models under explicit policy controls and writes a reviewable decision trail as it goes. I built it so the models behind its routes can change; the policy file and the log format persist. The case for the pattern rests on that asymmetry.
Local seldom wins on cost
The most useful correction to this year's local-model enthusiasm came from a skeptic. One developer on X ran the raw numbers (a Mac Studio drawing 150 watts under load, against API tokens at $0.002 per thousand with zero infrastructure overhead) and argued that local makes economic sense in almost no scenario beyond the latency-and-privacy edge. On pure cost per token he is more right than wrong, and the trend is not kind to local: frontier vendors keep cutting per-token prices, while a capable local rig still starts at Mac Studio money. If cheap tokens are your argument for owning hardware, the price trend is against you.
The durable case for local is four things the API price sheet does not capture. Privacy: PII, contracts, unreleased code, and sensitive records never leave the building, so a whole class of data-processing and residency questions never comes up. Sovereignty: this June, a Commerce Department export-control directive forced Anthropic to pull its brand-new flagship Fable 5 offline globally for roughly 18 days, three days after launch. A hosted model is a dependency someone else can switch off. Latency: a local model has no network round-trip and no rate limiter in the loop, which matters at the edge and inside interactive tools. Volume: a model you own is unmetered, so the 24/7 background lanes that would bleed an API budget run flat-out for the price of electricity.
None of those four move with the leaderboard, which is why they belong in a routing policy and the benchmark scores do not.
A routing policy is a governance artifact
I have taken 40 GenAI deployments through enterprise security review, and the first question is never about benchmarks. It is some version of: what data went where, and who decided. A routing policy answers that in writing. The policy says which classes of work may leave the building and which may not. The decision log shows every request, the route it took, and the rule that sent it there. When the security team asks, you hand over the log instead of convening a meeting to reconstruct behavior from memory.
Most rollouts never produce this artifact. Publicis Sapient's 2026 enterprise AI survey of 1,550 decision-makers found 73% of organizations using AI regularly or across most of their processes, but only 10% saying AI is core to how the business operates, and 42% saying the technology is capable but the organization is not set up to capture the value. That gap is operating-model work, and a routing policy is operating-model work at its smallest useful size: a written, reviewable answer to where work goes and why. In every rollout I run, it is the artifact that moves a system from interesting demo to approved deployment.
So pick your split by workflow rather than by fashion. Score each lane on risk, privacy, latency, and volume. Run the boring volume local, escalate the judgment calls, and write the policy down where an auditor can read it. Then put a quarterly review on the calendar, because the line keeps moving: open weights reached frontier coding scores this June, with GLM-5.2 beating GPT-5.5 on SWE-bench Pro under an MIT license. The models will keep churning, and the router is the piece you keep.