jev on openrouter

A URL Is Not Proof of a Callable Model

OpenRouter’s own X account announced Jev in beta, and a Jev route page resolves. OpenRouter also exposes a public model catalog at /api/v1/models; when checked September 22, 2026, it returned no model whose ID matched TypeSafe or Jev. The announcement establishes launch intent, while the missing catalog entry leaves the current callable identifier and contract unresolved.

Record both observations rather than saying either “OpenRouter never offered Jev” or “the route is definitely live.” Product announcements, route pages, catalogs and authenticated account access can change at different times. For implementation, the catalog entry and a successful account-level request are the decisive checks.

Check the Catalog Before Constructing a Request

This read-only query inspects OpenRouter’s public model metadata; it does not call Jev. An empty result means the catalog did not expose a matching route at that moment. If an entry appears, copy its exact ID and metadata from the response rather than translating Cloudflare’s typesafe/jev identifier or guessing an OpenRouter namespace.

Archive the response timestamp and relevant object with the integration review. Then compare the model page, API documentation and authenticated response. If those surfaces disagree, stop before writing production payload code and resolve which contract the account actually supports.

curl -sS https://openrouter.ai/api/v1/models   | jq '.data[] | select((.id | ascii_downcase | contains("jev")) or (.id | ascii_downcase | contains("typesafe"))) | {id, name, pricing, context_length}'

Verify the Provider Before Writing Integration Code

Do not guess an ID such as typesafe/jev from another provider. Cloudflare uses that identifier, but provider namespaces are not portable. OpenRouter commonly exposes OpenAI-compatible chat APIs, while Jev’s native contract is state plus typed questions; the mapping must be documented explicitly.

1. Query GET https://openrouter.ai/api/v1/models and find an exact TypeSafe/Jev model ID.
2. Open that model’s current page and record price, context, architecture and supported parameters.
3. Confirm how Jev state and typed questions map into the provider request; do not assume chat messages are equivalent.
4. Run a credentialed request and capture the response and error envelopes.
5. Compare the result with TypeSafe’s direct contract on identical labeled fixtures.

Represent Uncertain Availability in Code and Documentation

Availability changes independently of this site. Every provider statement needs a date and source. If a route disappears, retain a correction note rather than leaving copied setup instructions indexed.

Keep an Eventual OpenRouter Path Behind a Provider Adapter

The application should construct one internal Jev decision contract, then let each provider adapter map it to a verified transport. Do not scatter a speculative OpenRouter payload throughout product code. The platform guide shows the layer boundary and the HTTP API guide documents the direct TypeSafe contract used as the reference.

Verified Ways to Try Jev Today

These routes solve different problems. A playground is for exploration, a provider serves inference, and Failproof connects judgments with trace evidence, findings and policy operations. The platform map makes those layers explicit.

• TypeSafe’s browser Playground for manual question design.
• TypeSafe’s direct API with official Python or JavaScript SDKs.
• Cloudflare Workers AI using the published typesafe/jev model page and schema.
• Failproof AI beta for Jev eval and policy workflows; contact nikita@befailproof.ai.

What to Test if OpenRouter Lists Jev Again

Do not copy direct TypeSafe thresholds to a newly exposed route without a parity test. Provider adapters, preprocessing and model versions can change distributions even when the product name is the same.

• Exact model ID, alias behavior and upstream version visibility.
• Typed Choice, Score and Noul request and response fidelity.
• Probability precision and any normalization or translation.
• Pricing, quotas, routing, retention and provider selection controls.
• Latency, retries, request IDs and failure envelopes.
• Output agreement and calibration on the application’s held-out dataset.

Require a Route-Level Parity Report

Passing a smoke test establishes access, not equivalence. The provider comparison defines the portable record; calibration and benchmark methodology define the behavioral test.

1. Freeze representative Choice, Score and Noul fixtures with independent labels.
2. Run the same semantic definitions through direct TypeSafe and the verified OpenRouter adapter.
3. Compare answer agreement and full probability distributions, not only successful HTTP status.
4. Measure p50/p95/p99 latency, invalid responses, rate limits and retry-amplified cost.
5. Fit thresholds separately if distributions differ, then compare at equal automation coverage.
6. Record model/provider identifiers and dates beside every result.