Off Grid AI (OGAM): an on-device model manager with a chat UI on top
The Swiss Army Knife of Offline AI. Chat, see, speak, and generate images on your phone or Mac — GGUF LLMs, vision, Whisper speech-to-text, Stable Diffusion, tool calling, and local-network servers. Runs on your CPU, GPU, or NPU. No account, no API key, zero data leaves your device.
At a glance
- What is it?
- OGAM is a React Native and TypeScript app that runs GGUF language models, Whisper transcription, Stable Diffusion and vision models directly on Android, iOS and macOS hardware. The interesting part is not the chat screen, it is the RAM policy and backend detection that decide which model actually loads.
- Who is it for?
- Adopt Off Grid AI if you want an MIT-licensed mobile app that runs GGUF, Whisper and Stable Diffusion on-device with a visible RAM budget, and if you are willing to choose your quant to match the backend. Do not adopt it as a headless inference server or as a replacement for a desktop toolchain.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not inference, it is picking and holding a model on a phone
Running a GGUF file on a phone is a solved enough problem that several libraries will do it. The harder problem is that a phone has a fixed RAM budget shared with the operating system, the launcher, and whatever else the user left open. OGAM treats that as the central design constraint rather than an afterthought. The README describes a model manager that shows what is resident right now and what each model costs in RAM, with a per-model eject button. That is a different product from a chat wrapper: it is a resource manager with a chat interface attached.
The audience follows from that. This is for people who want to run Qwen 3, Llama 3.2, Gemma 3, Phi-4 or their own .gguf files on hardware they already own, and who accept that they must think about quantization and backend support before downloading a multi-gigabyte file. It is not aimed at someone who wants a hosted endpoint behind a local API shape.
Three loading policies and a backend probe decide what runs
The mechanism visible in the README has two layers. The first is backend selection. The app detects what the device has and defaults to the fastest backend that works, with a manual override in Settings. On Adreno GPUs it uses OpenCL, and the README gives 20 to 40 tok/s on a Snapdragon 8 Gen 2 or newer against 15 to 30 on CPU. Apple Silicon goes through Metal. The Hexagon NPU is exposed but marked experimental, and the README is specific about why: it only accelerates Q4_0 and Q8_0 quants, a K-quant silently falls back to CPU, and some model architectures produce garbled output on it. Models that can use the GPU or NPU are badged in the model list, which is the practical mitigation for downloading 4GB of the wrong thing.
The second layer is the loading policy, exposed as Model Loading with three settings. Lean keeps one model in memory at a time. Balanced co-resides models that fit and swaps the ones that do not. Aggressive commits a larger share of RAM so bigger models can load. When a load is refused, the README points at the model manager rather than an error dialog. That is a coherent design: the user is told which model is holding the memory instead of being told the load failed.
The rest of the suite sits on top of that same runtime. Tool calling runs an automatic loop with runaway prevention and exposes web search, calculator, date/time, device info and knowledge base search. The knowledge base chunks uploaded PDFs and text, embeds them on-device with a bundled MiniLM model, and retrieves by cosine similarity out of local SQLite, with the search_knowledge_base tool added automatically in project conversations. Remote servers are a separate path: any OpenAI-compatible server on the local network, discovered models, SSE streaming, API keys in the system keychain.
Getting it running: app stores first, source build second
The README's install path is the stores. The Google Play listing is under the package id ai.offgridmobile and the App Store listing is titled Off Grid Local AI. The README also points to a separate Off Grid AI Desktop repository for macOS, and states that one Pro licence covers both the phone and the Mac.
What the README does not give is a build recipe. There is no documented install command, no clone-and-run sequence, no environment file, and no list of required SDK versions in the supplied material. The repository is TypeScript with a src/assets directory holding the logo and the Wednesday Solutions branding, so it is a React Native style project, but the exact build steps are not in the text I have. If you intend to build from source rather than install from a store, treat that as unverified and read the repository directly.
The settings that are named in the README are the ones worth knowing before you start: the backend override in Settings, and the Model Loading policy (Lean, Balanced, Aggressive). The Pro tier adds on-device Kokoro text-to-speech for voice mode, custom personas with their own system prompt, voice and persistent memory, draft-then-approve actions against Calendar, email and MCP servers such as Linear, Notion and GitHub, and Personal Mesh sync between phone and Mac over your own network with no relay. Pricing stated in the README is $69 lifetime or $49 per year, with the lifetime price described as rising as more people join.
Quantization is a correctness issue here, not a tuning knob
The clearest limitation in the material is the NPU path. A K-quant falls back to CPU silently. Silent fallback is the worst kind of failure for a performance feature, because the user sees slower generation and has no signal that the accelerator was skipped. The model list badges are the compensating control, and they only help if you check them before downloading.
There is a second, broader limit that follows from the architecture. Everything runs in the app's process on the device, so the ceiling on model size is the device's RAM, not the model's quality. The Aggressive policy commits a larger share of RAM, which is a trade against the rest of the phone. The README does not state what happens to other applications when that policy is active, and I cannot confirm it from the material.
The third limit is scope. The README quotes roughly 7 seconds for vision responses and 5 to 10 seconds per image for NPU-accelerated Stable Diffusion on Snapdragon, with Core ML on iOS. Those are interactive numbers, not batch numbers. Someone generating fifty images, or running a long document pipeline, is on the wrong tool. The knowledge base is also described as PDF and text upload with MiniLM embeddings, which is a small retrieval setup, not a document platform.
Where it sits against llama.cpp and Ollama
The honest comparison is with llama.cpp and its wrappers, because OGAM is built around GGUF and the README's own remote-server feature targets Ollama, LM Studio and LocalAI. The difference in approach is packaging and lifecycle. llama.cpp gives you a library and binaries with no opinion about what is resident on your phone. Ollama gives you a server process with a model store and an HTTP API. OGAM gives you an application that decides which backend to use, tracks RAM per model, and exposes an eject control, at the cost of being an app rather than a service you can script against.
That trade matters in both directions. If you want to call a model from your own code on the same machine, OGAM's own remote-server support is the path: point it at Ollama or LM Studio on the local network. If you want to embed inference in another mobile app, llama.cpp is the dependency and OGAM is not, since the README describes an end-user application with store listings rather than a published SDK.
Maintenance surface and what the MIT licence covers
The release cadence in the repository metadata is fast and beta-heavy. v0.0.107 landed on 2026-08-21, preceded the same day by v0.0.107-beta.1 and v0.0.106-beta.1, and the last push to main is dated 2026-09-10. A 0.0.x version series with frequent beta tags means the API surface and the model compatibility matrix can move between releases. For a user installing from a store, that is mostly invisible. For anyone building from source or pinning a version, it means the backend support list and the quant compatibility notes should be re-read at each upgrade rather than assumed stable.
The repository is MIT licensed. The Pro features described in the README (Kokoro voice, personas, draft-and-approve connectors, Personal Mesh sync) are sold separately at $69 lifetime or $49 per year. The supplied material does not state which parts of the codebase are MIT and which are gated behind the paid tier, and it does not describe the licence of the bundled models such as MiniLM or the Stable Diffusion checkpoints. Those are separate licences from the application licence, and they are the first thing to check if you plan to redistribute anything. I am not giving legal advice here; the point is that an MIT badge on the repository does not automatically cover every artifact the app downloads or bundles.
Who this is for, and the three checks before you commit
Take it if you want a single MIT-licensed app on Android, iOS or macOS that runs GGUF text models, Whisper transcription, Stable Diffusion and vision models on-device, and you value the RAM visibility and the per-model eject more than you value having a scriptable server. The privacy claim in the README is structural rather than a policy promise: models run locally, and the remote-server option is explicitly local-network, so nothing routes through a vendor endpoint by default.
Skip it if you need a headless inference service, a batch image pipeline, or an embeddable library. Skip it too if your device is not on the supported backend list, because the fallback is CPU and the throughput difference between 15 to 30 tok/s on CPU and 20 to 40 on an Adreno GPU is the difference between usable and not.
Before installing, check three specific things. First, confirm your chipset against the backend list, since Adreno OpenCL and Apple Metal are named and the Hexagon NPU is flagged experimental. Second, if you want NPU acceleration, confirm the model you intend to download ships as Q4_0 or Q8_0, because a K-quant falls back to CPU without telling you. Third, decide your Model Loading policy up front: Lean if you switch between models often, Aggressive only if you accept that the app is committing a larger share of device RAM. The README's own warning is the one to keep in mind: a 4GB model does not politely share memory.
Editorial conclusion
Adopt Off Grid AI if you want an MIT-licensed mobile app that runs GGUF, Whisper and Stable Diffusion on-device with a visible RAM budget, and if you are willing to choose your quant to match the backend. Do not adopt it as a headless inference server or as a replacement for a desktop toolchain. Verify three things first: whether your exact device appears in the supported backend list, whether the quant you intend to run is Q4_0 or Q8_0 if you want NPU acceleration, and whether the MIT licence covers the components you plan to redistribute, since the Pro voice, persona and mesh features sit behind a separate paid tier.
Community notes