A personal agent may need your messages, calendar and accounts, which makes sending every thought and action through a cloud provider a hard bargain. That trust problem comes before the practical question: which jobs are small and measurable enough to move onto your own hardware? Quantization and llamafile show how models fit and travel; Foundry Local turns them into a desktop product instead of a folder of weights. On phones, the choices become concrete: Android can share Gemini Nano across apps, an app can ship a tiny fine-tuned function caller, or an iPhone can run Gemma 4 through MLX. The extravagant version comes last: a frontier model spread across home hardware, where memory bandwidth and the split between prefill and decode set the limits.
Why first: Chintala starts with the personal reason to run locally. A continuous agent needs broad access to private services, yet its powerful actions make a cloud provider harder to trust. Khalil's panel comes next because it turns that private need into a choice of models, harnesses and hardware.
Why second: Chintala gives the personal case for local AI. Khalil's panel widens it into a system design: frontier models can plan while smaller local models do the routine work. Nabors follows by showing how to decide which tasks can actually move onto the device.
Why here: Khalil's panel proposes using different models for different jobs. Nabors supplies the test: prove the task with a large model, then choose the smallest model that clears a measured bar and let the harness catch simple errors. The compression panel next tackles what happens when the chosen model still does not fit.
Why here: Nabors chooses the smallest model that can do the job. The compression panel offers another option: shrink a larger model without blindly trusting benchmark scores. Hood and Tunney follow because fitting the model into local memory is only half the problem; someone still has to make it easy to run.
Why here: the compression panel gets a model down to a usable size. Hood and Tunney package the weights and runtime into one executable that can run across operating systems, even on a CPU. Ning comes next with the step beyond a portable runtime: a complete desktop application that chooses and manages local models for the user.
Why here: Hood and Tunney make one model executable portable. Ning turns local inference into a desktop product, with the same document app running on Windows and Mac and a service managing the models underneath. Muntenescu and Gaymond take that managed approach onto a phone, where the operating system shares one model across apps.
Why here: Ning's desktop app relies on a local service to manage models. Muntenescu and Gaymond show the phone version: Android installs Gemini Nano once, schedules its work and lets several apps call it. Brick follows with the alternative, where the app ships its own smaller model and accepts more setup in return for more control.
Why here: Muntenescu and Gaymond make the case for a system model that apps share. Brick puts that beside an app-level model tuned for one narrow job, including a tiny function caller lifted from 46 percent to over 90 percent on most app intents. Grondin comes next with the corresponding route for developers building on Apple hardware.
Why here: Brick shows why an app might ship and tune its own phone model. Grondin gives Apple developers a short route from MLX Swift LM to a working iPhone app, then shows Gemma 4 running at about 40 tokens per second. Cheema closes the pack by pushing past phone-sized models to the outer limit of hardware a person might keep at home.
Why last: Grondin shows what one current iPhone can do. Cheema asks what it takes to run a frontier model at home, where decode becomes a memory-bandwidth problem and different devices can split prefill from decode. It belongs last because the private personal need from Chintala has now become a demanding hardware and systems project.