Product platforms
| Platform | Runtime expectation | Storage interfaces |
|---|---|---|
| Apple-silicon Mac | Full product surfaces and supported MLX model runtimes. | Internal flash, USB 3, USB4, or Thunderbolt according to the exact Mac and connected path. |
| iPhone | The same catalog, storage, verification, planning, conversation, and runtime logic with platform-adapted navigation and file selection. | Internal flash or system-supported external storage. High-speed external streaming requires a model whose specifications explicitly provide the needed USB or Thunderbolt mode. |
| Intel Mac | Management surfaces may be present in a universal build, but MLX model execution is unavailable. | Storage can be managed, but it cannot make the MLX runtime executable. |
Memory and storage are independent gates
A fast SSD does not replace the model's working-memory floor, and large physical memory does not repair an unstable or unsuitable storage path. Minirun admits a run only when the model-specific minimum fits within the current safe device limit; that limit reserves headroom for the operating system and can be lower than the marketed unified-memory capacity.
The Memory Dial then governs the accepted plan. Storage capacity, folder authority, complete verification, runtime support, and device admission must still pass independently.
External I/O is an end-to-end capability
- Host
- Confirm the data standard supported by the exact Mac, iPhone, or iPad port.
- Cable
- Use a cable rated for that data standard, rather than one limited to charging or USB 2 data.
- Hub or dock
- Confirm that it preserves the required data mode and provides adequate power.
- Bridge
- The enclosure must support the host mode, including an explicit USB fallback when needed.
- SSD
- Allow sufficient capacity and choose stable sustained-read and thermal behavior.
- Filesystem
- The operating system must mount the data volume and Minirun must receive folder authority through the picker.
Compatibility is layered
A single Supported badge cannot describe every stage. Minirun evaluates repository discovery, container understanding, runtime integration, local verification, and device admission separately. This allows future containers to remain visible without being offered for chat prematurely.
- Repository
- A current Minirun publication must provide an authoritative complete tree.
- Container
- The app must validate the layout and metadata without guessing.
- Runtime
- The product needs the model adapter, input pipeline, and runner for this family.
- Verification
- The selected local bytes must match the publication and filesystem evidence.
- Device
- The current architecture and safe memory ceiling must admit the plan.
Repository updates
A Minirun repository can publish a new immutable version without requiring the app to hard-code one commit forever. The catalog resolves the current authoritative version, and a local copy must verify against the version it actually represents before execution.
An already verified local model remains local. Refreshing the remote catalog is useful for discovering a new publication, but it is not a prerequisite for every chat turn. When the selected local bytes and their saved evidence still match, the app can describe that state without pretending the network installed anything.
New model families
Adding a model family means more than displaying its name. A complete product integration must define the container layout, verify runtime metadata, assemble the model's supported inputs, execute within the Memory Dial, stop and tear down safely, and report honest telemetry. Until that binding exists, the correct product state is storage and verification only.