A local assistant for Home Assistant, built on Qwen3-14B-Base. It turns plain requests into service calls, builds automations, answers questions about the home, asks when a request is ambiguous, and looks up documentation with citations — entirely on the hub. No cloud, no account, no telemetry.

This is the larger of the two Selora AI lines. The 1.7B line lives at selorahomes/Selora-AI and runs on far less memory. This model needs about 16 GB of RAM.

One shared base plus five small task adapters, served by llama.cpp with the adapter selected per request:

Five specialists share one base, so the whole set costs 9.6 GB of memory rather than five separate models.

llama-server -m qwen3_14b_base.Q5_K_S.gguf \
  --lora selora-answer.lora.gguf \
  --lora selora-clarification.lora.gguf \
  --lora selora-automation.lora.gguf \
  --lora selora-utilities.lora.gguf \
  --lora selora-command.lora.gguf \
  -c 4096 -np 1

Adapter slot ids follow the order of the --lora flags. Resolve them by filename from /lora-adapters rather than assuming a fixed order.

llama.cpp — the default. One base plus five adapters, selected per request. Every number on this card below is this configuration unless marked otherwise.

Ollama — the Advanced tier. A single merged model, selora-ollama.Q5_K_S.gguf, with all five specialists fused into one set of weights and the routing decision made by the model itself. Simpler to deploy: one file, one ollama create.

The merged model trails the five specialists on one surface, and the card says so plainly: when a request is ambiguous, it acts instead of asking about half the time (54.5% routing accuracy on clarification cases, against the clarification specialist asking reliably). On a Selora-authored 262-case behavioural set scored identically for both, the merged model reaches 69.5% against the specialists' 82.8%; 47 of its 80 misses are routing rather than content. It passes every pre-registered integration gate (18/18 turns through Home Assistant in the 15 GB sim, median 8.9 s, zero 500s), and multi-device commands actuate every target. Choose it for deployment simplicity; choose the adapters when asking-before-acting matters — locks and alarms in particular.

The Modelfile pins a chat template matching the training prompt byte-for-byte. Ollama renders the template embedded in the GGUF and ignores the Modelfile's own; the shipped GGUF carries the corrected one. Third-party benchmarks for this tier are in the table below, beside the specialists.

Measured with adapters, KV cache and Home Assistant running alongside, inside a 15 GB hub:

Q6_K is a little more accurate on some suites. Q5_K_S is the one that leaves room for the KV cache to grow on a large home — Home Assistant's own analytics put the average install near 386 entities.

Measured through the Home Assistant integration in a 15 GB simulated hub at the shipping quant — not against the model in isolation.

Response time is dominated by prompt ingest, so it scales with how many entities a home exposes. The simulated home here is small (about 20 entities); a real home will be slower in proportion.

Measured on the exact weights in this repository, under each suite's own published protocol, temperature 0, on Apple Silicon (Metal) at the shipping quant. Each adapter is addressed by name from the server's /lora-adapters listing. The Ollama tier is measured separately below.

HomeBench by group, upstream scorer:

HomeBench multi-device, F1 partial credit (Selora-defined slice):

HomeBench improved from 0.0% to 30.2% in this build by teaching the model the suite's output contract, which the training data had never contained — every prior output wrapped its operation in quotes the scorer could not read. Two gaps remain and are located: on requests naming several absent items the model refuses once rather than once per item, and "this device has no such setting" is read far worse than "no such device".

Allen automations is four scenarios, each sampled five times at temperature 0, so it moves in 25-point steps. Three pass. The one that fails does so on a single malformed key — a trigger's id: placed on an action step — which Home Assistant's loader rejects. Two earlier defects (a missing turn-off action; a double-wrapped blueprint input) were fixed in this build and are confirmed closed at the loader.

Allen questions is bounded by data, not capability: 17 of its 38 cases have answers that live only in entity attributes the model is never shown, so the achievable ceiling is about 55%. Of the 21 misses, 16 are the model declining.

acon96 has no published scoring harness, so that row is scored by our own translation and labelled as such.

The merged model, measured the same way, beside the specialists:

Why the merged model trails. It was fused from the training corpus one generation before the command and automation fixes in this release, so it still carries the HomeBench quote-wrapping (99% of outputs) and the two blueprint defects the adapters no longer have — all four automation scenarios produced valid YAML that Home Assistant rejected on exactly those defects. The remaining gap on assist and intents is the act-vs-ask boundary: on HA intents, 63 of its 90 misses are the model asking a clarifying question where a command was wanted. No third-party suite here measures clarification or documentation lookup directly, so the table understates the difference on asking-before- acting, which is where the specialists are strongest.

One caveat on all of the above: measured on Metal. On one sampled case the same weights at the same quant produced a different numeric parameter on CPU than on Metal at temperature 0. The hub runs CPU.

Apache 2.0, inherited from Qwen3-14B-Base.