Open Minis
An on-device AI Agent that runs on your phone, open & secure
148 followers
An on-device AI Agent that runs on your phone, open & secure
148 followers
Open Minis is a free, open-source AI agent for iOS and Android that does more than chat — it gives the model a real computer to work with. A sandboxed Alpine Linux shell runs on your device: it installs packages, runs Python, edits real files and drives a browser. Around it, 30+ native bridges reach HealthKit, HomeKit, Calendar, Photos. etc. Bring your own model — Claude, GPT, Gemini, Kimi, Grok, or any OpenAI-compatible endpoint. Keys and data never leave your phone. Free and Open Source.
Free
Launch Team
Render: Get up to $100K in startup creditsCloud infrastructure for founders who want to move fast and NOT break things
Promoted
@wang_ethan local-first plus bring-your-own-model is the right bet, that's the actual value over another cloud chat wrapper. one thing i'd want clarity on before turning it loose on healthkit or homekit: since the bridges are exposed as plain command-line tools the same way ls is, does that mean once granted, the agent has blanket access to all 30+ bridges, or does ios still gate each one separately the way a normal app has to ask for health data, photos, and home access as distinct permissions? no server in the path removes one kind of risk, but a model doing something dumb with data it didn't need for the task is a different one, and it doesn't go away just because it's on-device.
Giving the agent a real local shell instead of another chat layer is a great direction. Python, git, ffmpeg, and the native bridges make it feel genuinely useful on a phone, not just impressive in a demo. How do you handle permissions and approval when a task touches sensitive areas like HealthKit, Photos, or HomeKit?
@alpertayfurr Permissions are gated in two layers: iOS's own native system prompt (first-time access to HealthKit/Photos/HomeKit etc.), plus a configurable approval layer in Minis Settings → Permissions, set per capability as either "ask every time" or "ask once." Same model as Claude Code or ChatGPT — human checkpoint before sensitive actions, tunable per tool. If disabled, the call just fails and I point the user to the setting.
@wang_ethan That two-layer model makes a lot of sense. Native permission + per-capability approval feels like the right balance between usability and safety, especially for sensitive actions.
the cli bet is the interesting part and i think it is right, models are genuinely good at command lines. what it costs you is that a command line does not tell the model what a command costs.
ls and rm are the same shape until you read the name. a health read and a home unlock are both just tools in a namespace. so the surface encodes capability and not effect, and effect is what you would actually want to gate on: does this read, does this write, does it move something in the physical world.
gal's question above is about reach. mine is about what happens after it reaches. no server in the path removes the leak risk and it also removes the log. if it does something dumb at 2am there is no server side record to reconstruct what it ran, and that is the half of no telemetry that never makes the slide.
are the 30+ offloads classified by effect anywhere, or is it one flat namespace where reading step counts and unlocking a door look identical to the model?
Local-first is doing some heavy lifting on this page. Keys and files stay on the phone, but the second the agent reads HealthKit and drops it into a prompt, that data is sitting on someone's inference server, and it's whichever provider the user picked rather than one you can vouch for. That's still a better story than every cloud wrapper, it just isn't no server in the path, and the people who care about that distinction are exactly who you're selling to. I'd say it plainly on the page: on-device execution, remote reasoning.
Great product, totally in love with it now