LLM-Hub: On-Device Chat, Image, Video and Music Generation on Android and iOS
Local LLM, image&video&music generator, vibecode like cursor with local models on your phone
At a glance
- What is it?
- LLM-Hub is a C++ mobile runtime wrapper that puts LLM chat, Stable Diffusion image generation, Stable Video Diffusion and music generation on the handset, with a Termux-backed autonomous agent on Android. The interesting part is the model-format matrix and the error-correction loop; the weak part is the licence and the patch-release cadence.
- Who is it for?
- Adopt LLM-Hub if you need a single on-device app that covers chat, image, video and music generation and you are willing to accept a non-standard licence and a release stream dominated by iOS SDK patch builds. Do not adopt it if you need a stable, documented plugin API for your own models, or if you are shipping a commercial product whose legal team requires an SPDX-clean licence.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C++, 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 LLM-Hub targets: one binary for four generative modalities on a phone
Most on-device inference projects solve one modality. llama.cpp runs text. whisper.cpp runs speech. Draw Things runs image synthesis. A developer who wants chat plus image plus video plus music on a handset normally assembles four runtimes, four model directories and four sets of memory-management rules. LLM-Hub's README describes a single Android and iOS app that covers all four, with a shared model download and import screen reached through Settings, Download Models. The audience is narrow and specific: mobile developers and technically comfortable users who want generative models running locally, without a server, and who are prepared to import weights themselves. The README states the privacy position directly: 100 percent on-device processing, no accounts, no tracking. That claim is only meaningful if the inference genuinely runs on the device, and the technology list supports it, naming GenieX SDK, MediaPipe, LiteRT, WhisperKit and whisper.cpp rather than a remote endpoint.
Platform split: GenieX and Termux on Android, Run Anywhere and Draw Things on iOS
The architecture is not one engine with two skins. Android is Kotlin plus Jetpack Compose with Material 3, and inference goes through the GenieX SDK for LLM and VLM work, WhisperKit for ASR, with GGUF support on Android routed through GenieX. iOS is Swift plus SwiftUI, and inference goes through the Run Anywhere SDK, which the README says wraps Llama.cpp, plus Draw Things (MediaGenerationKit) for image and video, Apple Foundation Model, and whisper.cpp for transcription. The consequence is that a model format supported on one platform may not load on the other. The README lists importable formats as .task, .litertlm, qnn, .mnn and .gguf, but it does not publish a per-platform compatibility table. That omission matters more than any feature bullet: if you plan to ship the same weights to both stores, you are guessing until you test. The image generator is documented as Stable Diffusion 1.5, the video generator as Stable Video Diffusion on iOS only, and music as SoundGen on Android and Magenta Realtime 2 on iOS. Video generation is an iOS-only feature in the current material.
The Android agent loop and the Termux RUN_COMMAND_SERVICE path
The AI Agent is the most distinctive mechanism in the repository. On Android it drafts shell commands aimed at a Termux environment through the RUN_COMMAND_SERVICE intent interface. The README describes four stages: the LLM generates a command, the user inspects and edits it before execution, output streams into a dark monospace terminal container showing stdout and stderr, and on failure the error log is fed back into the model so it can produce a fix. That last step is the part worth examining. An automatic retry loop that re-injects stderr gives the model a feedback signal, but it also gives it a path to iterate on a command you already approved once. The README says MCP tool calls require user approval before execution, and it says the same about pre-execution editing of shell commands. It does not say the auto-correction loop pauses for a second approval. If you use this on a device that holds real credentials, treat the loop as the risk surface, not the initial prompt. Device function calling sits alongside the terminal path: embedded OpenStreetMap maps, calendar, alarms, flashlight, SMS and email composition, SHA-256 and MD5 hashing, and arithmetic.
Getting it running: store install versus source build
The README gives a three-step quick start. Step one is to download from Google Play (package com.llmhub.llmhub) or the App Store, or to build from source. Step two is Settings, Download Models, then download or import a model. Step three is to select the model and start chatting or generating. Model import accepts .task, .litertlm, qnn, .mnn and .gguf files, and the app can pull weights directly from HuggingFace. If you build from source you are compiling against five external dependencies across two toolchains: GenieX SDK and WhisperKitAndroid on Android, Run Anywhere SDK, MediaGenerationKit and whisper.cpp on iOS. The README does not include build commands, a Gradle or Xcode target list, or a minimum OS version, so a source build is a reading-the-build-files exercise rather than a copy-paste one. The repository description names C++ as the primary language, which is consistent with a native inference core wrapped by Kotlin and Swift layers, but the README's technology section describes the app layers in Kotlin and Swift without mapping which parts are C++. Plan for a native toolchain on both platforms before you commit to a fork.
Where LLM-Hub is the wrong tool
Three cases stand out. First, server-side or batch workloads. Everything here is designed around a single handset, a touch interface and on-device memory budgets. There is no documented headless mode, no CLI, and no batch API. Second, anything requiring a stable extension contract. The README describes features and SDK dependencies but publishes no plugin interface, no model adapter specification and no versioned API surface for third-party tools. If you want to add your own runtime, you are patching the app. Third, memory-constrained devices. The app targets CPU, GPU and NPU acceleration, and the README mentions NPU acceleration for upscaling with RealESRGAN and UltraSharp. It does not publish RAM or storage requirements for any model. Stable Video Diffusion and Stable Diffusion 1.5 are not small, and the README offers no guidance on which devices can hold them. That is a documentation gap, not a defect, but it means you cannot size a deployment from the README alone.
Alternatives and the actual difference in approach
The honest comparison is against assembling the components yourself. llama.cpp gives you a text runtime you can embed, with an explicit build system and a documented quantization story, but it does not give you image, video or music generation, and it does not give you a mobile UI. Draw Things is the closest match on the media side: it is a dedicated image and video generation app, and LLM-Hub uses its MediaGenerationKit on iOS rather than reimplementing it. The difference is scope. Draw Things concentrates on diffusion pipelines and their controls; LLM-Hub spreads across chat, agent tooling, transcription, translation, upscaling and generation, and its README explicitly lists ComfyUI and Draw Things feature parity as a future roadmap item, which is an admission that the media controls are not yet at that level. If your job is image or video generation specifically, the dedicated tool is the better fit today. If your job is a single app where a chat model can also call a camera, a map and a shell, LLM-Hub is the one assembling that combination.
Licence, release cadence and upgrade cost
The repository metadata reports the licence as NOASSERTION, which means GitHub could not match the LICENSE file to a known SPDX identifier. The README uses the phrase open-source and says fully transparent, but a NOASSERTION result is not the same as a recognised licence. Before you ship anything derived from this code, read the LICENSE file itself and decide whether its terms work for your distribution model. This is not legal advice and the terms may be perfectly permissive; the point is that you cannot infer them from the README. The release history raises a second question. The three most recent releases are all named ios-sdk-v0.19.7-patched-v16, v15 and v14, published between May and June 2026, with the repository's last push in September 2026. Three patch revisions of the same iOS SDK version inside a month suggests active maintenance of the iOS integration path, and it also suggests the Android side does not get the same release-tagged treatment. If you depend on iOS behaviour, pin to a specific patched tag rather than tracking main, and expect the patch stream to continue. If you depend on Android, verify what the current build actually corresponds to before you plan an upgrade.
Editorial conclusion
Adopt LLM-Hub if you need a single on-device app that covers chat, image, video and music generation and you are willing to accept a non-standard licence and a release stream dominated by iOS SDK patch builds. Do not adopt it if you need a stable, documented plugin API for your own models, or if you are shipping a commercial product whose legal team requires an SPDX-clean licence. Verify first: open the LICENSE file and confirm the actual terms, check that your target chipset appears in the GenieX or LiteRT support list, and test the Termux RUN_COMMAND_SERVICE intent path on a real device before relying on the agent workflow.
Community notes