Cassette Build Report 004 — The Model Stays on the Drive

Scope note: This post covers the physical placement and user-facing performance requirement for Cassette. It does not claim a measured throughput, a completed runtime, or parity with a datacenter service.

The word “approach” caused the next problem.

I said Cassette should perform at the level people expect from a very large model such as Kimi K3 when that model is accessed from its laboratory. I meant the experience a person receives: inference speed, response time, and answer quality. I was flexible about the method. The system could transform, schedule, page, cache, retrain, quantize, predict, or combine those operations if the physical evidence supported them.

I was not flexible about changing the subject. A smaller local model could not stand in for the frontier model simply because it ran more quickly. A slow result could not be declared acceptable because the mechanism was interesting. The person waiting for the first token would experience the whole path as one system.

GPT-5.6 Sol Ultra drifted into a familiar arrangement. It began speaking as though the model would be hosted on the Mac and the external drive would provide supporting storage. That would have been an easier problem. It would also have been a different project.

I stopped it: “You’ve drifted into hosting on the mac. Do not do that.”

The full local model belongs on the external physical drive. The Mac contributes computation, unified memory, and coordination with the storage path. The drive is not an archive and not merely a download folder. If the model becomes an ordinary Mac installation after activation, Cassette has avoided the central constraint rather than solving it.

That distinction changes what has to be measured. The project needs the path from the external device through the transport and filesystem to the operations that produce tokens. A parameter that never becomes reachable does not count as preserved capacity. A file that can be opened once but cannot sustain the working set is not a usable model. Storage traffic cannot be made faster by giving it a different name.

The performance question therefore has three parts. How quickly can the system begin? How quickly can it continue? Does the answer retain the breadth and long-tail knowledge that motivated using a model larger than the machine’s unaided memory?

The last part matters because I am not trying to win a datacenter contest with a laptop. Cassette exists to change what the same consumer machine can do when a large model is available on a physical device. The meaningful comparison is not only against a hosted service. It is against the strongest model that machine can run without Cassette.

That comparison had not been written yet. At this stage, I only knew the direction of the correction. The external device had to remain part of the model system, and the performance claim had to include the cost of the path rather than hide it.

This is the kind of correction that looks obvious after it is written down. It was not obvious inside the first answer because the ordinary architecture was easier to complete. The agent knew how to describe a Mac-hosted model. It had to be made to keep describing the problem I had actually asked.

Cassette’s physical center is now explicit. The model stays on the drive. Everything else has to answer to that fact.