Can you run Jev locally with Ollaya by changing one setting? For most of the Jev tooling on npm, no. We downloaded every npm package published for TypeSafe’s Jev decision model in its first eleven days — 698 of them — and read how each one decides where to send its request. 520 build a Jev request of their own. Only 193 of those 520 honour TYPESAFE_BASE_URL, the one variable Ollaya's README tells you to set. The other 327 need a code change, a different variable, a config file, or cannot be pointed anywhere else at all.
The single biggest predictor is whether the author used the official SDK. Use the official SDK and the switch to Ollaya is free; write your own fetch() and it almost never is.
Status, 26 September 2026: counted against the npm registry on 26 September and Ollaya at commit 8989f88. Re-check any package in one line: grep -rn "TYPESAFE_BASE_URL" node_modules/<package> — then read what the matching line actually does.
Jev is TypeSafe AI’s “System One” decision model, launched 15 September 2026. It reads a document plus typed questions and returns calibrated probabilities — a yes/no confidence, a choice distribution or a score — instead of generating text. TypeSafe’s hosted API charges $0.042 per million input tokens and nothing for output. Vercel reported that 13% of its paid AI Gateway users were calling Jev within 24 hours of launch. There are no official open weights, which is why “run Jev locally” became its own genre within a week: open decision models, a Kev reimplementation on Qwen 3.5, and now Ollaya.
Ollaya is an open-source runner for decision models, built the way Ollama runs LLMs, and it reached 483 points and 122 comments on Hacker News on 26 September. Its README makes a specific compatibility claim: POST /v1/systemone, /v1/decisions and GET /v1/models are wire-identical to TypeSafe's, and "the official SDK works unchanged when you set TYPESAFE_BASE_URL=http://localhost:11435." We checked that claim against the SDK's source and it holds. @typesafe-ai/sdk 0.6.0 calls exactly two endpoints — GET /v1/models and POST /v1/systemone — and Ollaya's router in crates/ollaya-server/src/http.rs serves both. The Python typesafe-sdk 0.7.1 reads the same variable through its BASE_URL_ENV constant.
So the promise is sound. The question is how much of the ecosystem is built on the thing the promise covers.
193 of 520 Jev clients on npm honour TYPESAFE_BASE_URL — 37.1%. A client "honours" it when setting that one variable, and nothing else, changes where its Jev requests go. That happens two ways: the package reads the variable itself (59 packages), or it constructs the official SDK without overriding the base URL, so the SDK reads it on the package's behalf (134 packages). The remaining 327 packages send their requests somewhere the variable cannot reach.
A local runtime is only as compatible as the clients that were written to be redirected.
Because the SDK does the environment lookup for you, and a hand-rolled client has to remember to. 152 of the 176 packages that use @typesafe-ai/sdk honour the variable (86.4%). 41 of the 344 packages that write their own HTTP client do (11.9%). The typical hand-rolled client declares a constant — const ENDPOINT = "https://api.typesafe.ai/v1/systemone" — and posts to it. Many of them do accept an override, but through a constructor option or an environment variable of their own naming, which is the next finding.
The 24 SDK users that still ignore the variable all do the same thing: they pass baseURL explicitly when constructing the client. The SDK's constructor lets an explicit value win over the environment, as it should, so a hard-coded baseURL: "https://api.typesafe.ai" silently switches the variable off.
If you maintain a Jev client, the fix is one line: resolve the base URL as your own option, then TYPESAFE_BASE_URL, then the public default — in that order — and leave baseURL unset when you construct the SDK. 30 distinct environment variable names set the Jev endpoint across these packages. TYPESAFE_BASE_URL is the most common, read directly by 59 packages. After it come JEV_BASE_URL (13), TYPESAFE_ENDPOINT (5), JEV_API_URL (5), JEV_ENDPOINT (4) and TYPESAFEAI_BASE_URL (4), then a long tail of names used by one or two packages each, such as TYPESAFE_URL, TYPESAFE_AI_BASE_URL and a tool-prefixed variant per project. Every one of them works for its own package. None of them is the one Ollaya documents. (We matched 45 candidate names and excluded 15 that configure something else — proxies, target pages, or OpenRouter and Cloudflare endpoints.)
If you run three Jev-powered tools on one machine, you may need three variables to move them all to localhost. We split the clients that ignore TYPESAFE_BASE_URL by where their request goes:
We hand-read a random 20 of the 250 direct clients. 14 expose some other knob — their own environment variable, a constructor option or a config field — 3 are hard-coded outright, and 3 we could not settle without running them. So most of the 327 can be moved to Ollaya. Just not with the one setting.
** on your own stack for a second: which of the Jev tools you installed this week did you check for this?**
No, and two of the packages say why in their own comments. One opencode plugin documents that it always sets the base URL explicitly because reading it from the environment “prevents TYPESAFE_BASE_URL from redirecting a configured key" — an attacker who can set one variable could otherwise send your API key to their server. Another package pins the endpoint "so an unrelated TYPESAFE_BASE_URL override cannot" change it. That is a real security trade-off, not an oversight. It also means local-first tooling and key-protection are pulling in opposite directions, and a package cannot serve both without an explicit opt-in.
On 26 September 2026 we queried the npm registry search API with seven terms — jev, keywords:jev, systemone, typesafe, typesafe system one, ollaya and decision model — and collected 13,786 unique results. We kept packages whose name, description, keywords or README mention Jev, TypeSafe's System One or Ollaya, and whose first publish date is on or after the 15 September launch: 698 packages. We downloaded the latest tarball of every one.
Then we classified each package on the line that assigns the request URL, not on whether a string appears somewhere in it. Our first-pass signal — “does TYPESAFE_BASE_URL appear in the code" — was badly wrong: it matched constants named TYPESAFE_BASE_URL that hold a hard-coded URL, error messages that merely mention it, and comments explaining why a package deliberately ignores it. We rebuilt the classifier around actual environment reads and actual SDK constructor calls, then hand-read:
Every automated call that flipped, flipped toward the louder number, which is the direction to distrust — so each of the 11 was confirmed against the code. Where a hand-read could not settle a package, we counted it as honouring the variable, which makes 37.1% an upper bound. 178 packages had no Jev request path of their own — they delegate to a host agent, depend on another Jev package, ship a native binary, or just share the name — and are excluded from the 520.
Can you run TypeSafe’s Jev model itself locally?
No. TypeSafe publishes no official Jev weights. Ollaya runs open decision models — Laya, Kev, Decider, Von and others — behind a TypeSafe-compatible API, so clients built for Jev can talk to them. That is a local substitute, not Jev.
What is the fastest way to check whether my Jev tool will switch to Ollaya?
Search the installed package for TYPESAFE_BASE_URL and read the matching line. If it reads the variable, or the package constructs TypeSafeClient without a baseURL, set the variable and it will follow. If it only names a constant, look for the package's own variable or option instead.
Does Vercel’s AI SDK provider for TypeSafe honour TYPESAFE_BASE_URL?
Not in version 3.0.8, which we read. @ai-sdk/typesafe-ai takes the base URL as a baseURL option when you create the provider, and reads its API key from TYPESAFE_AI_API_KEY. Pass baseURL: "http://localhost:11435/v1" in code to point it at Ollaya.
Why did so many developers skip the official SDK?
Timing, most likely. The npm SDK first appeared on 12 September, three days before the public launch, and a single fetch() to one endpoint is short enough to write by hand. It is also the reason most of these clients cannot be redirected by the standard variable.
Will this number go up?
It should, if library authors adopt the SDK or read TYPESAFE_BASE_URL as a fallback. We will re-run the census and publish the change rather than predict it.
If you have already moved a Jev-powered tool to a local decision model, which setting did you actually have to change — and was it the one the docs told you to? We publish one original measurement a week, with the method attached and the corpus named. The next one probes how many agent libraries still misread GPT-6 Sol four days after its launch. Follow to get it when it lands.
Written by Decoding AI. We measure what the AI industry asserts, and publish the method with the number.
Can You Run Jev Locally? We Checked 520 Jev Clients — Only 193 Switch to Ollaya With One Setting was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.