Ollaya's latency table sets a local RTX 4090 against Jev's network round trip

Every request Ollaya serves is one forward pass. A decision model takes an input and a set of typed questions and returns a category, a score or a yes/no answer, each with a probability ^[3]. It does not write a free-form response ^[3]. In Ollaya's example, one billing complaint comes back as five fields: intent, urgency, frustration, refund request and churn risk ^[4]. The output is meant to go straight into application logic ^[5].

Cobanov's GitHub profile describes him as a senior AI engineer at Refik Anadol Studio, where he works on Dataland ^[7]. He built the serving and packaging, and quality depends on whichever model a team loads ^[8]. The Rust repository wraps a command-line tool, a daemon, a desktop app and a Docker image around models from other authors ^[2]. The catalog holds Laya from ConvAI Innovations, decider from Mapika, NLI classifiers associated with Moritz Laurer, and GLiClass from Knowledgator ^[8].

Ollaya reports 9.6 milliseconds for English Laya and 8.1 for its multilingual model on a five-question request, measured locally on an NVIDIA RTX 4090 ^[9]. Beside those it lists 236 to 276 milliseconds for TypeSafe's hosted Jev API, taken from third-party benchmarks that include network time ^[10]. At face value the gap is roughly 25 to 34 times ^[11]. Ollaya calls the comparison an order-of-magnitude reference ^[12]. The label is fair: one column is a GPU on the desk, and the other is a round trip across the internet ^[10].

For that gap to carry into production, each machine making decisions needs hardware close to a 4090. The Jev figure also has to match what a team measures from its own network location, since network time is part of it ^[10]. And the local model has to answer that team's questions about as accurately as Jev does. RuntimeWire's assessment is that the comparison is not a controlled head-to-head test ^[13].

In my view the calibration figure matters more than the latency. Ollaya says Laya's expected calibration error is 0.081 after temperature fitting, against 0.246 for Jev ^[14]. Code that auto-routes every answer above a probability threshold depends on that probability tracking accuracy on its own task ^[16]. Both figures are company-published, and the site does not establish that the models were tested on the same data under the same conditions ^[15].

The compatibility layer makes the check cheap. TypeSafe introduced Jev on September 14, 2026, as a model for structured decisions in software ^[22]. Ollaya exposes matching /v1/systemone and /v1/models endpoints, so TypeSafe's Python SDK can call a local server after a change of base URL ^[17]. The two projects have no established partnership, according to RuntimeWire ^[18]. Before switching, I would run four steps:

1. Pull a labelled sample of production inputs, with the questions the code already asks. 2. Send it to Jev through the existing SDK calls and record every answer and probability. 3. Point the base URL at the local Ollaya server and replay the same sample ^[17]. 4. Compare accuracy and calibration field by field, then time the local run on the hardware that will serve it.

The model handling is careful work. Ollaya pulls weights from each author's Hugging Face repository, pins them to a commit and verifies them with SHA-256 checks ^[19]. The model a team validated in step four is then the same bytes that load next month. Ollaya does not host the weights itself ^[19]. If an author deletes a repository, the pinned commit can no longer be fetched. For a tool pitched on running on user-controlled hardware ^[21], binding to loopback is the right default, and Ollaya's server listens on 127.0.0.1 by default ^[20].