By 19:30 UTC on September 25, Ollaya's launch had drawn 414 points and 114 comments on Hacker News. Its GitHub repository still showed 197 stars the next day. That gap points to the idea attracting more attention than the code itself: developers want a small local service that turns messy text or JSON into typed answers without waiting for a chat model to write prose.
Ollaya packages that service in an Ollama-like command line and daemon. A request supplies some state, such as an email or support ticket, plus questions with bounded answer types. The model returns a choice, score, or yes/no probability in one forward pass. It does not generate an explanation.
What Ollaya actually ships
Ollaya does not train a single flagship model. Its catalog currently lists seven model families, including Laya, Mapika's Decider, zero-shot NLI models, GLiClass, Qwen3Guard, Kev, and Von. Ollaya downloads the chosen weights, starts a local runner, and exposes one interface across them. The familiar commands are deliberate: pull, run, serve, list, show, and rm mirror the vocabulary that made Ollama easy to approach.
The abstraction matters because these models do not all work the same way. Laya uses encoder models for typed decisions. Decider reads option-letter logits from Qwen3.5-based models. The NLI family turns each option into a hypothesis and scores entailment. Ollaya hides those mechanics behind the same question schema, while its model page still exposes size, latency, and an accuracy result for each family.
A basic migration from TypeSafe's hosted Jev API can be as small as changing environment variables. Ollaya says the official TypeSafe Python SDK 0.7.1 works against its local server without code changes:
export TYPESAFE_BASE_URL=http://localhost:11435
export TYPESAFE_API_KEY=local
export TYPESAFE_DEFAULT_MODEL=laya
The compatible endpoints are /v1/systemone and /v1/models. Ollaya also has its own /api/decide endpoint with routing and timing data, according to the project README. This makes the runtime useful even if a team later changes the model behind a stable application contract.
The API arrived eleven days after Jev
TypeSafe introduced Jev on September 15 as an early-access "System One" model for fast, probabilistic decisions inside software. The company says Jev gives up string generation in exchange for structured output and much lower latency. Those are TypeSafe's own product claims, laid out in its launch post, rather than independent measurements.
Ollaya's attention eleven days later shows how quickly an interface can become a community target. The Hacker News discussion spent much of its energy arguing over whether "decision model" describes a new category or a well-packaged form of classification. Other commenters asked why Ollama could not add the same model support. That thread establishes interest and skepticism. It does not establish that Ollaya's models match Jev.
The maintainer's own documentation is more restrained than the launch chatter. Ollaya's FAQ says its small encoder models fall well below Jev on harder questions, while Decider is more accurate and slower. It also says that a trained classifier is usually the better option when a team has labelled data for one fixed task. Ollaya is aimed at the space between a hand-built classifier and a general chat model: changing questions, limited labels, and an application that needs an answer in a predictable shape.
Milliseconds do not settle the quality question
On an RTX 4090, Ollaya reports a median of 8 to 10 milliseconds for a five-question request using its Laya models. GLiClass takes 14.7 milliseconds in the same setup, NLI takes 20.4 milliseconds, and the larger Decider model takes 190 milliseconds. The homepage publishes the hardware and precision details and warns that its comparison with hosted Jev includes network time, so the rows are not a controlled head-to-head benchmark.
Its accuracy table deserves the same care. On Ollaya's 400-state typed-decisions set, Laya's default model scores 0.361 and Decider scores 0.591. The model catalog says those labels have low annotator agreement and should be used to compare the listed models, not read as absolute measures of correctness. Fast inference only becomes useful after the selected model survives an evaluation built from the application's own traffic.
That caveat is especially important for probabilities. A result such as refund_requested: 0.88 looks ready for a threshold, but a number can be precise and still be poorly calibrated for a new domain. Ollaya applies temperature scaling by question type and option count. Its Modelfile format can refit that calibration on labelled examples, and the FAQ explicitly recommends doing so for thresholds a team will rely on.
The absence of generated prose removes one common failure: code no longer has to parse a sentence that ignored the requested schema. It does not remove wrong classification. A local model can confidently route a ticket to the wrong queue or approve an unsafe action. The useful operational change is narrower output with measurable error, provided the team records decisions and checks them against later outcomes.
Local inference changes the deployment tradeoff
Ollaya listens on 127.0.0.1:11435 by default. Its documentation says states and questions are never logged, and the network is used only when models are pulled. That is a practical fit for support tickets, internal email, or agent state that a developer would rather keep away from a hosted inference API. The FAQ documents those defaults, though teams that expose the service beyond localhost still need to configure authentication and network controls for their own environment.
The model supply path is also visible. Ollaya fetches weights from each author's Hugging Face repository, pins them to a commit, and verifies every file with SHA-256. The project publishes small derived ONNX graphs rather than rehosting the weights. Each model keeps its upstream license, while the Ollaya runtime itself uses Apache 2.0, according to the repository.
Agent developers get another route into the service. ollaya mcp exposes decisions to MCP clients, and the project includes an agent skill describing when to call a decision model. The useful split is easy to picture: a larger model can plan or interpret an open-ended request, then a smaller local model can repeatedly score bounded actions. Ollaya's homepage demonstrates that pattern with an agent command evaluated for task fit, risk, and destructiveness.
The beta still has a narrow hardware lane
The one-command pitch has firm platform limits. Native Linux builds require glibc 2.38 or newer. NVIDIA acceleration needs an R580 or newer driver with CUDA 13. Apple silicon runs on the CPU, as do Intel and AMD GPUs. Windows has a CPU build, while NVIDIA users are directed to WSL 2. Docker images cover Linux on x86-64 and Arm64, with a separate CUDA image for x86-64. These constraints are listed on Ollaya's download page.
The repository also remains young in visible project terms. GitHub showed 67 commits, three open issues, and ten forks when checked for this article. The roadmap on the project page still lists GGUF models through llama.cpp as planned. A desktop app exists for the major desktop systems, but the fastest published figures come from one high-end NVIDIA card. CPU latency on ordinary developer machines will matter more to many prospective users.
Ollaya's name and command design invite an obvious question: why should this stay separate from Ollama, vLLM, or another inference server? The project says it is independent and unaffiliated with Ollama. Its immediate answer is Jev wire compatibility plus a registry built around typed decisions. That advantage could shrink if larger runtimes adopt the same endpoints, a possibility raised repeatedly in the Hacker News thread.
Accuracy will decide whether it sticks
The next useful evidence will come from application-specific evaluations, not another latency chart. Watch whether users publish labelled tests that compare Ollaya's seven families on the same tickets, moderation cases, or agent actions, and whether calibration holds after the input distribution changes. Also watch the interface: if other local runtimes adopt the same request shape, Ollaya's lasting contribution may be the model registry and compatibility work. If they do not, its 414-point launch will remain a sharp signal that developers saw a missing piece, then waited for the error rates to justify installing it.