Open-Weight vs Frontier

Learning Objectives

By the end of this lesson, you can:

• Define open-weight and frontier models in one sentence each
• Install a small open-weight model on your machine and run it
• Compare an open-weight model's answer to a frontier model's answer to the same prompt
• Pick open-weight or frontier for a given scenario based on cost, privacy, and offline needs
• Explain why "open weight" is not the same as "open source"

The Problem

The default the chat app hands you is a frontier model. You never made that choice, and it is the most consequential choice you will make all session.

It is consequential in three ways at once: every call costs money, every call sends your prompt to a datacenter, and every call needs a network. The first one shows up in your bill. The second one shows up in your privacy review. The third one shows up the moment you try to work on a plane.

An open-weight model is a different shape of the same job. A file you can download. Runs on your hardware. No bill per call, no prompt leaving your machine, no network needed after the initial download. Different shape, different cost, different trade-offs.

Most people never make this choice consciously. They take what the app defaults to. After this lesson, you will pick on purpose, and you will know which scenarios push you to which side.

The Concept

Two kinds of model. Same job. Different shape.

The size column is not the point. Some open-weight models are huge. Some frontier models are modest. Size is a description, not the definition.

The reframe: the difference between open-weight and frontier is whether the weights are public, not how big the model is.

flowchart LR
  A[You] -->|download weights once| B[Open-weight<br/>runs on your laptop]
  A -->|pay per call| C[Frontier<br/>runs in a datacenter]
  B --> D[Cost: electricity<br/>Privacy: local<br/>Offline: yes]
  C --> E[Cost: per call<br/>Privacy: leaves machine<br/>Offline: no]

Build It

You will install one small open-weight model, ask it a question, then ask the same question of a frontier API, and compare.

1. Install a runtime that runs models locally. Three common options:
   • ollama from ollama.com — easiest install, one-command model pull
   • llama.cpp from github.com/ggerganov/llama.cpp — lower-level, more control
   • opencode from opencode.ai — a coding-agent CLI that takes any open-weight model as its backend (you point it at a local runtime like Ollama or any OpenAI-compatible endpoint)

Pick one and follow its install steps.

1. Pull a small chat model. Example (may need updating):

`` ollama run qwen2.5:3b ``

A small open-weight chat model such as Qwen-2.5-3B-Instruct (about 2 GB, fits on most laptops). If that exact tag has changed, the runtime's model library will show the current small option. Another well-known family in the same tier is DeepSeek (e.g. ollama run deepseek-r1:1.5b, or pointing OpenCode at a deepseek-coder / deepseek-r1 tag on a local Ollama instance); either one gives the lesson the same lesson — that the weights are a local file and the call has no per-token bill, regardless of which runtime drives the model.

1. Ask it a question. Try:

`` Explain in two sentences why a hash table lookup is O(1) on average. ``

Note the answer and how long it took.

1. In a separate terminal, send the same prompt to a frontier API you have access to. Note the answer and the latency.

1. Compare. Write down, in one sentence per model: what it got right, what it got wrong, how long each took, and what each call cost.

Pass: you have one sentence per model, the open-weight model ran on your machine with no network after the initial download, and you can state which you would reach for next time and why.

Use It

Exercises

1. Define it. Without looking back, write one sentence each for "open-weight model" and "frontier model." Then check against the table in this lesson. Pass: both sentences mention whether the weights are public and where the model runs.

1. Run the comparison. Pick a prompt you actually care about — a refactor plan, a tricky regex, a domain question. Send it to a small open-weight model running on your machine and to a frontier API. Score each on correctness, latency, and cost. Pass: a one-paragraph written comparison, and a stated pick for that exact prompt.

1. Pick for a new scenario. A hospital wants an assistant that reads patient notes and suggests follow-up questions for the doctor. Patient notes cannot leave the building. The hospital has a small GPU server. Pass: you name open-weight, give two reasons from this lesson, and name one tradeoff the hospital will have to accept (slower responses, smaller model capacity, hardware cost — your choice).

Key Terms

What this lesson skipped

Training, fine-tuning, distillation, and quantization. These are the levers that make open-weight models useful in practice — a 3B-parameter model fine-tuned on your support tickets will often beat a generic frontier model on your specific task. They are also where the real complexity lives: data pipelines, eval sets, GPU memory, and the discipline of not teaching your model to lie. Those come in later lessons. For now, the question is just: can you download it, or can you only call it?