Jev API: How to Use TypeSafe’s Model, Queue, OpenRouter Access and Token Pricing
The jev api is the HTTP surface for TypeSafe AI’s System One model, allowing developers who use jev to send application state along with typed questions and receive structured decisions rather than free-form text. It runs at $0.042 per million input tokens with output free, answering in roughly 70 to 500 milliseconds, and is available in beta on OpenRouter as typesafe/jev-1.13.
This guide walks through how to call the API end to end, from hitting the decisions endpoint and structuring Bearer auth to implementing the Choice, Score, and Noul decision types. It details how the engine handles many questions in a single parallel request rather than relying on a slow serial queue, ensuring latency remains predictable even for complex application logic.
It also covers OpenRouter availability via the alpha decisions endpoint, concrete per-token and per-decision pricing models, and a side-by-side price comparison with cheap general-purpose models like GPT-4o mini, Gemini Flash, and Claude Haiku. Understanding these mechanics enables engineering teams to integrate the model directly into high-throughput production environments without unpredictable billing.
What the Jev API is and what it returns
The Jev API is TypeSafe AI’s HTTP interface to its System One model, which takes app state plus a typed question and returns a typed decision with a probability rather than text. Jev is developed by TypeSafe AI specifically for bounded judgments that software executes millions of times a day, such as routing, classification, scoring, and safety checks. Because the Jev API returns a typed decision with a probability instead of text, applications do not need complex parsing layers or validation loops to handle the response.
System One vs generative LLMs
Jev stands apart as TypeSafe AI’s flagship and first System One model, fundamentally differing from traditional generative LLMs. Standard large language models are optimized to emit paragraphs of conversational prose, requiring developers to use JSON prompting to force structured output. With this System One AI architecture, there is no JSON prompting, no parsing layer, and nothing to validate because the answer is already typed natively.
The architecture is optimized for high-volume inline execution where text generation is unnecessary overhead. Important metrics define this performance gap:
- Jev costs $0.042 per million input tokens, with output tokens free, and answers in 70 to 500 ms end to end.
- The model bypasses autoregressive decoding entirely, allowing it to finalize internal states instantly.
- Memory overhead is strictly bound to the input context size, completely eliminating output generation costs.
What comes back: value + probability
The response from the model is structured as an answers object where each requested question yields a typed value plus a probability or confidence signal. Instead of receiving a string of text that must be interpreted, the application code receives a clear data structure indicating exactly what to do next, such as routing a request, pushing a task to a queue, or escalating a flagged item to a human reviewer.
This return shape drastically simplifies application logic. By providing a numeric probability alongside the decision, the API empowers the consuming application to set programmatic thresholds. If a classification decision returns a low confidence score, the system can automatically trigger a fallback workflow, whereas high-confidence decisions pass straight through. This deterministic output shape is what makes the low per-million-input-token economics feasible for inline production calls.
How to call the Jev API: endpoint, auth and request shape
A call to the Jev API is a single POST to the decisions endpoint with a Bearer API key, sending a JSON body of state plus a questions map and receiving typed answers. The Jev API returns a typed decision with a probability instead of text, ensuring immediate usability. OpenRouter serves Jev in beta as model typesafe/jev-1.13 through a separate alpha endpoint at POST https://openrouter.ai/api/alpha/decisions, with a 32,000-token context window.
Endpoint and authentication
There is essentially one decision endpoint to execute queries, implemented as a POST request to either a /decisions or /v1/systemone-style path depending on the provider. Authentication is handled via standard HTTP headers, requiring Authorization: Bearer <API_KEY> and Content-Type: application/json.
To execute a request successfully, follow these specific integration steps:
- Obtain an active API key / Bearer authentication token from the TypeSafe console or your chosen provider platform.
- Construct a standard HTTP POST request directed at the target decisions endpoint.
- Inject the
Authorizationheader formatted exactly asBearer your-token-string. - Add the
Content-Type: application/jsonheader to ensure payload parsing succeeds. - Send the compiled request body containing the context window data and await the JSON response.
Request body: state + questions
The request body is strictly divided into two primary parts: the state and the questions map. The state represents your program context and can be passed as plain text, JSON objects, or text arrays, defining the knowledge the model uses to make its judgment. The questions parameter is a named map of typed queries that define exactly what evaluations the engine needs to perform against that state.
For a customer support integration, the body might define a state containing an incoming user email and user account metadata. The questions map could then include keys like queue (to pick a routing destination), priority (to score the urgency), and refund_review (to check if a human is needed). This shape allows developers to see how one single call yields several discrete decisions at once.
Reading the response
Upon successful execution, the endpoint returns an answers object keyed by the exact question names provided in the request body. Each key maps to an object containing the requested typed value, the calculated probability, and a dedicated confidence metric, allowing fine-grained control over downstream routing.
The response payload also includes usage and timing fields such as elapsedMs, which tracks the exact processing duration for monitoring pipelines. Developers must factor in the 32,000-token context window constraint when structuring their state payloads, as any data exceeding this limit will trigger a validation error before processing begins.
The three decision types: Choice, Score and Noul
The Jev API exposes decision types Choice, Score and Noul, which act as question primitives returning a typed answer with probabilities instead of generated text. A Choice question can select from up to 255 options, and all questions in one request are evaluated in parallel.
Choice
The Choice decision type acts as a categorical selector, configured to pick one specific option from a declared set of options. Developers define this set as an array of descriptive strings within the question definition, allowing the engine to evaluate the input state against those specific boundaries.
The API returns the chosen option alongside a full probability distribution and a distinct confidence score. This primitive is heavily used for routing support tickets to specialized departments, categorizing incoming transactions, or picking an appropriate processing queue based on complex contextual clues that simple regex cannot handle.
| Decision Type | Primary Use Case | Output Format | Max Boundaries |
|---|---|---|---|
| Choice | Routing, classification, categorization | Single string + distribution | Up to 255 discrete options |
| Score | Severity, priority, risk assessment | Weighted float + per-level data | 2 to 10 ordered levels |
| Noul | Guardrails, binary checks, logic gates | Float (0.0 to 1.0) | N/A (Boolean nature) |
Score
The Score decision type grades the provided input state along an explicitly ordered rubric. Instead of selecting distinct categorical buckets, Score evaluates data across a spectrum containing between 2 and 10 levels, assessing intensity or severity based on the instructions provided in the question map.
The response is a probability-weighted position that can fall dynamically between defined levels, offering more granularity than a rigid integer scale. The payload also contains individual per-level probabilities. This makes Score the ideal primitive for assigning priority to bug reports, evaluating the severity of a security alert, or assessing financial risk.
Noul (boolean)
The Noul decision type is a boolean primitive representing a binary probability ranging from 0 (meaning strict no) to 1 (meaning strict yes). Unlike the other primitives, the Noul output number is the model’s belief itself, operating without a separate attached confidence metric.
When invoked via specific integration layers like Vercel, the Noul output is often simplified and surfaced directly as a standard Boolean type in the application code. This type is best utilized for implementing safety guardrails, performing rapid true/false validation checks, and determining whether a specific programmatic condition has been met.
Queue, concurrency and latency: how Jev handles load
The Jev API avoids a slow serial queue by evaluating all questions in one request in parallel, ensuring that Jev answers in 70 to 500 milliseconds end to end regardless of batch size. Because Jev evaluates all questions in one request in parallel, ten questions cost roughly the time of one, radically improving throughput.
Parallel evaluation, not a serial queue
When developers hear the word ‘queue’ in relation to this API, it typically refers to two entirely separate concepts that must be distinguished. First, at the protocol level, there is no serial evaluation queue inside a single request. All declared questions within the map run in parallel against the provided state. Batching numerous decisions into a single API call does not multiply the latency, allowing complex, multi-faceted evaluations to execute instantly.
Second, ‘queue’ frequently appears as a downstream application concept driven by the model’s output. For example, a Choice answer might literally route a customer support case into a specific billing or priority queue within Zendesk or Salesforce. Clarifying this distinction ensures engineering teams understand that the API itself operates concurrently, while the outputs often dictate external queue management.
Latency you can expect
The model’s published latency sits firmly in the 70 to 500 ms end-to-end range, offering near-instantaneous feedback for high-speed programmatic loops. This baseline applies to standard workloads, but the exact speed heavily depends on network location, payload size, and the level of concurrent requests being fired from the client environment.
Because performance can fluctuate based on these variables, latency should always be strictly validated within the reader’s own infrastructure before relying on it for hard SLAs. During the current beta phase, there are no public per-account rate-limit numbers documented, meaning developers should monitor their own request thresholds closely.
Jev on OpenRouter: availability, model id and credits
Jev is available on OpenRouter in beta as typesafe/jev-1.13, served through the alpha decisions endpoint POST /api/alpha/decisions with a 32,000-token context window and prepaid credits. OpenRouter adds a 5.5% credit fee on top of Jev pricing, making it a highly accessible route for developers already in the ecosystem.
Model id and endpoint
For developers utilizing aggregator platforms, the specific OpenRouter model id is strictly defined as typesafe/jev-1.13. Because the model relies on structured inputs rather than standard chat completions, requests must be routed to the separate alpha endpoint located at POST https://openrouter.ai/api/alpha/decisions.
- The payload supports a strict 32,000-token context window, allowing substantial application state to be passed per request.
- OpenRouter added the model to its roster on September 18, 2026, roughly three days after the official platform launch.
- The integration remains actively in beta, meaning the endpoint structure is subject to refinement.
Credits and fees
Accessing the model through OpenRouter requires developers to maintain an active balance of prepaid credits on their account. The platform applies its standard credit fee of approximately 5.5% on top of the base computing costs, which rely on the exact same $0.042 input token and free output token pricing scheme used directly by TypeSafe. Because the markup is isolated to the credit fee, the financial overhead of using OpenRouter versus calling the native API directly remains exceptionally small.
Jev token pricing in detail
At exactly $0.042 per million input tokens with output free, Jev costs roughly $0.0004 per decision on standard benchmark workloads. Because the model generates no text, there are no output tokens to bill, fundamentally altering the economics of inline AI calls for developers scaling infrastructure. Jev costs $0.042 per million input tokens with output free across all standard integrations.
The fundamental per-token price of $0.042 per 1M input tokens and $0 per 1M output tokens is a direct result of the System One architecture. Because the engine emits pre-calculated probabilities rather than autoregressive prose, output token generation simply does not exist. This specialized pricing structure is universally echoed on platforms like OpenRouter and Vercel, and developers can verify exact billing mechanics by consulting the Jev AI model pricing documentation.
The platform provides a unified application programming interface (API) through which developers can access models from multiple developers and inference providers.Wikipedia
To understand the cost per decision, consider a worked estimate based on standard application payloads. If a system processes 1,000 decisions requiring roughly 500 input tokens each, the total compute cost sits at approximately 2 cents. TypeSafe officially pegs the average decision cost near $0.0004 for standard enterprise tasks.
- Input token pricing remains locked at $0.042 per million.
- Output generation carries absolutely zero cost.
- OpenRouter’s ~5.5% credit fee acts as the only markup on these estimates.
Jev price compared to other models
At $0.042 per million input tokens with output free, Jev is cheaper than general-purpose LLMs like GPT-4o mini, Gemini Flash, and Claude Haiku for high-volume decision workloads. TypeSafe reports Jev was up to 193.6x faster and 444.6x cheaper than LLMs in its own testing, highlighting a massive economic gap for specific bounded tasks. Jev costs $0.042 per million input tokens with output free, changing how developers allocate AI budgets.
The input-token price advantage is stark for structured tasks. Comparing raw token costs reveals a significant delta between specialized decision models and general-purpose conversational agents. Jev’s free output remains the biggest differentiator for high-volume, automated decisions where prose is unnecessary.
| Model | Input Price per 1M Tokens | Output Price per 1M Tokens |
|---|---|---|
| Jev | $0.042 | $0 (Free) |
| GPT-4o mini | $0.15 | $0.60 |
| Gemini Flash | $0.75 | $3.75 (introductory through Dec 31, 2026) |
| Claude Haiku 3.5 | $1.00 | $5.00 |
The architectural gap explains the massive cost difference. These comparisons represent an apples-to-oranges reality: Jev is specialized entirely for bounded decisions and emits absolutely no prose, allowing it to avoid output-token billing entirely. While TypeSafe reports up to 193.6x faster and 444.6x cheaper metrics in its tests, engineering teams should frame these strictly as vendor figures to verify in their own unique production environments.
Access routes, limits and when to use Jev
Developers can integrate the system via the TypeSafe console, OpenRouter, and gateways like Vercel AI Gateway, relying on it when software needs a fast typed decision rather than generated text. Jev is available on OpenRouter in beta as typesafe/jev-1.13, and the Jev API exposes decision types Choice, Score and Noul across all connection methods. On Vercel AI Gateway Jev is exposed as model typesafe-ai/jev via the AI SDK experimental_evaluate function, and was free through September 25, 2026.
Three ways to get access
Engineering teams can route their traffic to the model through three distinct, officially supported pathways:
- TypeSafe console: Developers can create a direct account and issue an API key / Bearer authentication token for native integration.
- OpenRouter: Users can target model typesafe/jev-1.13 utilizing their prepaid credits and standard aggregator keys.
- Gateways: Vercel AI Gateway exposes typesafe-ai/jev via the AI SDK
experimental_evaluatefunction, while LangChain provides support via thelangchain-typesafepackage. All of these routes rely strictly on Bearer auth.
Constraints to know
While highly efficient, the architecture imposes specific operational limits that developers must design around. The Choice decision type maxes out at exactly 255 options per question, preventing unlimited programmatic branching. The OpenRouter gateway enforces a hard 32K context window, rejecting oversized state payloads. Furthermore, the model relies exclusively on structured text input—there is no documented vision support—and it will never produce free-form text output. Because the service remains in beta, strict rate limits and minor API versions are subject to rapid change.
When Jev fits — and when it doesn’t
Jev is explicitly recommended for tasks demanding massive volume and structural rigor, such as content routing, data classification, algorithmic scoring, and security guardrails. For applications requiring creative writing, conversational summarization, or open-ended reasoning chains, developers should implement a normal LLM instead. The two architectures are complementary tools designed for entirely different layers of the modern AI stack, not direct substitutes for one another.
FAQ
Is Jev still in beta?
Yes, Jev is currently served in beta on platforms like OpenRouter. It is accessible there under the model identifier typesafe/jev-1.13 through a dedicated alpha endpoint.
Is Jev output really free?
Yes, output tokens generated by Jev are completely free of charge. You only pay for input tokens, which are priced at $0.042 per million.
How do I get a Jev API key?
You can obtain access by registering with providers that host the model, such as OpenRouter or Vercel AI Gateway. Generating an API key within your account dashboard on those platforms will allow you to authenticate requests.
What is the maximum number of options per question?
A single Choice question allows you to evaluate up to 255 options at once. Jev will score and select from these choices within your defined context.
Are there extra fees on OpenRouter?
No extra hidden fees apply beyond standard platform credit usage for your input tokens. Usage is billed strictly against your existing account balance based on the token rate.
Can I make several decisions in one API call?
Yes, you can include multiple questions within a single API request. All questions submitted together are evaluated in parallel, delivering responses end to end in 70 to 500 ms.