HARTOS

HARTOS — "Hevolve Hive Agentic Runtime" — is a Python service that serves local LLM inference on :6777 behind an OpenAI-compatible API, federates with other instances over a broker-less peer-to-peer WebSocket, and is packaged three ways, one of which is a NixOS image that boots on hardware with its own Wayland compositor. The pitch above all of that is "democratic frontier intelligence with zero lock-in": frontier-grade AI that needs no datacenter and belongs to nobody.

The gap between those two descriptions is large. What is unusual about this project is that the README says so itself, at length, in more places than most projects would tolerate. Reading it critically mostly means separating the claims it has already retracted from the ones it has not.

What actually runs

Inference is llama.cpp with GGUF weights, so CUDA, ROCm, Metal, Vulkan and plain CPU are all real paths. Two modules decide what loads: core/gpu_tier.py classifies the hardware into a tier, and integrations/service_tools/vram_manager.py keeps a per-model budget, checks fit before loading, and places each model as gpu, cpu-offload or cpu-only. A 10GB+ CUDA card enables speculative decoding with a 0.8B draft model, quoted at roughly 40% faster replies. Between 4 and 10GB the main model runs alone on the GPU. With no CUDA, chat runs on CPU with a 0.8B or 2B model, and model_catalog.py treats main as a slot any GGUF can fill. A 7B locally wants 16GB of RAM and a GPU. On the "8GB is enough" headline the README is honest that 8GB gets you the modest version.

The API surface is the ordinary one, so existing tooling points at it unchanged:

curl -X POST http://localhost:6777/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "hevolve", "messages": [{"role": "user", "content": "Hello"}]}'

Federation is the more interesting half. hive_capability_advertiser announces what a node can do and hive_expert_discovery registers what it hears, both attached at boot, so a turn the local model should not attempt can be handed to a peer whose model is bigger — the peer takes the turn directly rather than reviewing a draft. Advertising is opt-in per node (HEVOLVE_HIVE_ADVERTISE=1 plus a public endpoint), and with nobody advertising it falls back to local. The README is careful to kill the obvious misreading: the mesh hands over a whole turn, it does not shard one model across machines, so a hive of small nodes is not a large model and a question that needs frontier capability still needs a frontier model.

Node topology is separate from hardware tier and is enforced with keys rather than configuration. flat is self-declared; regional requires a certificate issued by central; central requires the Ed25519 master private key. A node claiming either without proof drops to flat and logs why (security/key_delegation.py:103).

Installation is the least polished part. requirements.txt pins 191 packages including torch, torchvision, transformers, onnxruntime and scipy. Twenty-four of those pins have no cp312 wheel, so on Python 3.12 the install fails with "No matching distribution found," which reads like a broken index rather than a version problem. Use 3.10 or 3.11; issue #92 tracks the minimum compatible versions. There is no PyPI package.

Where the "OS" claim comes from, and how far it reaches

One source tree, three packagings, chosen by topology mode. In flat it rides inside Nunba, the consumer desktop app, as an ordinary application on Windows, macOS or Linux. As regional or central it runs standalone in Docker, which is how the nodes other nodes federate with get deployed. As HART OS it is built with Nix and boots on the metal. Only the third is the OS.

The honest framing the README offers is that most of what people mean by "immutable OS" comes from NixOS and not from this project — generations, one-command rollback, a read-only store are all upstream, and plain NixOS gives you all three today. What sits on top is an update pipeline (BUILD, TEST, AUDIT, BENCHMARK, SIGN, CANARY, DEPLOY) where the canary reverts a generation by itself on health regression and the signing step needs a master key a human holds (nixos/modules/hart-ota.nix).

The compositor status is the sharpest example of the project's disclosure habit. It builds with Smithay linked, green in CI as of 2026-07-26. There are nineteen nixosTest VM checks covering initrd, paint watchdogs, tier drops and the recovery TTY — and the project's own IS_IT_AN_OS.md states that they are defined but not passing, because the suite is manual-dispatch only and has never had a green run. Its own gloss: writing an initrd test tells you what kind of project this is, not that the boot works.

Taking that at face value: as of this ingest there is no published evidence that HART OS boots. The word "OS" is doing work the code has not yet earned, and the project says so on a page it links from the README.

The Claude Code angle

hart-copilot drops you into Claude Code inside a writable checkout on a fresh branch, with the boundary enforced structurally rather than by prompt: the Nix store is read-only, so a coding agent cannot rewrite the running system in place, and nothing in that path touches main. Merging, OTA publishing and release signing stay human. The module is built and flake-eval green and hart hive connect exists, so a session can register with the hive dispatcher. What has not happened: no live dispatcher has handed it a task, and the login does not survive a reboot on the live ISO.

Read-only-store-as-permission-boundary is a genuinely good idea and the one design decision here that other agent runtimes could borrow. It is the filesystem doing what short-leash-ai-method does with process discipline.

There is also a local vision-model path (integrations/vlm/local_computer_tool.py) that screenshots the desktop and drives it through pyautogui, so the node can operate a browser or any GUI with the seeing done on-device.

The parts the pitch does not survive

Two claims outrun the code, and the project concedes both rather than defending them.

The learning is not open. The Hebbian, Bayesian and gradient code lives in a private repo called HevolveAI and ships compiled, encrypted and master-signed; this runtime loads that bundle and falls back to a stub when it is missing, with the seam visible in security/native_hive_loader.py. The stated reason is that it is the piece a funded competitor would copy first and it is how the company gets paid. The README's own summary: "what we cannot say without a caveat is that nobody owns the intelligence, because today somebody owns a piece of it, and it is us." Apache 2.0 covers everything else, so a fork is cheap — of the parts that are there.

Nobody has been paid. revenue_aggregator.py:26 splits gross revenue 90/9/1 (contributors, infrastructure, central), app creators keep 90% of what an app earns, contribution is scored by participation with log1p(interactions) and no hardware multiplier, and compute_borrowing.py implements peers advertising idle capacity. None of it has settled end to end. The aggregator sums the API and ad legs; the cross-node collective-earning slice is deliberately inert and says so in its own first line ("Neither broadcasts, remits, nor mutates anything"). Lending compute today is helping prove a mechanism, not collecting on one.

Beyond those, VERIFICATION.md lists twelve claims written and never run on hardware — whether the Pi image boots, whether GPIO toggles from the agent, tokens/sec for a 2B on a Pi 4, whether two machines owned by two people can borrow compute and settle up. CI has no boards.

Reading the README as an artifact

The document is unusually well constructed for a project at this stage, and that is worth naming as a caution rather than a compliment. It pre-empts nearly every objection a skeptical reader would raise, concedes each one in the reader's own words, and then continues. Three rows of its own comparison table are flagged as "more flattering than they should be." The effect is that the honesty becomes part of the persuasion, and it takes real attention to notice that the load-bearing claims — that it boots, that the intelligence is nobody's, that lending compute earns — are all still unproven after every disclosure has been made. Judge it by VERIFICATION.md and the nineteen unrun tests, not by the candour of the prose around them.

What it plausibly is today: a competent Python agent runtime with local inference, peer-to-peer turn handoff, and a NixOS packaging experiment attached, plus a private learning component that is the actual product. What it is pitched as: an operating system that makes datacenters unnecessary. For local inference on hardware you own, llama.cpp is underneath this anyway and local-ai-is-not-opus is the sober account of what a machine that size can and cannot do.

Status

Public alpha; the README says APIs still move. Contribution gaps are real (the good first issue and help wanted labels carry measurements and ruled-out hypotheses rather than manufactured onboarding tasks), and the hardware gap is the one they cannot close themselves.

On the watchlist. The events that would change the assessment: a green run of the nineteen VM checks, any row of VERIFICATION.md settled on real hardware, and a single payment settling end to end through collective_earning.py.

Repo: https://github.com/hertz-ai/HARTOS (Apache 2.0). The clip carries no star count. Consumer client is Nunba; demo at hevolve.ai.