Ollaya returns decisions without writing an answer
A refund request doesn't always need a chatbot reply. Sometimes your application needs a billing label and a flag saying a customer might leave. Ollaya accepts that message, your questions, and the allowed answers, then returns scores and probabilities. Its README's triage example makes the distinction clear: the model chooses among outcomes instead of composing text that your code must parse.
That is a useful boundary for a local service. The CLI downloads named models and manages a daemon, while Modelfiles can attach a saved question set to a model. Our checkout contained 833 files and about 76,529 source lines in 10.8 MB. The small checkout shouldn't obscure the scope: Rust crates cover the registry, scheduling, question formats, and different inference engines. Adopting the daemon also means adopting those runtime choices.
What happened when we ran it
Our run installed Ollaya commit ef448f7 in 10 seconds, adding 328 packages, but the build failed after 150 seconds with exit 101. We used a fresh Debian sandbox on October 15, 2026, with 3 CPUs and 12 GB of RAM, image lab-rust:1, no secrets, and no elevated privileges. Installation succeeded. We never reached a working binary through that build, so these results cannot establish inference speed or decision accuracy.
The linker reported undefined C++ symbols, including a wide-string _M_replace_cold function. The tail also names object files associated with ONNX Runtime and Abseil, followed by collect2: error: ld returned 1 exit status. That shows where the command stopped. It doesn't identify which library or toolchain change would fix it, and it gives us no basis for prescribing a missing system package.
The test command failed after 49 seconds with exit 101 and the same linker problem. This was a failure to produce the binary, so there is no passing test count to report and no evidence here of an assertion failing. Our scan found 3 CI workflow files and a Dockerfile, but no tests directory. That directory check alone says nothing about tests embedded in Rust modules. The supplied run simply couldn't get past linking.
Existing TypeSafe clients can keep their request format
Ollaya implements TypeSafe's /v1/systemone format, and the README documents switching an existing client through TYPESAFE_BASE_URL. Its native /api/decide adds routing information. You can ask for a choice among named categories, a graded score, or a yes-or-no decision. For an application already expressing work that way, preserving the request contract is a stronger reason to try Ollaya than collecting another model server.
The API security documentation says authentication is off by default and the daemon binds to loopback. Set OLLAYA_API_KEY before allowing other machines to reach it. Public weights don't require a hosted inference subscription, while private or gated Hugging Face downloads can need a token. None of that was exercised by our failed 150-second build. Treat network configuration and model access as separate acceptance checks after obtaining a working runtime.
CPU and GPU support depends on the model family
Our sandbox had 3 CPUs and 12 GB of RAM, but the linker failure prevented any finding about how well a model fits that machine. The README directs users without an NVIDIA GPU toward Laya. ONNX models use ONNX Runtime, while GGUF models use llama.cpp. The hardware choices differ between those engines, so a claim that Ollaya supports your operating system isn't enough to select a model and acceleration path.
Linux downloads require glibc 2.38 or newer according to the README. Apple silicon has a macOS path, and Windows has separate GPU considerations, including Vulkan for GGUF models. Docker has CPU and CUDA variants. Those are documented distribution options, not successful paths from our run. If you need to compile changes inside a standard Debian image, resolve the demonstrated linker failure before making this service a dependency of your application.
Model downloads retain their own licensing conditions
Apache-2.0 covers Ollaya's code, while model weights keep their authors' licenses. The README explicitly separates those terms and identifies restrictions for particular families. It also says weight downloads are pinned to commits and checked by hash. That helps explain which artifact you received, but it doesn't grant permission to use every model under the runtime's license. Read the selected model's terms before committing to a deployment.
The 328-package install measured repository preparation, not a complete cache of inference weights. Ollaya fetches those from the authors' repositories, so an offline deployment needs its artifacts prepared separately. Release v0.13.0 adds pulls by manifest digest, a useful control when names can move. Its release notes also warn that pinning a router manifest doesn't pin the models it routes to. Pin the answering model directly when repeatability matters.
October maintenance is active, with model support still selective
The last push was October 14, 2026, following the October 13 release of v0.13.0. GitHub showed 1,312 stars and 5 open issues and PRs combined. Recent issue activity includes model requests and a closed CUDA decoder failure addressed in that release. Those are signs of ongoing work. They don't make our source build pass or establish that a particular model behaves correctly on your hardware.
Choose Ollaya when a local typed-decision API matches your application and you can own runtime validation. Snap is another Jev-compatible decision engine worth comparing. Ollama suits a broader local chat workload, while Text Embeddings Inference fits embedding or supported classification services. Our 150-second build ended at the linker: before trusting Ollaya with ticket routing, require a working artifact and check its decisions against tickets your team has already labelled.