coreai-models vs uzu
Apple's official Core AI toolkit: recipes exporting Hugging Face models to .aimodel, PyTorch primitives for authoring, Swift runtime for macOS/iOS apps — plus skills for coding agents. — versus — Rust inference engine for on-device AI on Apple Silicon (Metal, unified memory) with Swift, Python and TS bindings, OpenAI-compatible server and a TypeSafe System One decision-model API.
Both put models inside macOS/iOS apps through a Swift runtime; Apple's Core AI exports Hugging Face models to .aimodel, uzu runs its own Metal engine with a ready model catalog and chat/tool-call API.
| coreai-models | uzu | |
|---|---|---|
| Stars | 2.3k | 3.2k |
| Forks | 252 | 221 |
| Language | Swift | Rust |
| License | BSD-3-Clause | MIT |
| Last activity | yesterday | yesterday |
| Topics | local | local, decision-models |
| Curated connections | 4 | 5 |
coreai-models — the curator's take
The sanctioned path to shipping models inside Mac and iOS apps: export recipes take popular open models to Core AI format, the Swift package handles tokenizers and multi-model pipelines at runtime, and the bundled agent skills teach Claude Code/Codex the framework — Apple shipping skills for coding agents is itself a signal. NOT for experimentation velocity: this is the deploy-in-an-app stack, not the tinker stack (MLX is where Apple-silicon research lives), it requires macOS/iOS 27+ and Xcode 27+, and you're accepting Apple's format and release cadence as your foundation.
uzu — the curator's take
Pick it when you are shipping an iOS/macOS app and want a local LLM embedded in-process — Swift Package, structured output, tool calls, and a cloud fallback through the same API. Not for NVIDIA/Linux serving (Metal and CPU only) or bring-your-own GGUF: models need its own format, converted with lalamo.