What is open-source AI, and why does it change who holds the power?

When a model ships with its weights publicly available under a permissive license, it doesn't just change the download page — it shifts the entire balance of who can build, deploy, and compete in AI. That structural shift is exactly what the latest wave of open-weight coding models is forcing practitioners to reckon with.

Why this matters now

For most of the last few years, access to frontier AI capabilities required a subscription, an API key, and a willingness to send your data to someone else's servers. A closed model is a service; an open-weight model is an artifact you own. The difference sounds philosophical until you're building a production agent, working in a regulated industry, or simply trying to control your infrastructure costs. Open-source AI breaks the dependency on a small cluster of well-capitalized labs and makes frontier-quality capabilities available to any team with the hardware to run them. The repeated emergence of competitive open-weight models from outside the traditional power centers reinforces a durable pattern: capable models can be built and released by a much wider range of actors than the mainstream narrative typically acknowledges.

How it works

Open-source AI refers to models released with publicly accessible weights — the numerical parameters learned during training — typically under licenses that permit free use, modification, and redistribution. The "open" in open-source AI exists on a spectrum, and the license terms determine what you can actually do.

Release type      Weights public    Commercial use
Full open         Yes               Yes
Restricted open   Yes               Limited
Closed API        No                Via vendor

At the fully open end, an MIT or Apache license lets you download weights, run inference on your own hardware, fine-tune on proprietary data, and integrate into commercial products without royalties or usage reporting. At the restricted end, a model may be publicly downloadable but carry clauses that limit commercial deployment or require attribution. Closed models expose none of this — you interact only through an API, the weights never leave the vendor's infrastructure, and your access can be repriced or revoked.

The practical mechanics are straightforward: weights are distributed as large files (often in the tens to hundreds of gigabytes), loaded into a runtime framework, and executed on GPU or specialized hardware. Once the weights are local, inference runs entirely under your control. This is what makes open-weight models relevant to on-device deployment scenarios, air-gapped environments, and cost-sensitive agentic pipelines where API calls accumulate rapidly.

Real-world applications

Open-weight models unlock several categories of use that closed APIs make difficult or impossible. Fine-tuning on proprietary codebases or domain-specific documents is the most common enterprise application — you adapt the base model to your vocabulary and use cases without exposing sensitive data to a third party. In retrieval-augmented generation systems, an open model sitting alongside a vector database means the entire pipeline runs on your infrastructure; embeddings, retrieval, and generation all stay in-house. For agentic workflows that involve multi-step tool use and long context, controlling the model layer removes a significant variable in latency, cost, and rate-limit exposure. On the hardware side, open weights enable deployment on edge devices and mobile platforms — including ARM-based chips with heterogeneous core architectures — where you cannot rely on a persistent API connection. For developers learning agent architectures or experimenting with RAG pipelines, the ability to run a capable model locally changes the economics of iteration entirely.

Where to go deeper

If this framing connects to work you're doing or planning, several topics on the platform extend it directly. Retrieval-augmented generation and vector databases cover how to build the retrieval layer that pairs with any open model for knowledge-intensive tasks. Text embeddings explains the representation layer that makes semantic search in those pipelines work. For deployment on constrained hardware, the Arm big.LITTLE course covers the heterogeneous chip architectures increasingly used to run inference at the edge, and Android sideloading addresses how to get custom model runtimes onto devices outside standard distribution channels. The thread connecting all of them is the same: once you control the weights, the infrastructure decisions become yours to make.