Chapter 17: The open model revolution of 2026

Introduction

The introduction frames February 2026 as a turning point when several open-source AI models matched or exceeded leading proprietary systems.

• February 2026 open-model shift: Explain why the chapter calls February 2026 a turning point: within ten days, multiple open-source models reached or surpassed the performance of the best proprietary AI systems.
  Why it matters: This claim sets the context for the models and comparisons that follow.

Key terms: open source models, proprietary AI systems

17.1 February 2026: A turning point

The section contrasts the former assumption that proprietary models led AI with the February 2026 open-model releases that challenged it.

• February open model turning point: Explain how the February 2026 releases challenged the assumption that proprietary models would always outperform open ones, and why the section calls this a paradigm shift.
  Why it matters: This shift explains why the chapter treats open models as serious alternatives to proprietary systems.

Key terms: open models, proprietary models, major benchmarks, frontier, paradigm shift

17.2 GLM-5

17.2.1 Architecture

This section explains how GLM-5 uses a mixture-of-experts design to draw on a very large model while activating only a relevant subset for each query.

• GLM-5 expert activation: Explain how GLM-5 can have 744 billion parameters while using only about 40 billion at a time, and why that can give it an advantage over a dense model with the same number of active parameters.
  Why it matters: The distinction between total and active parameters explains the section’s claim that GLM-5 can be both enormous and efficient in practice.

Key terms: GLM-5, mixture of experts (MoE), parameters, active, dense model

17.2.2 Trained on Huawei chips

This subsection uses GLM-5’s training hardware to show that frontier-scale models need not rely on NVIDIA GPUs.

• Alternative hardware for frontier training: Explain that GLM-5 was trained entirely on Chinese-designed Huawei Ascend chips rather than NVIDIA GPUs, and why that is notable for frontier-scale training.
  Why it matters: GLM-5 is an example of frontier-scale training beyond the usual NVIDIA hardware path.

Key terms: GLM-5, Huawei Ascend chips, NVIDIA GPUs, accelerator stacks, frontier-scale training

17.2.3 Benchmark results

The section reports GLM-5’s result on Humanity’s Last Exam and why it marked a milestone for open models.

• GLM-5 benchmark milestone: Explain how GLM-5 performed on Humanity’s Last Exam relative to GPT-5.2 and Claude Opus 4.5, and why the result was significant for open models.
  Why it matters: The result illustrates how competitive open models had become on a demanding reasoning test.

Key terms: GLM-5, Humanity’s Last Exam, open model, proprietary model

17.2.4 License

17.3 Qwen3-Coder-Next

17.3.1 Ultra-Sparse MoE architecture

This section explains how Qwen3-Coder-Next’s sparse activation reduces its runtime footprint and why quantized versions may run on consumer hardware.

• Sparse parameter activation: Explain that Qwen3-Coder-Next has about 80 billion parameters in total but activates only about 3 billion at a time, giving it a runtime footprint close to a 3B model.
  Why it matters: The active parameter count helps explain why this large model can have a much smaller runtime footprint.
• Consumer hardware feasibility: Explain why quantized versions might run on a desktop or laptop with enough RAM, and describe how to check requirements before downloading a large model.
  Why it matters: Checking the specific model’s requirements helps you judge whether your computer has enough RAM before a large download.

Key terms: MoE, parameters active, runtime footprint, quantized versions, consumer hardware, RAM, model card, Ollama model page

17.3.2 Coding agent focus

This section explains Qwen3-Coder-Next’s coding-agent focus and why its small runtime footprint makes local, offline use possible.

• Qwen3-Coder-Next for local coding agents: Explain that Qwen3-Coder-Next is designed for coding agents that can autonomously write, test, debug, and refactor code, and that its MoE design gives it the knowledge of an 80B model with the runtime footprint of a 3B model.
  Why it matters: This connects the model’s coding specialization and compact runtime to the possibility of a free, offline coding agent on your laptop.

Key terms: Qwen3-Coder-Next, coding agents, MoE, runtime footprint

17.4 MiniMax M2.5

17.4.1 SWE-bench parity

This subsection reports MiniMax M2.5’s SWE-bench Verified result and explains why its match with Claude Opus matters for coding performance.

• MiniMax SWE-bench performance parity: Explain that MiniMax M2.5 scored 80.2% on SWE-bench Verified, matching Claude Opus, and that the benchmark evaluates models on real-world software engineering problems.
  Why it matters: The result gives you a concrete basis for comparing MiniMax M2.5 with a leading coding model.

Key terms: MiniMax M2.5, SWE-bench Verified, Claude Opus

17.4.2 Cost advantage

This subsection illustrates MiniMax M2.5’s cost advantage over Claude through API pricing and the option to run open weights locally.

• MiniMax cost advantage: Explain the section’s cost comparison: MiniMax M2.5 API calls cost one-twentieth as much as Claude’s, while its open weights allow local use without API charges.
  Why it matters: The example shows how API pricing and open weights change the cost of using a model.

Key terms: MiniMax M2.5 API, Claude API calls, model weights are open

17.5 The benchmark picture

The section uses a benchmark comparison to show that open models have caught up with proprietary models while retaining a striking cost advantage.

• Open model benchmark parity: Explain how open models compare with proprietary models on major benchmarks and what the section says about their cost difference.
  Why it matters: The comparison challenges the assumption that proprietary models necessarily perform better.

Key terms: open models, proprietary ones, major benchmarks

17.6 The economics of open models

17.6.1 Agent cost analysis

This section compares the per-task cost of cloud API agents, a lower-cost model, and local Ollama deployment.

• Agent task cost tradeoffs: Explain why an autonomous agent can incur substantial cloud API costs and compare the section’s examples of frontier pricing, MiniMax M2.5, and local Ollama deployment.
  Why it matters: An agent that makes many calls can turn small API charges into a meaningful cost per task.

Key terms: input tokens, generated output tokens, MiniMax M2.5, Ollama

17.6.2 Why local agents change what is possible

This section explains how avoiding per-action charges makes long-running local agents more practical and affordable.

• Per-action cost and agent behavior: Explain why the cost of each agent action affects what people let an agent do: without a charge for every action, it can experiment, fail, retry, and tackle much longer problems.
  Why it matters: An agent’s running cost can determine whether it is useful for sustained work rather than just short tasks.
• Affordability of continuous agents: Describe why cost savings matter more for continuously running autonomous agents than for personal chatbots, and how local AI can affect whether a small business can afford AI.
  Why it matters: For a continuously running agent, operating cost can decide whether a small business can use AI at all.

Key terms: agent action, local agents, privacy, control, cost, autonomous agents, local AI

17.7 The Unsloth-to-Ollama pipeline

The section introduces the high-level path from a frontier open model to a locally deployed model specialized on your own data.

• Open model customization pipeline: Describe the high-level pipeline: start with a frontier open model, specialize it on your own data using fine-tuning tools, and deploy it locally.
  Why it matters: This gives you the overall purpose of the workflow before its steps are explained.

Key terms: frontier open models, fine-tuning tools, base model, deploy it locally

17.7.1 The complete custom model workflow

This section traces a custom model from fine-tuning with Unsloth to running it locally in Ollama.

• Custom model deployment workflow: Trace how a selected base model becomes a custom model running locally: fine-tune it on your examples with Unsloth, export the weights and tokenizer as quantized GGUF, define a Modelfile, then create and run the model in Ollama.
  Why it matters: It connects the fine-tuning environment to a custom model you can use on your own machine.
• Individual customization feasibility: Explain the section's claim about who can complete this custom-model pipeline compared with what it previously required.
  Why it matters: The comparison shows why the workflow is presented as practical for an individual reader.

Key terms: Unsloth, GGUF, Modelfile, Ollama, custom model, running locally

17.7.2 Why customization matters now

This section explains why fine-tuning is more valuable when it starts from frontier-quality open models and can produce specialized models that run locally.

• Frontier Starting Point: Explain how the starting point for fine-tuning changed with the new frontier open models: earlier base models were useful for learning but below frontier quality, while the newer ones are already world-class and can be specialized further.
  Why it matters: The quality of the starting model changes what a customized model can offer.
• Specialized Local Models: Describe the section’s examples of tailoring models to professional material and state the claimed benefits of running the resulting models locally.
  Why it matters: The examples show what specialization could look like in practice and why local operation is appealing.

Key terms: fine-tuning, base model, frontier open models, legal documents, medical literature, translation memories, locally, privately

17.8 What this means for you

This section argues that the practical skills developed throughout the book already count as building real AI applications.

• Practical AI builder skills: Explain why the section calls the skills developed in the book “real AI” rather than merely preparation for it, using examples of what those skills let a reader build or customize.
  Why it matters: It recognizes the applications you can already build as real AI work.

Key terms: Ollama, Python, Streamlit, system prompts, Modelfiles, RAG

17.8.1 How to try these models

This section explains how to find a currently available featured model, choose a version a Mac can support, and compare it with models already used.

• Featured model availability: Distinguish which featured model has an official Ollama download at publication time and how to look for alternatives for the others.
  Why it matters: Availability changes, so a model named in the chapter may not have an official download when you try it.
• Mac memory and model size: Explain how to choose a quantized model version that fits a Mac and what to check when running it.
  Why it matters: Checking memory needs helps you avoid pulling a model that is too large for your Mac.
• Model comparison habits: Describe how to evaluate a new model against ones already used and why to keep checking new releases.
  Why it matters: Comparing familiar and new models helps you notice tradeoffs as the model landscape changes.

Key terms: Qwen3-Coder-Next, GLM-5, MiniMax M2.5, official Ollama library, community builds, quantized version, RAM, model size, ollama ps, response quality

17.8.2 Practical next steps

This section suggests ways to test the chapter’s claims against current benchmarks and models, then continue experimenting with agents and fine-tuning.

• Checking Open Model Claims: Explain how to check whether the chapter’s model claims still hold by consulting current leaderboards and comparing a frontier open model with gemma2:2b on your own hardware.
  Why it matters: Checking current results and trying models yourself helps you avoid treating the book’s rankings as permanent.

Key terms: SWE-bench Verified, Humanity’s Last Exam, frontier open model, gemma2:2b, llmfit, quantizations

17.9 Further learning

The section closes the chapter by connecting the narrowing gap between open and proprietary AI to the value of practical model-building skills.

• Open Model Skills Relevance: Explain the chapter’s takeaway that open source AI has caught up with proprietary AI and that skills in running local models, building applications, and customizing their behavior are valuable to the industry.
  Why it matters: The work you practiced is relevant to how AI applications are being built more broadly.

Key terms: open source, proprietary AI, running models locally, building applications, customizing behavior

17.10 Beyond individual models: The rise of orchestration

This section describes how coordinator models combine other models, how an open-source project reproduced a commercial orchestration approach, and why locally run models matter as components of multi-agent systems.

• Coordinator model approaches: Distinguish the two coordination approaches cited as foundations for Sakana Fugu: TRINITY assigns roles across larger worker models, while Conductor learns strategies for orchestrating workers through natural-language instructions.
  Why it matters: These examples show why progress in AI need not come from improving a single standalone model.
• Open-source Fugu reimplementation: Explain how OpenFugu relates to the commercial Sakana Fugu product and what its release illustrates about open-model progress.
  Why it matters: The example connects a specific orchestration project to the broader pace of open-model development.
• Local models as components: Explain why the section presents locally run Ollama models as useful beyond standalone assistance and how the book’s existing skills relate to that use.
  Why it matters: It connects orchestration to practical skills the reader has already used with local models.

Key terms: Sakana Fugu, TRINITY, Thinker, Worker, Verifier, Conductor, OpenFugu, open source reimplementation, Ollama, standalone assistants

17.11 Exercises

17.12 Summary