Local decision models and their runtimes
Local decision models run through different runtimes. Start with your machine and the model’s loading code: MLX, ONNX and GGUF packages need the runtime that understands their decision outputs.
Apple Silicon: Laya or a d1 integration
laya-mlx runs Laya natively through MLX, without PyTorch or a cloud API. Its Snake demo includes a safety layer that can override a model move. For an OpenClaw agent, openclaw-d1-local loads LiquidAI/d1-Omni-2B-MLX-8bit and supplies a native provider plus a bridge for OpenClaw’s TypeSafe integration. Despite its repository name, Kev-claw-decisionmaking loads d1-Omni. These are different integration routes, so use the instructions for the specific model and application.
Browser: Laya or SemIf
Laya in the browser uses ONNX Runtime Web, with WASM on CPU by default. It downloads the model before local inference. SemIf uses pinned GGUF builds through wllama and reads option logits. SemIf reproduces an interface pattern and is independent of TypeSafe; neither route downloads TypeSafe’s private Jev weights. Browser parity and task accuracy answer different questions: Laya’s reported 97.9% top-answer agreement with PyTorch on 48 questions per quantized build does not make those answers correct.
Laya browser project · SemIf model facts
Source: github.com · Source: github.com · Source: github.com
Local HTTP API: Ollama or Noullama
Ollama v0.35 introduced /v1/systemone for choice, yes/no and score questions, with Nimble and Tev1 at launch. Noullama is a desktop runtime that finds decision-model GGUF files, runs them through llama.cpp and serves a local typed-question API. Check each project’s supported models before downloading weights. A GGUF file alone does not establish compatibility with a particular decision head or API.
Ollama runtime facts · Noullama project · Nimble model facts · Tev1 model facts
An ordinary local LLM: decision-cli
decision-cli reads answer-token probabilities from one forward pass of an ordinary MLX model on Apple Silicon. It exposes a CLI, batch mode and a Jev-like API, without fine-tuning. Its published scores use 231 public JevBench questions; they do not establish performance on private workloads or every possible question type.
What the hardware records tell you
VENDOR-REPORTED: openclaw-d1-local uses about 3 GB of resident RAM and takes about 200 ms per warm batch on its author’s M4 Mac mini. laya-mlx reports 13.4 ms median for a short English typed decision and 7.4 ms for its multilingual checkpoint on an M3 Max. These are separate models and workloads, not a speed ranking. Laya’s browser project warns that quantized confidence values are approximate because calibration used the full-precision model. These isolated records cannot tell you whether a particular Q8 file fits a 6 GB GPU at your chosen context and batch size.
OpenClaw’s reported configuration · Laya browser parity checks
Source: github.com · Source: github.com · Source: github.com
Before giving it real work
Choose the route that fits your application, then follow its own repository’s setup and loading instructions. Keep the model revision and runtime version with a small labelled sample of your task. Measure correct answers, errors among accepted answers, latency and peak memory at the context and batch size you expect to use. Recheck after changing precision. This guide identifies documented routes; it does not supply a locally reproduced installation recipe or a memory-sizing calculator.
Evaluate on your own task · Decision models versus classifiers · Compare model access and inputs