What runs on your own hardware.

You've seen where the data goes and what your obligations are. So what's the alternative actually like? This lesson is about open-weight models: what they are, how far behind the best cloud models they really sit, and the specific jobs where that distance stops mattering. It's the lesson where a lot of vendors overclaim, so we'll be careful with the words.

What "open weights" means, in plain English

A model is, at bottom, an enormous file of numbers. Those numbers are the weights, and they are what the training process produced. An open-weight model is one where the vendor publishes that file, so anyone can download it and run it on a machine they control.

Be careful with the word open, though. Weights are not source code. You cannot read them and work out what the model will say, any more than you can read a photograph's pixel values and see the picture. Open here is about distribution rather than inspection. Anyone telling you a model is safe because it's open source has skipped a step.

What the format does give you is a property worth understanding, because it is unusually solid. A weights file is static data, not a program. It has no ability to open a network connection. It cannot phone home, because there is no home and no phone. You can confirm this by running a packet capture, or more bluntly by unplugging the network cable and watching it keep working. That's a physical property of the setup rather than a clause in someone's terms of service, and it is the single strongest thing that can be said in favour of running a model yourself.

One distinction to hold on to, because it is the most common overclaim in this market. Open weights and "runs in your office" are different claims. Several of the strongest open models run to hundreds of gigabytes at full precision and will not run on anything you'd put in a cupboard behind reception. Publishing the weights doesn't make the model small. When someone quotes you an impressive open model, ask what hardware it needs and what it costs to keep fed.

The gap, stated honestly

Open models are behind the best closed ones. Anyone who tells you otherwise is selling something, and your team will find them out the first time they hand it something hard.

Two independent measurements say roughly the same thing. Epoch AI has measured the lag between the best open-weight model and the best closed model at about four months, or 8 points on its capability index, over the period since January 2026. Artificial Analysis, checked in August 2026, had the top open model scoring 57 on its intelligence index against 61 for the top closed model.

The defensible way to put that: open models sit roughly one release cycle behind the frontier, and that gap has been stable for about 18 months rather than widening. The difference is real, and it's narrower than most people assume in either direction. What it is emphatically not is "caught up", and using that phrase will cost you credibility with anyone technical in the room.

Where the gap disappears, and where it bites

This is the part that actually decides projects. A four-point capability difference does not spread itself evenly across the work. It's invisible on some jobs and decisive on others, and the reason is mechanical.

Genuinely solved on your own hardware: summarisation, structured extraction from documents, classification and routing, transcription, translation, optical character recognition and document parsing, and question answering over your own document set. These are single-pass jobs. You hand over some content, one transformation happens, and you read the result. A small capability gap gets absorbed into that single pass and usually never surfaces in the output.

Where a frontier cloud model still clearly wins: hard agentic coding across a multi-file codebase, long-horizon reasoning, and complex multi-step tool use. These jobs chain dozens of steps, and each step depends on the one before it. A small per-step disadvantage compounds. By step twenty, a modest difference in reliability has become a large difference in whether the task finishes correctly at all.

That mechanism gives you a sorting rule you can apply without benchmarks. If the job is one pass over content you supply, running it in the building is a genuine option. If the job is a long chain where each step depends on the last, keep it on a frontier model, and if the material is sensitive, we'll cover how to do that safely in lesson five.

What the Australian government did about this exact question

There's a useful worked example in how the Commonwealth handled DeepSeek. Protective Security Policy Framework Direction 001-2025 required government entities to remove DeepSeek products, applications and web services from their systems. It also carved out, expressly, open-source large language models where the entire codebase is available for inspection, the model is deployed locally on a government system, and appropriate mitigations are in place.

The shape of that decision is the shape of this lesson. What got banned was the hosted service, where material leaves your control and goes to somebody else's servers under somebody else's law. What was expressly permitted was locally deployed open models with controls around them. The instinct that says "this model came from over there, so my data goes over there" is attaching the risk to the wrong object. That risk belongs to the hosted service. Download the weights, run them on your own machine with no outbound path, and the cross-border disclosure question simply does not arise.

Which leads somewhere counterintuitive and correct. A business pasting customer details into a US-hosted chatbot has a live cross-border disclosure question today. The same business running an open model on a box in its own office has none. What remains to manage is supply-chain integrity, which means getting weights from the vendor's own repository, verifying checksums, and refusing formats that can execute code when loaded. Those are controls you would want regardless, and they are cheap.