Chapter 14Open vs. Closed Models and the Modern Landscape

A Map of the Territory

At the broadest level, models divide by how you get access to them. On one side are hosted models (often called closed or proprietary): you send your text over the internet to a provider who runs the model on their own computers and sends back the result. On the other side are open-weight models: the model's learned weights are published, so you can download them and run the model on your own hardware. Most real-world choices live somewhere along the line between these two poles, but understanding the poles first makes everything else clear.

Hosted (Closed) Models

With a hosted model, you never possess the model itself. You call it through an API — exactly as you did in Chapter 3 — and the provider handles everything behind the scenes. This is the most common way people begin, and for good reason.

The advantages are real. There is almost no setup: no powerful hardware to buy, no infrastructure to maintain. Hosted models are frequently the most capable options available, because the organizations running them are also the ones pushing the frontier. And they are maintained for you — improvements, fixes, and new versions arrive without any effort on your part.

The trade-offs are equally real. You pay an ongoing cost per token for as long as you use the model, which can add up at high volume. Your data leaves your machine and travels to the provider, which can be unacceptable for sensitive or regulated information. You depend on the provider: they can change prices, alter the model, or retire it entirely, and you have little say. And you get less control — you cannot deeply customize a model you cannot touch.

Open-Weight Models

With an open-weight model, the weights are published for anyone to download. You can run the model on your own computer or servers, entirely under your control.

The advantages mirror the closed model's weaknesses. You have full control and can run the model completely privately — your data never has to leave your own machine, which can be decisive for confidential work. There is no per-token fee; instead you pay for the hardware and electricity to run it, which at high volume can be far cheaper. You can customize and fine-tune the model deeply (Part V), and you have no vendor lock-in — no one can take the model away or change it underneath you.

The costs, again, mirror the hosted model's strengths. You need hardware and technical know-how to run the model well. The very best open models have historically trailed the very best closed ones in raw capability, though the gap has been narrowing steadily. And you are now responsible for maintaining, updating, and operating it.

It's a Spectrum, Not a Binary

Real life is rarely as tidy as "closed versus open." Many arrangements sit in between. You can use an open-weight model without running it yourself, by calling it through a hosting company that operates it for you over an API — giving you an open model's flexibility with a hosted model's convenience. Licenses range across a wide spectrum of permissiveness. The useful question is not which of two boxes a model falls into, but where it sits on the line, and whether that position fits your needs.

Other Axes That Matter

Open versus closed is the headline distinction, but several other dimensions matter just as much when choosing a model, and they apply regardless of where a model sits on the open-closed line.

• Capability versus cost and speed. Bigger, more capable models are generally slower and more expensive; smaller models are faster and cheaper but less capable. The most powerful model is rarely the right model for every task — a theme we return to in Chapter 46 on small models.
• Context window size. As we saw in Chapter 12, different models can hold different amounts of text at once. If your task involves large documents, this can be a deciding factor.
• Specialization. Some models are tuned for particular strengths — writing code, careful reasoning, or following instructions precisely. A model specialized for your task can outperform a larger generalist.
• Multimodality. Some models handle only text; others also understand images, audio, or more. If your agent needs to read screenshots or listen to audio, you need a model built for it.
• Latency. How quickly the model responds matters enormously for interactive agents, where a user is waiting. A slightly less capable but much faster model is often the better experience.

How to Choose: A Practical Framework

Faced with a real project, you can cut through the noise by asking a short series of questions. Let your answers, not the hype, guide you.

1. Is data privacy or compliance critical? If sensitive data must never leave your control, lean toward open-weight models you can run privately.
2. Do you need the absolute best capability available? For the hardest reasoning tasks, frontier hosted models are often still ahead — start there and only move if another need overrides it.
3. Will you run at high volume where cost dominates? At large scale, running an open model yourself, or choosing a smaller and cheaper model, can save a great deal.
4. Do you need to customize the model deeply? If you want to fine-tune the model on your own data and behavior, an open-weight model gives you that freedom.
5. Are you just learning or prototyping? Then optimize for the lowest friction: a hosted API gets you building in minutes, which is exactly why this book started you there in Chapter 3.

Start Simple, Stay Flexible

For most people most of the time, the wise path is to start with a hosted API to learn and prototype quickly, then move toward open or local models only when a concrete need — privacy, cost at scale, or deep customization — actually demands it. Do not start by wrestling with infrastructure you may never need.

There is one practical habit that protects you no matter which way the landscape shifts: do not hard-wire your code to a single model or provider. Wrap your model calls behind a thin layer of your own, so that swapping one model for another is a one-line change rather than a rewrite. This keeps you free to follow the rapidly improving options.

# A thin wrapper keeps your code independent of any one provider.
def generate(prompt, backend="hosted"):
    if backend == "hosted":
        return hosted_client.complete(prompt)   # a hosted API model
    elif backend == "local":
        return local_model.complete(prompt)     # an open model you run

# The rest of your program calls generate() and never needs to know
# or care which model is actually behind it. Swapping is trivial.

Summary

Models divide first by access: hosted (closed) models you call over an API, which are easy and often the most capable but cost per token and keep your data on someone else's servers; and open-weight models you run yourself, which give privacy, control, and customizability at the price of infrastructure and effort. Reality is a spectrum between these, and other axes — capability versus cost, context window, specialization, multimodality, and latency — matter just as much. Choose by asking practical questions about privacy, capability, volume, customization, and your stage of work, and in most cases start with a hosted API and stay flexible by wrapping your model calls. Above all, learn the durable distinctions rather than memorizing a landscape that changes monthly.

This completes Part III: you now understand what large language models are, how they read and reason, how they are built, and how to choose among them. Part IV turns to the foundation beneath every capable model — the data — beginning with where training data comes from and how it is prepared.