ollaya

How we reviewed this: we took the v0.7.5 Linux release, checked it against the published sha256sum.txt, and ran it in Docker on four CPU cores with no GPU. We pulled laya, exercised the HTTP API, drove it through a separate MCP client, and ran it with --network none. We did not run winnow:e4b, the recommended model, because it wants an NVIDIA GPU we do not have; its numbers below are the project’s own. Neither we nor it made any call to TypeSafe.

What it does

ollaya serve runs a daemon; pull, run, list, ps, show, rm, cp, stop and create work the way Ollama’s do. Behind them is a library of open decision models — Laya, Mapika’s decider, CLM, JevK5, Kev, Von, Winnow, NLI classifiers — pulled by name. The daemon serves POST /v1/systemone, /v1/decisions and GET /v1/models in TypeSafe’s shape, plus a native /api/* with routing information and progress streams.

Nine Rust crates, about 33,000 lines, Apache-2.0, and docs/api.md calls itself a normative contract — it has an error model, error codes, validation-issue shapes and rules for errors inside a stream. That is not a five-day-old project’s usual documentation.

Where the weights come from

The claim that caught our attention is that ollaya publishes only small ONNX graphs and never re-hosts anyone’s weights. It holds, and you can read it in the manifest before you pull. laya’s manifest lists a 2.7 MB graph on ollaya.dev, and then:

"mediaType": "application/vnd.ollaya.weights",
"digest": "sha256:4fa56de72383a9d3efa9cfa78955733c81b9fc8067a587ca4beb82c78107a24e",
"size": 842609220,
"urls": ["https://huggingface.co/convaiinnovations/laya/resolve/aa8c91ca.../model.safetensors"]

The author’s own Hugging Face repository, pinned to a commit, with a digest to check it against. The whole pull was 852 MB in 68 seconds, and the registry lives in the repository as static files, so the manifest is reviewable in a pull request rather than served from somewhere.

What it costs without a GPU

laya routes by script and language and resolved to laya:en, a 421M ModernBERT, on CPU at fp32. First call 4.2 s, of which 3.7 s was loading the model. Warm, three questions in one request took 530 ms and one question 160 ms — so the state is read once and each extra question is cheap, which is the property the whole idea rests on.

That is the small end of the library. The recommended winnow:e4b is a 4B-class model the project reports at 89 ms for five questions on an RTX 4090; we could not check it here.

Truncation is an error, not a footnote

laya:en has a short context, and this is where the design shows. Past a few hundred words the Jev-compatible endpoint refuses:

422 {"error":"state: part of state was dropped to fit the context of laya:en",
     "code":"STATE_TRUNCATED", "detail":[{"loc":["body","state"], …}]}

The native /api/decide answers the same request and sets "state_truncated": true, leaving the judgment to a caller who asked for the native API. We planted a marker at the end of a long state to check it was not quietly clipping: the strict endpoint refused, and the same marker alone came back at 0.89. A client written for Jev never silently gets an answer about half its input.

Every error we could provoke came back the same way: a 422, a code, and the JSON path of the offending field. A 300-option choice is refused at 255 with the limit in the message.

It really is the same wire

The strongest test we could run was to point something else at it. We took System One Connector — an MCP server written for Jev, which we reviewed the same day — set TYPESAFE_BASE_URL to the ollaya daemon, and changed nothing else. It worked: noul, choice with ordered probabilities, the connector’s own min_confidence abstention, and its 500-item batch mode fanning three records out and back. An agent’s Jev tooling runs against a model on your laptop for the cost of one variable.

ollaya mcp serves four tools directly, and their annotations are careful: decide is readOnlyHint: true, openWorldHint: false, while pull_model is not read-only and is marked openWorldHint: true. Someone thought about what each one does to the machine.

It starts and answers with --network none once models are pulled. It did need a system CA store to start at all, even offline — on a bare ubuntu:24.04 image it exited with No CA certificates were loaded from the system. We reported that, and it was fixed on main the next morning (b88bf19): the plain-HTTP clients now load no TLS roots, so only a pull fails without a CA store, and it says which package to install. We read the change rather than rebuilding it, and it is not in a release yet.

Verdict

Five days old, and the scaffolding is already better than most of what it packages: a reviewable static registry, weights pulled from their authors under a pinned commit and a digest, a documented error contract, and a strict/permissive split between the compatible and native APIs that shows someone thought about who is calling.

The catch is the hardware. The model it recommends wants an NVIDIA GPU, and what is left on a laptop CPU is the small end, with a context short enough that a long ticket is a 422. Every accuracy figure in its model table is the project’s own, measured by the project, on its own suite. Treat the table as a map of what exists rather than a ranking.

For the models themselves, see Laya, decider, CLM and JevK5.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 28, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.