Ollaya Is "Ollama for Decision Models" — A Local Runtime, Not a New Model

TypeSafe AI's Jev launched September 15, 2026, and within days the open-source response wasn't one clone — it was six clones in two days, each betting on a different model architecture. Ollaya showed up a little later, and it isn't trying to be model number seven. It's a runtime: a desktop app, CLI, and Docker image that downloads and serves several of those already-existing open decision models — laya, decider, nli, gliclass, kev, von, qwen3guard — behind one local HTTP endpoint that speaks TypeSafe's own API shape. The pitch, stated directly on its landing page, is "run decision models locally... calibrated answers in milliseconds... private, open source, on your own hardware." The more useful framing is the one its own name invites: Ollaya is to decision models what Ollama was to local LLMs.

TL;DR

What Ollaya actually is — and isn't

This distinction matters because the last two weeks of Jev coverage have almost entirely been about individual models: Laya on MLX, Kev's 0.8B/4B/9B family, OpenJev. Ollaya doesn't compete with any of them — it hosts them. The unit of value isn't "a better classifier," it's "one install that gets you seven classifiers behind a consistent API, with a model catalogue you can swap without touching your application code."

That's exactly the shape of Ollama's original pitch for LLMs: nobody remembers Ollama as a model, they remember it as the thing that made ollama run llama3 a one-liner instead of a weekend of manually wiring up llama.cpp, quantization formats, and a serving loop. Ollaya is making the same bet for the decision-model category — small, non-generative classifiers that answer typed questions ("What does the customer want?") rather than generate text.

API compatibility: the actual technical claim

The concrete, verifiable part of Ollaya's pitch is drop-in compatibility with TypeSafe's own SDK. Ollaya serves /v1/systemone and /v1/models using TypeSafe's request and response shapes, and per its own documentation, the official TypeSafe Python SDK 0.7.1 works against it unchanged — you only redirect where it points:

export TYPESAFE_BASE_URL=http://localhost:11435
export TYPESAFE_API_KEY=local  # any value works — a local server doesn't check it

A sample request against /v1/systemone — a typed "choice" question like "What does the customer want?" with criteria invoice, refund, other — returns a choice, a confidence score (Ollaya's example shows 0.9547), the full probability distribution across all options, and, notably, zero output_tokens, since nothing is generated. That's the same output shape as Jev's Choice primitive, covered in how does Jev actually work and what is a System One Model — a calibrated classification, not a completion.

Practically, this means any code already built against the TypeSafe SDK — including the routing patterns in how to integrate Jev into agent pipelines — can be pointed at a local Ollaya server for development, offline testing, or cost reduction, without rewriting the call sites.

The model catalogue

Ollaya doesn't train anything itself; it packages models that already exist in the wild, several of which explainx.ai has covered individually:

Each family covers a different design point on the same trade curve already mapped out in Jev vs. XGBoost and BERT: raw accuracy (decider) versus multilingual breadth (laya) versus long-context handling (von) versus zero-shot flexibility without any fine-tuning (nli, gliclass) versus safety-specific classification (qwen3guard).

Speed: the case Ollaya makes for itself

Ollaya's own published median-latency table, measured end-to-end on a five-question request, is the strongest part of its pitch:

Read that table carefully rather than as a simple "local beats hosted" headline. The fastest entries (laya, gliclass, nli) are genuinely tiny models doing a single forward pass with no network hop — an order of magnitude faster than the hosted API largely because there's no round-trip. But decider, Ollaya's own pick for "most accurate," lands at 155-190ms — close enough to hosted-Jev territory that the latency advantage mostly evaporates once you choose the more capable model in the bundle. Speed and accuracy trade against each other inside Ollaya's own catalogue, not just against TypeSafe's hosted product.

Platform and GPU support

Ollaya is Apache-2.0 licensed, pins weights to sha256-checked Hugging Face commits (so an update can't silently swap in different weights under the same tag), and the server listens on 127.0.0.1 by default — a deliberate local-only, privacy-first default rather than something you have to lock down after the fact.

Is this genuine infrastructure, or just a wrapper?

This is where the discussion gets more interesting than the product page, and it's worth reporting honestly rather than repeating Ollaya's own framing. Commenters on Hacker News split roughly into two camps on an Ollaya launch thread.

The skeptical camp argued there's nothing novel here, and one commenter put it bluntly: "After chatgpt everything in AI mostly became LLMs and building wrappers around them. It's like people forgot how to do ML... anyone with basic ML knowledge could've built this in a few hours. The question is mostly why wasn't this productized." Others in the same thread went further on the terminology itself, calling out "decision model" as marketing dressed over old concepts: "decision model = classifier, system one model = small non-reasoning LLM, noul = boolean, confidence = f(probabilities)... It's sad to see how gullible engineers are today." There was also unresolved speculation — not established fact — about whether Laya's creator independently arrived at a similar architecture or built on ideas from Jev/TypeSafe roughly two weeks after Jev's own launch.

The counter-argument, from other commenters on the same thread, is a demand-timing one: "It wasn't until recently that demand for classifiers at this scale existed. Jev exists because LLMs exist," and separately, "LLMs still are better than Jev at the task, just across the board slower... people tried fine-tuning classifiers back in 2023/2024 and it was determined not worth the effort vs chain-of-thought — the tradeoff calculus only recently flipped." A related Hacker News thread on the broader Jev-clone phenomenon made the same point about the underlying model architecture specifically: "The moat is the RL synthetic data pipeline they set up to train Jev. Open sourcing that would be the coup, not the model architecture and training scripts, which are trivial" — a claim consistent with where Jev actually fails, which found the harder failure modes cluster around data and calibration, not raw architecture.

Neither side is simply wrong. The classifier techniques Ollaya bundles (NLI zero-shot, logit-based option scoring, LoRA fine-tuning) are not new inventions — they predate Jev by years. What's arguably new is the packaging: a single local runtime treating "decision model" as a first-class deployment target the way Ollama treated "local LLM," at the exact moment demand for that category spiked.

The accuracy gap, with numbers

The debate isn't purely philosophical — there's a real, cited accuracy gap behind it. An independent jevbench leaderboard citation put Ollaya's Laya 421M model at roughly 41st place with a score of 30.25 (58.4% public accuracy, 30.8% sealed accuracy) — well behind Jev itself at 63.29 (86.6% / 36.7%) and other open clones like decider-4b v2 (64.13) and Kev 4B (36.14). One developer's comment on the thread summarized it plainly: "Yes. Laya is a lot weaker than Jev, especially on harder queries. It's a small model, so it's fast, but that's the trade-off." At the same time, real production use was reported in the same thread: "it works so well I already integrated it into my product... saves about 75% of costs" — a reminder that "weaker on hard queries" and "good enough for a specific production task" aren't contradictory claims. See Jev's speed and cost claims, fact-checked for the equivalent scrutiny applied to TypeSafe's own numbers.

Practical use cases for a local decision-model runtime

The category Ollaya serves — fast, calibrated, non-generative classification — has concrete, latency-sensitive use cases that a hosted API round-trip actively hurts:

• Support ticket routing. Classify "what does this customer want" into a fixed set of categories without waiting on a network round-trip per ticket, echoing the example baked into Ollaya's own docs.
• Home automation intents. A commenter on a related Hacker News thread described the pattern directly: "It's cold and dark in here, do something about it" needs to trigger near-instant appliance actions, not wait on an LLM call.
• Agent action selection. Another developer described building a woodworking app where a fast decision model handles real-time action selection for an "autopilot" — interpreting instructions like "cut the middle 2x4 into 4 equal pieces" and choosing from available actions — while a larger LLM handles the higher-level reasoning above it. This mirrors the routing pattern in Jev's cheap verification checkpoints for agent pipelines.
• Semantic grep / log search. Scoring whether a log line or code snippet matches a natural-language query is exactly the "score all options in one pass" shape gliclass and nli are built for.

Commenters on the same threads recommended an iterative path to get here rather than jumping straight to a decision model: prototype with an LLM and prompt-engineer it, collect a real-world eval dataset from that prototype, turn the working prompt into a rubric for a decision model, iterate on accuracy, then land on a cheap, fast, calibrated classifier fine-tuned to the specific task — validated in production rather than staying dependent on a slow, expensive LLM call indefinitely.

Decision models vs. the alternatives you already know

Ollaya's bundled models aren't the only way to solve "classify this text into one of N categories fast." Three approaches compete for the same job, and the trade-offs are genuinely different, not just a speed/accuracy slider:

The honest takeaway: a fine-tuned BERT classifier still wins on raw accuracy for a fixed, well-labeled task, and embeddings still win on flexibility for exploratory or fast-changing category sets. Ollaya's pitch is the middle lane — no training required, better calibration than raw embedding similarity, and a consistent API across seven different model choices so you can pick the point on that trade curve per task instead of committing to one architecture project-wide.

Honest limitations

• Ollaya trains none of its own models — it depends entirely on the continued availability, licensing, and maintenance of seven third-party projects it bundles.
• The accuracy gap versus hosted Jev is real, not marketing spin — the jevbench numbers cited above (30.25 vs. 63.29 for Laya vs. Jev) come from an independent leaderboard, not from Ollaya's own materials.
• GPU support is uneven across platforms — macOS and Linux ARM64 are CPU-only; only Linux x86-64 and Docker get native CUDA.
• The "is this genuinely novel infrastructure" debate is unresolved — treat the Hacker News quotes above as community opinion, not a settled technical verdict.
• Speculation about Laya's origins relative to Jev/TypeSafe is exactly that — speculation — no independent confirmation either way is cited here.

What this means for builders

If you're already calling Jev's API and want a way to develop, test, or run offline without hitting TypeSafe's hosted endpoint, Ollaya's drop-in API compatibility is the practical reason to try it — point TYPESAFE_BASE_URL at localhost and existing SDK code should work unchanged. If you're choosing a decision-model architecture from scratch, use the accuracy numbers above rather than the speed table alone: decider is the accuracy-lean pick inside Ollaya's own bundle, the multilingual laya variants are the latency-lean pick, and none of them fully close the gap to hosted Jev on hard queries yet. As with every clone in this category — see six Jev clones in two days and awesome-jev-use-cases — test against your own representative task before adopting anything here beyond experimentation.

Related on explainx.ai

• Learn Jev: self-paced Jev & TypeSafe AI course on Udemy, or the live Build with Jev workshop — full comparison.

• Six Jev clones shipped in two days — the model-level open-source response Ollaya packages rather than joins

• Awesome Jev Use Cases: a 50-demo gallery you can run yourself

• Kev's real numbers: 0.8B/4B/9B, corrected from the "8B" headline

• Laya on MLX: an on-device Jev alternative

• OpenJev: an open-source Jev clone with open models

• Jev vs. XGBoost and BERT: is a System One Model actually new?

• Where Jev actually fails: the specific complaints behind the hype

• How does Jev actually work? RLCD and the System One Model, explained

• Jev's speed and cost claims, fact-checked

This post describes Ollaya as published on ollaya.dev as of September 2026, alongside Hacker News community discussion cited and attributed as such throughout. Speed and accuracy figures are drawn from Ollaya's own published tables and an independently cited jevbench leaderboard entry, not independently re-benchmarked by explainx.ai. Verify current numbers against each project's own repository before adopting anything here in production.