01One model, many tasks

Imagine learning to read. Once you can read, you do not relearn it for every new book — you reuse that one skill for menus, novels, and street signs alike. A foundation model works the same way. It is a large model pretrained on a broad sweep of data — meaning it learns general patterns first, before it is given any specific job. Then it is adapted: the same trained model is pointed at a particular task, like summarizing a report or answering a question. That is why we call it a "foundation" — many different tools are built on top of this one base. Tap a task to see how the same model gets adapted to it.

• A foundation model is pretrained on broad data, then adapted to many downstream tasks.
• It is a "foundation" because other applications and specialized tools are built on top of it.
• One strong base, reused — instead of training a brand-new model for every single job.

02"Frontier" models, and the shift that changed AI

Not every foundation model is at the cutting edge. The term frontier model is reserved for the most capable, highest-compute models — the ones at the leading edge of what is currently possible. Every frontier model is a foundation model, but most foundation models are not at the frontier. The deeper shift, though, is in how these models get built. The old way was: pick a task, gather data for it, train a fresh model just for that task — then repeat from scratch for the next task. Foundation models flipped that to pretrain once, adapt many: train one broad base, then reuse and adapt it across countless tasks. That reuse is what let AI capabilities spread so quickly across so many products.

• Frontier model: one of the most capable, highest-compute models at the leading edge.
• Old way: a new model trained from scratch for each task.
• New way: pretrain one broad base, then adapt it many times — far less duplicated effort.

03Scaling, and abilities that "emerge"

Why are frontier models so capable? A big part of the answer is scale. Broadly, scaling means increasing three things together: the size of the model, the amount of data it trains on, and the compute used to train it. As models scale up, researchers have observed something striking: certain abilities appear that were not obvious in smaller models — often called emergent abilities. A small model might fumble a kind of task entirely, while a much larger one handles it. The honest caveat: capability is something you have to measure and compare, not just assume from size — and a model that sounds fluent and confident can still be wrong. So treat capability claims as things to verify, not take on faith.

• Scaling = more model size, more data, and more compute, broadly together.
• Emergent abilities are capabilities that show up at greater scale and are not evident in smaller models.
• Capability is measured and compared — fluency is not proof of correctness, so verify claims.

04Open-weight vs closed models

Foundation models come in two broad flavours, and the difference is mostly about who can hold the model. An open-weight model lets you download the trained weights — the numbers the model learned — and run or adapt it on your own machines. A closed (or proprietary) model stays with its maker: you reach it through the vendor's hosted service or API, without ever downloading it. One important caveat that trips people up: "open-weight" is not the same as "open-source." Getting the weights does not mean you also get the training data, the full source, or unrestricted licensing — those are often still held back, and a license still governs use. Flip the toggle to see how the trade-offs shift.

• Open-weight: download the weights and run or adapt the model yourself.
• Closed / proprietary: use it through the vendor's hosted API — no weights to download.
• Open-weight ≠ open-source: downloadable weights do not guarantee open training data or unrestricted licensing.

05How to choose — and the wider ecosystem

There is no single "best" model; there is the best fit for your situation. A simple way to decide is to weigh four trade-offs: capability (how strong does it need to be?), cost (what fits your budget?), control (do you need to run and customize it yourself?), and privacy (must your data stay on your own infrastructure?). If control and privacy matter most, an open-weight model you self-host leans your way. If you want the strongest capability with the least setup and your data policy allows it, a hosted frontier model via API leans the other way. As for the ecosystem: there are several major foundation-model families today, spanning both approaches — some are open-weight families you can download and adapt, others are closed, hosted families reached through an API. The right starting point is the trade-off that matters most to your task, not the loudest name.

• Weigh capability vs cost vs control vs privacy — fit beats "best."
• Control & privacy first → lean toward a self-hosted open-weight model.
• Peak capability, least setup → lean toward a hosted frontier model via API.

06Check your understanding

07Take it with you & go deeper