Jev · third front door
Jev on OpenCode: a decision endpoint, not a chat endpoint
OpenCode Zen serves Jev on its own path — /zen/v1/systemone — instead of the
chat-completions endpoint every other model there shares. You send a state and a map of typed
questions; you get back one answer per question id. That is the same shape Cloudflare
documents and the same shape the model is, and seeing it spelled out by a second provider is the useful
part: the request format is the product, not a client library's convenience.
What OpenCode declares
| Field | Value |
|---|---|
| Model ids | jev-1.13 · jev-1.13-free the second is the limited-time free route |
| Endpoint | https://opencode.ai/zen/v1/systemone not the chat-completions path the other Zen models use |
| Request shape | state + questions a string, and a map of typed questions keyed by the id you choose |
| Question types | noul · choice · score yes/no, one of a set, or a point on a rubric you define |
| Response | one answer per question id values and probabilities; text is not the output |
| Free route | jev-1.13-free the docs call the free model limited-time |
OpenCode's own sentence for it is worth quoting, because it says the thing this topic keeps having to re-establish: Instead of generating text, it evaluates a state against typed questions and returns values and probabilities that your code can use directly.
Three doors, one model
| Field | Value |
|---|---|
| OpenRouter | typesafe/jev-1.13 Model listing with a per-request call — The door this site's specs come from. It answers on the single-model endpoint even though it is not in the catalogue list our sync reads. |
| Cloudflare Workers AI | typesafe/jev Called through env.AI.run with state + questions — The first door that showed the non-chat shape in a provider's own docs. |
| OpenCode Zen | jev-1.13 Dedicated /systemone endpoint, state + typed questions — The third, and the one that gives the shape its own URL path rather than one function signature. |
Nothing about the model changes between the doors; what changes is who bills you and what the request looks like on the wire. The typesafe/jev-1.13 specs on the Jev page were read from the OpenRouter listing, and they still describe the same 32K-context, $0.042-per-million-input model that OpenCode is now routing.
The question types, in one table
| Field | Value |
|---|---|
| noul | yes / no documented example: Does this request require urgent attention? |
| choice | one of a set you name documented example: Which team should handle this request? |
| score | a point on a rubric you name documented example: How frustrated is the customer? |
The semantics of each type — what noul returns, how a score rubric is ordered,
what the probability means — are on the reference page, which is
where we keep the request and response fields. This page only records that OpenCode publishes the same
three.
How to check it yourself
| Field | Value |
|---|---|
| Is Jev on Zen | Fetch opencode.ai/zen/v1/models and search for jev no key needed; this is the list we read |
| The endpoint and the example | opencode.ai/docs/zen the Jev section carries a two-question example and the response shape |
| What it costs | The same page's price table jev-1.13-free is listed among the free routes |
| Our own specs | /typesafe-jev read from OpenRouter on 2026-09-18, with the parameters we measured ourselves |
FAQ
Is Jev available on OpenCode?
Yes, as of 2026-10-09: OpenCode Zen lists jev-1.13 and a limited-time free variant, jev-1.13-free, and documents them at a dedicated /zen/v1/systemone endpoint rather than the chat-completions path the other Zen models use.
Why does Jev not use the chat endpoint?
Because it does not generate text. You send a state and a map of typed questions — noul for yes/no, choice for one of a set, score for a point on a rubric — and receive an answer with a value and a probability per question. A chat-completions shape assumes a prompt and a completion, and this model has neither.
Does this tell us anything new about the model?
One thing worth recording: it is the second provider to document the same non-chat request shape in its own words. Cloudflare's Workers AI page shows state plus a questions object through env.AI.run; OpenCode gives the same shape its own endpoint. Independently written provider docs agreeing on a request format is weaker than a benchmark and stronger than a blog post.
Which route should I use?
Whichever bills you the way you want and passes your data rules. The model is the same; the doors differ in who charges, what the wire format looks like, and what their terms say about retention. Read the terms on the door you pick — the spec table on this site is about the model, not about the provider.
Where this fits
The Jev topic holds the specs, the measurements and the guide; Jev with Claude Code is the other pairing we wrote up — one is about calling Jev from an agent, this one is about calling it from a provider.
New front doors, and what we measured on each
We add a route here when a provider documents it and we can read it ourselves. One email when that happens — not a newsletter.
One email per event. No newsletter, no forwarding, unsubscribe in one click.