Reading the Landscape

Lesson 1 of 3 in Model Families.

An honest opening for the most volatile domain on this site: any specific model this page could name will eventually be someone’s legacy migration. New Large language model (LLM) releases arrive monthly; deprecation notices follow on a schedule measured in quarters. If your mental map of the landscape is a list of model names, it expires like milk. The map that lasts is drawn at a different altitude: the Model family.

A family is a named lineage of models from one developer — releases that share an architecture lineage, a Tokenizer, a license lineage, a distribution channel, and a set of engineering values. Learn a family once and every new release inside it becomes a fifteen-minute read: you already know who builds it, where its model cards live, what its license tends to require, and what kinds of trade-offs its designers favor. Learn only models, and every release is a cold start.

The asymmetry is the whole argument: models deprecate; families persist. A Model release is an artifact with a shelf life. The family is the institution around the artifact — the team, the conventions, the license scheme, the org page that survives every individual checkpoint that passes through it.

How a model family evolves — the generic release pattern

  1. Generation N: base model

    A new pretrained checkpoint. The architecture and tokenizer are fixed here — every variant downstream inherits them.

  2. Instruct / chat variants

    Post-trained for dialogue and instruction following — usually the releases you actually deploy.

  3. Capability variants

    Reasoning modes, vision or audio variants — new abilities grafted onto the same base lineage.

  4. Size and efficiency variants

    Small siblings and quantized releases extend the family down the cost and hardware curve.

  5. Safety siblings

    Guard and moderation models that ship alongside the family and share its conventions.

  6. Generation N+1 ships

    The cycle restarts on a new base. Licenses, sizes, and traits can all change between generations — re-verify, never assume.

  7. Older releases deprecate — the family persists

    Models move to the deprecated table; the org page, the conventions, and the lineage continue.

This pattern — fan-out, then generational turnover — is why this site refuses to keep model facts in prose. Prose carries no expiry date; facts about models need one. Every model-specific statement in this domain (a parameter count, a context window, a license name) lives in a dated fact table: each row records the official page it was read from and the date it was read, and quoted phrases are verbatim from those pages. The lessons cite the table instead of asserting from memory, and the Release Log tracks what has changed since.

Steal this discipline for your own organization, because design documents suffer the same decay. The durable content of an architecture decision is the family and the requirements — why this lineage, what it must do, what terms you can accept. The volatile content — the exact model id, its documented limits, its license text — belongs in a dated registry with source links, re-verified whenever a model id changes. A model name in undated prose is a bug waiting for a deprecation notice.

Key terms: Model family, Open weights, Closed weights, Model card, Community license, Gated distribution

What actually persists across a family

Five properties tend to be stable within a family, and they are exactly the properties worth learning:

The tokenizer. Vocabulary changes are rare within a generation, so token-denominated intuition — how prompts meter, how Context window budgets spend — transfers between siblings in a way no Benchmark score does.

The architecture lineage. Dense or mixture-of-experts, text-only or Multimodal — design commitments echo through a family’s releases because the developer’s training stack and serving stack are built around them.

The license lineage. Vendors keep a licensing scheme — permissive, custom community terms, or a mixed catalog — even as exact names change per generation. The scheme tells you what to check; the per-model card tells you the answer.

The distribution channel. An org page, a vendor docs page, cloud model catalogs: where a family lives determines how you discover releases, read cards, and obtain weights or endpoints.

The conventions. Chat formats, reasoning-mode toggles, naming patterns, safety siblings — the family’s habits, visible in every card.

Each of these is a tendency, not a guarantee — which is precisely why the fact table exists: it records the exceptions, with sources, so the tendencies can be trusted for navigation and the specifics can be looked up.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.