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. It isn't. What I actually advocate is the router. The model at the end of any given route changes with the leaderboard. The routing pattern survives it.
Classify the work, not the model
Four questions sort almost any AI workload: 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 the split mostly writes itself. 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 — exactly the profile where a 30B-class model on hardware you own is enough. The hard lanes escalate 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 is not enough for the work you escalate. It is more than enough for the lanes where the model's job is to compress, sort, and label.
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. It is built so the models behind its routes can change; the policy file and the log format are what persist. That asymmetry is the whole argument.
Local rarely 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 mostly right, 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, your argument is losing.
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, which converts a whole class of data-processing and residency questions into non-questions. 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. That 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 do not convene a meeting to reconstruct behavior from memory. You hand over the log.
This is the part most rollouts miss. 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 the rollouts I run, it is consistently the artifact that moves a system from interesting demo to approved deployment.
So pick your split by workflow, not 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. The router is what you keep.