Integration

Jev on OpenRouter

The fastest way to call Jev without an early-access key — and the one place people conclude it is not available, because OpenRouter's own model list does not contain it.

The short answer. The model id is typesafe/jev-1.13. It is live, serving, and priced identically to the first-party API. It is not in the default catalogue listing, so searching for “jev” in a picker returns nothing. Address it by its exact id.

What the provider API says right now

Rather than quote a screenshot, here is the readout from OpenRouter's own endpoints API, pulled on 2026-09-19:

Model id: typesafe/jev-1.13
Serving build: typesafe/jev-1.13-20260917
Input price: $0.000000042 per token ($0.042 / 1M)
Output price: $0 — no tokens are generated
Context length: 32,000 tokens
Max completion: 28,800
Uptime, last 24h: 100%
In model catalogue: No — see below

Check it yourself in one command; it takes no key:

bash

curl -s https://openrouter.ai/api/v1/models/typesafe/jev-1.13/endpoints | jq '.data.endpoints[0]'

Why it is missing from the model list

This is the single most confusing thing about Jev on any gateway, and it is not a bug on OpenRouter's side. Jev's architecture modality is text->decisions rather than text->text, and it reports an empty supported_parameters array.

Catalogue endpoints and model pickers are built around chat models. A model that produces decisions instead of tokens, and accepts none of the usual sampling parameters, falls out of those filters. The result is a model with 100% recent uptime that you cannot find by browsing.

bash

# The catalogue: no typesafe entry comes back.
curl -s https://openrouter.ai/api/v1/models | grep -o '"id":"typesafe[^"]*"'
# (no output)

# The model itself: fully served.
curl -s https://openrouter.ai/api/v1/models/typesafe/jev-1.13/endpoints \
  | jq '.data.endpoints[0].uptime_last_1d'
# 100

Do not send chat parameters

supported_parameters is empty, and it means what it says. There is no temperature, no top_p, no max_tokens, no penalties, no stop sequences. Nothing about sampling applies to a model that returns a probability distribution over options you supplied.

Jev also does not take the chat-completions request shape at all. You send a state and a map of typed questions; you get answers back under the same keys. So this is not a case of repointing an OpenAI SDK at a new base URL and changing the model string — see the API reference for the real shape.

OpenRouter or a first-party key?

OpenRouter

No waitlist. Same price. One bill alongside the rest of your models, and a second set of terms — OpenRouter's rate limits, privacy policy and billing apply, not TypeSafe's.

TypeSafe directly

The documented rate limits, the official SDKs, zero-data-retention terms for enterprise, and one fewer hop between you and the model. Costs you a place in the early-access queue.

For evaluating Jev, the gateway is plainly the better first step: you can be running today rather than waiting for a key batch. For production, the question is whose terms you want to be under.

Working examples that need no key

rajivkuriakose/typesafe-jev-examples

Worked ticket-triage and reranking examples runnable through OpenRouter without an early-access key, with sample data and a Makefile.

This is the shortest path from curiosity to a running call: clone it, add an OpenRouter key, and you have ticket triage and reranking working against real sample data without touching the waitlist.