OpenRouter provides managed access to TypeSafe Jev under model identifier typesafe/jev-1.13 and alias ~typesafe/jev-latest.
Developers can access Jev using OpenRouter's stable System One endpoint (supporting full multi-question batches with native TypeSafe schemas) or explore experimental single-decision workflows in OpenRouter's live Jev Lab.
Model Identifiers & Version Pinning
OpenRouter exposes two distinct slugs for routing requests to Jev:
•Pinned Version (typesafe/jev-1.13): Locks inference execution to Jev version 1.13.0. Recommended for production systems requiring reproducible decision distributions and stable scoring rubrics.
•Dynamic Alias (~typesafe/jev-latest): Resolves to the most recent stable release published by TypeSafe AI. Automatically adopts new minor and patch releases without client configuration changes.
Recommendation: Use POST /api/v1/systemone or the TypeSafe SDK with baseURL: "https://openrouter.ai/api" for all production architectures. It provides complete parity with TypeSafe System One schemas, accepts keyed question objects with explicit criteria rubrics, and returns structured answers.
Context Window Discrepancy
Important platform discrepancy: OpenRouter lists Jev with a flat 32,000-token context window in its model directory. In contrast, TypeSafe's direct API specifies a two-part budget:
01OpenRouter catalog limit: 32,000 tokens per request across your input payload.
02Direct TypeSafe budget: A total combined request limit of 64,000 tokens (shared state + all questions), with a strict cap of 32,000 tokens for the shared state plus the single longest question.
If your application relies on large multi-question payloads that exceed 32,000 total tokens while keeping state under 32,000 tokens, use direct TypeSafe endpoints or verify that your OpenRouter requests remain within OpenRouter's 32,000-token envelope.
Authentication & Headers
OpenRouter requests require an API key passed in the standard authorization header: