HomeGenie: nine downloads, and the GPU question they hide

Your build variant decides whether your GPU is used

Installation here is not a package manager and not a container. You pick an archive from a table of nine and unzip it. The table has three dimensions: platform, architecture, and hardware acceleration, and the variant suffix is the whole decision. Windows, Linux and Raspberry Pi each offer a standard CPU-only build, a `cuda12` build for NVIDIA, and a `vulkan` build for everyone else. macOS has exactly one entry, `osx-x64`, which the table says covers both Intel and Apple Silicon through Metal. The guidance underneath is explicit about who should pick what: NVIDIA users take `cuda12` for the best language-model and vision performance and need reasonably current drivers; AMD, Intel and Windows users take `vulkan`; macOS users take `osx-x64`; headless servers and older PCs take the unsuffixed standard builds as the most stable and lightweight; Raspberry Pi 3, 4, 5 and Zero 2 take `linux-arm64` while the Pi 2 takes the legacy 32-bit `linux-arm`. Nine archives for one application is an unusual distribution shape, and it exists because the accelerator choice cannot be detected reliably at install time.

The Linux Vulkan build has no GPU vision path

Read the Linux Vulkan row carefully, because it is where the two acceleration paths come apart. On Windows, the `win-x64-vulkan` build runs the language model through Vulkan and vision through DirectX 12 via DirectML, so an AMD or Intel card does both jobs. The Linux Vulkan row says the language model runs via Vulkan and vision via the CPU, with the note that there is no DirectML on Linux. So on a Linux box with an AMD GPU, object detection, instance segmentation and pose estimation all fall back to the processor while the language model still gets the GPU. For a platform whose vision suite includes YOLO across ESP32-CAM modules and generic IP cameras, that is the single most consequential line in the installation guide, and it is easy to miss because the variant is named the same on both operating systems. If your plan is camera-based detection on Linux with a non-NVIDIA card, the `cuda12` path is unavailable to you and the Vulkan path will not do what its Windows counterpart does.

Raspberry Pi gets a CPU-only build

The ARM rows are described as optimised for 64-bit ARM SoCs and CPU-based, which for a platform whose headline feature is that it runs language models on your own server means the language model runs on the Pi's CPU. The Pi 3, 4, 5 and Zero 2 are mapped to `linux-arm64`, and the Pi 2 gets the legacy 32-bit build. So the promise of local agentic AI holds on a Pi in the sense that nothing leaves the house, and not in the sense that anything is fast. That is a reasonable target for voice control and rule-based automation, which is what the scheduler and the visual editor are built around. It is not a target for running a vision model over a camera feed on the Pi itself, since those are CPU tasks with no accelerator behind them. Worth noting also that the Pi 3 sits in the 64-bit row, so a Pi 3 still running a 32-bit Raspberry Pi OS needs the older `linux-arm` archive instead.

You install a binary rather than building one

After unzipping you will find a `homegenie` directory holding the application binaries and a startup script for your operating system. On Windows you double-click `start.bat`, on macOS `start.command`, and on Linux or a Raspberry Pi you run `./start.sh` from the terminal, or double-click it if your file manager executes shell scripts. To stop it, press CTRL+C in the terminal window. There is a `HomeGenie.sln` and a `src/` directory in the tree, so the source is there, but the visible documentation describes no build-your-own step and no container image, and the top level has no Dockerfile. The distribution is therefore prebuilt binaries per platform and accelerator, which is friendly for a Raspberry Pi user and awkward for anyone who wants a reproducible image to run on their own hardware. There is a configuration backup feature and a package repository in the extensibility list, so configuration is portable even when the binary is not.

Local agentic AI names where inference runs, not which model

The phrase in the repository description is 100% Local Agentic AI, and the feature list expands it as running state-of-the-art LLMs directly on your HomeGenie server for autonomous reasoning, context awareness and natural language control, ending with the line that your data stays private and your intelligence stays local. Read precisely, that is a statement about deployment topology rather than about model choice. The visible documentation does not say which models are bundled, which are downloadable, or what the hardware floor is for a given model. The vision suite is named more concretely, since it lists YOLO for object detection, instance segmentation and pose estimation running on the server, on ESP32-CAM modules, and on generic IP cameras. Two things follow for an evaluator: the privacy claim depends on the model actually being local, and the practical performance depends entirely on the accelerator variant, so both need checking against your hardware before the promise means anything.

Three API languages behind a Visual Studio solution

The repository is labelled JavaScript, and the root holds a Visual Studio solution file, which together suggest a .NET service with a web front end. The universality claim is about programmability rather than implementation, and it is genuinely three-way: the API is described as fluent and programmable in C#, JavaScript and Python, for writing custom programs and widgets with full developer tools. The widget story is the most concrete part, a built-in editor for creating and customising dashboard widgets with HTML, JavaScript and CSS, which means the extension surface for display is just a browser. The scheduler sits alongside and accepts extended cron expressions plus variables and conditions, and adds AI-driven natural language tasks, so a routine can be written as a schedule, as a condition, or as a sentence. The protocol list is what makes this a whole-house platform rather than a bridge: X10, Z-Wave, ZigBee, GPIO, SPI, I2C, and IR/RF, plus ESP32 hardware repurposed as smart displays or as AI-powered FPV robotic platforms. The UI is stated to support more than ninety languages, with voice control integrated.

AGPL-3.0, weekly releases, then four months of quiet

The licence is AGPL-3.0, with a `NOTICE` file alongside it at the repository root. For a system intended to run on your own hardware and stay private that is a defensible choice, and it is the kind of thing worth routing past a legal review if you intend to modify and redistribute rather than merely run. Release cadence was brisk and then stopped: v2.0.22 on 2026-05-12, v2.0.23 on 2026-05-24 and v2.0.24 on 2026-05-31, roughly weekly across May. The last push to the default branch, master, was on 2026-05-31, the same day as the newest release, so the tree and the newest tag agree. The project is not marked archived. The homepage is homegenie.it and the documentation lives at genielabs.github.io/HomeGenie, with an image gallery under `docs/` and a separate wiki link, so the code, the manual and the community documentation are three different places to look.

Editorial conclusion

Adopt HomeGenie if you want local language-model and vision control over real hardware, you can pick the archive matching your accelerator, and AGPL-3.0 suits a system you host yourself. Do not adopt it expecting a reproducible build or a container from the documented path, because installation is a prebuilt archive you unzip and run. Do not choose the Linux Vulkan build if your use case is camera-based vision, since vision there falls back to the CPU. Verify first which variant your GPU needs, since choosing wrong costs you either acceleration or the stability the standard build was chosen for.

Frequently asked questions

Official sources

1. genielabs/HomeGenie on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases