"The model is open" is one of the most misunderstood sentences in AI. Students hear it and assume free, private, and easy to run. Sometimes none of those is true. This lesson gives you the vocabulary to tell the difference — before you download 40 gigabytes onto a laptop that cannot hold them.

Five terms, said plainly

Learn these once and a hundred announcements will parse cleanly:

These combine freely. An open-weight model can be run locally, self-hosted on a rented server, or accessed through a provider that hosts it for you. A proprietary model, by definition, is only available through its owner. And "open weights" is not the same as "open source" in the strict software sense — weights plus a restrictive license is open-weight but not open-source software. The distinction matters when lawyers, budgets, or redistribution enter the picture.

Who runs the computers?

  Your machine          →  local model
  A machine you rent/control →  self-hosted model
  The model company's servers →  proprietary hosted (or hosted open-weight)

Who published the weights?

  Published for download →  open-weight
  Kept private           →  proprietary

Why "open" does not automatically mean free, private, cheap, or easy

Each hopeful assumption needs its own correction:

• "Open means free." The download may be free; running it is not. You pay in hardware, electricity, cloud GPU rental, or a provider's per-token price for hosting it. A large model can cost more to self-host than to call through an API.
• "Open means private." Only if *you* run it where you control the data. An open-weight model accessed through someone else's API sends your prompt to their servers exactly like a proprietary model does. Privacy comes from where it runs, not from the license.
• "Open means cheap." Small open-weight models are cheap to run. Large ones demand serious GPUs and memory. Always check the size and hardware notes before assuming savings.
• "Open means easy." Downloading weights is the easy part. Quantized variants, drivers, memory limits, context configuration, and tooling are where beginners stall. A hosted API is often the saner first step; local comes when you have a reason (privacy, offline work, experimentation, scale economics).

The builder's version: openness describes access to the artifact; local describes where computation happens; cost and difficulty describe what you must supply. Three different questions. Do not let one word answer all three.

Hugging Face: the library for open models

Hugging Face is the place these questions get answered. Think of it as a public library plus collaboration platform for models: model pages with documentation, licenses, downloads, datasets, demo Spaces, and discussion. You will meet it again in Class 11 when you investigate model families. For now, learn to read one page well.

A model page typically offers: the model card (documentation), the license, file sizes and variants, download counts, community activity, linked datasets, and runnable demo Spaces. Demos are wonderful for a first feel; the card is where decisions get made.

How to read a model card like a builder

Open any popular model page on Hugging Face and find these eight fields. Each one answers a specific builder question:

Annotated model card (what to circle):

  ┌─────────────────────────────────┐
  │ Creator + official badge  → Can I trust this upload?  │
  │ Intended task             → Does it match my job?     │
  │ License                   → May I use it commercially?│
  │ Size + quantized variants → Fits my hardware?         │
  │ Context length            → Fits my files?            │
  │ Hardware needs            → What must I rent or own?  │
  │ Limitations               → Where will it fail me?    │
  │ Example use               → How do I run it?          │
  └─────────────────────────────────┘

Two traps to avoid. First, download count is popularity, not suitability. A million downloads of a chat model tells you nothing about whether it edits code with tools or fits on your laptop. Second, "runs on my laptop" claims need numbers. If the card says 70B parameters and you have 16 GB of RAM, the honest answer is "not without a quantized variant or a hosted option" — check the quantized files and the VRAM notes rather than hoping.

A note on dating your knowledge: model pages update. When you record a decision, note the model name *with version/revision*, the date you read the card, and the license you saw. A decision that says "MIT license, checked September 2026" survives; "it looked open" does not.

Practical exercise: inspect one model page

1. Go to Hugging Face and pick one widely used open-weight model (your instructor or a classmate can suggest a current one, or search for one matching a task you care about). 2. Fill in the eight builder fields: creator (official?), intended task, license, size, context length, hardware needs, limitations, example use. 3. Answer in writing: does this model make sense for your machine and your task? Name the binding constraint — license, hardware, context, or task mismatch. 4. State how you would access it: locally, self-hosted on rented hardware, or through a hosted provider — and what that choice implies for privacy (where does your prompt go?).

Finish line: a one-page model brief — eight fields plus your fit verdict and access choice — saved in your notes. If you cannot fill a field, write "not found on the card" rather than guessing; that gap is itself a finding.

Quick verification: check two things — (a) is the page from the official organization, and (b) does the license actually permit your intended use? If either answer is uncertain, you are not done.

Common failure mode: downloading tens of gigabytes before reading the hardware and license rows. Read first, download second. Your disk and your lawyer will thank you.

Check your understanding

1. What is the difference between an open-weight model and a local model? 2. Why can an open-weight model still send your data to someone else's server? 3. What does the license on a model card decide, and why can you not infer it from the word "open"? 4. Which card fields determine whether a model fits your hardware? Your files? 5. Why is download count weak evidence that a model fits your task?

Next, in Lesson 8.4, you meet the specialists: vision, audio, and other models for work that text alone cannot do — with a modality map that tells you which input belongs to which capability.