Cassette Build Report 001 — Can a Frontier Model Run from an External Drive?
Cassette began with a practical question about putting a very large language model on a physical drive and making it useful on consumer hardware.
Scope note: This post covers the question that started Cassette and the value I see in asking it. It does not claim that Cassette already runs a frontier model from an external drive or that the engineering problem has been solved.
I began Cassette with a 2 TB LaCie Rugged drive and a MacBook Air: one ordinary external device and one ordinary consumer computer. Could a very large language model live on the drive and remain useful through the Mac?
I did not want another chat application or an Ollama wrapper with a new button. I wanted to test what a person could do with a laptop, a drive, and a model that normally lives in a datacenter.
The obvious response was that the model would be too large. The memory would not hold it. The drive would be too slow. The result would be an archive, not a working system. I expected that response, which is why I asked for reasoning from the model and hardware level rather than a quick product survey.
The social question sat inside the technical one. Frontier models are concentrated in datacenters because the hardware needed to serve them is expensive and centralized. A person can download a model, but possession is not the same as practical use. If the full model can sit on a device that a person can carry, revise, and keep, then the relationship between a model and its owner changes. The model is no longer only a remote service reached through an account.
That change would matter to more than enthusiasts. Researchers could keep a large model near sensitive material. Small organizations could experiment without sending every prompt to a vendor. Open-source projects could work toward a wider range of usable model sizes instead of treating consumer hardware as a permanent lower tier. Those are possibilities, not results. Cassette has to earn them through the physical path.
The first answer from GPT-5.6 Sol Ultra did not dismiss the question. It proposed a compiler that would keep a shared part of the model ready and move selected parameter pages from storage as the request required them. It discussed page layout, routing, adaptive precision, and tracing. The answer contained useful mechanisms. It also made a decision I had not authorized: it turned one possible architecture into the project and named it CartridgeLM.
That mistake became part of the specification. I learned that a technically serious answer can still be unfaithful when it answers a narrower question than the one I asked. The model had found an interesting way to attack the storage problem. It had not yet shown that the way belonged to Cassette.
The project therefore began with two obligations. The first was physical: the majority of the model had to remain on external media, and the Mac had to contribute computation and coordination without quietly becoming the host. The second was editorial and public: I needed a record of the corrections that made those obligations exact.
I am keeping both obligations in view because a system like this can fail in two ways. It can fail in code. It can also succeed at a smaller, easier problem while its author continues to describe the larger one. Cassette is worth building only if the public claim stays attached to the actual model, the actual storage path, and the actual limits.
The opening question remains open. That is not a weakness in the record. It is the reason the work has a subject.
