You rarely call Jev from the same place twice. A prototype hits the TypeSafe API directly, a Next.js app goes through the Vercel AI Gateway, a Worker calls it from Cloudflare, and a framework user reaches it through OpenRouter. The request shape barely changes; the surrounding contract does. Here is the current map.
The direct API is the reference
Everything else is a wrapper around POST /v1/systemone with a state and a questions map, documented in the API reference. If you can call this, you can call any of the gateways, because they all preserve the typed request and the typed answer. Access starts at the TypeSafe console.
Vercel: gateway plus a first-party SDK provider
Vercel ships Jev as a model on the AI Gateway and as an AI SDK provider. For a Next.js app already on the AI SDK, that means the decision call goes through the same transport as your other models, and the Vercel guide covers the wiring. The gateway also gives you the provider's own retries, caching, and keys.
One trade-off: a gateway adds a hop. When the decision sits in a tight loop, call the API directly; when it sits beside other model calls, the one transport is worth it.
Cloudflare: Jev in the Workers AI catalog
Cloudflare lists typesafe/jev in Workers AI, callable with env.AI.run inside a Worker or over the REST API with an account ID and an AI token — the Workers AI entry documents the binding and the envelope shape. The card flags it third-party and lists zero data retention. The same catalog now carries Cloudflare's own Clef decision models, which answer the same typed shape, so a Worker can compare them behind one interface.
OpenRouter: a router entry with a comparison surface
OpenRouter lists Jev and a decision-model family alongside it, which makes it the fastest way to try Jev against the rivals on identical questions. It is a router, so it adds a hop and its own terms; it is best for evaluation and comparison, not the hot path.
The common thread: the base URL
All of these reduce to a base URL and a key. The serving locally article makes the same point for self-hosted servers, and the open reimplementations answer the identical request. That portability is why moving between gateways, and even to an open model, is a configuration change rather than a rewrite.
| Surface | Best for | Cost of the hop |
|---|---|---|
| Direct API | Tight loops, lowest latency | None |
| Vercel Gateway | Next.js and AI SDK apps | One network hop |
| Cloudflare Workers AI | Edge and Worker workloads | One hop, edge-local |
| OpenRouter | Comparing Jev against rivals | One hop, shared rate pool |
| Local server | Data residency, offline, fixed version | Your hardware |
Choose by where the decision runs
If the decision runs in a Next.js route, use the Vercel gateway. If it runs at the edge, use Workers AI. If you are still choosing a model, use OpenRouter to compare. If it runs in a tight control loop, call the API directly, because no wrapper earns its latency there.
Same request, same answer, different contract. Pick the surface that matches where your code already lives.