展開全文
I spent today wiring TypeSafe's Jev — the "System One" decision model that launched on Sept 15 — into a decision gate that routes coding tasks. Most of the time went into finding the endpoint, so here is what's actually true as of 2026-09-20. Everything below is measured, not read off the docs.
The endpoint nobody points you at
It works on OpenRouter with an ordinary OPENROUTER_API_KEY:
POST https://openrouter.ai/api/alpha/decisions
Content-Type: application/json
Authorization: Bearer $OPENROUTER_API_KEY
{
"model": "typesafe/jev-1.13",
"state": "help! my payouts have been failing for 3 days",
"questions": {
"tier": {
"type": "choice",
"instructions": "pick a tier",
"criteria": {
"billing": "payments",
"technical": "bugs"
}
}
}
}
Response:
{
"model": "typesafe/jev-1.13-20260917",
"answers": {
"tier": {
"type": "choice",
"choice": "billing",
"probabilities": {
"billing": 0.87,
"technical": 0.13
},
"confidence": 0.82
}
},
"usage": {
"input_tokens": 312,
"output_tokens": 35,
"cost": 1.31e-05
},
"provider": "TypeSafe"
}
The traps, each one measured:
/chat/completions with typesafe/jev → 400 "is not a valid model ID". Jev does not generate text, so it isn't an autoregressive chat model. Don't try to shim it into standard completions.
/api/v1/decisions → 404. The route is currently live under /api/alpha, not /api/v1.
Wrapping the body in {"decisionsRequest": {...}} → 400 invalid_type ... path: ["model"]. The body must be flat: model, questions, and state at the root level.
GET /api/v1/models (447 entries) lists no typesafe/* ID, and GET /api/v1/models/typesafe/jev-1.13 404s. Yet GET /api/v1/models/typesafe/jev-1.13/endpoints returns 200 with the full provider snapshot, pricing, context, and uptime. Any SDK preflight asserting "does the model exist in the list?" will falsely fail. Make a live call instead.
There is no typesafe/jev-latest alias on OpenRouter; that alias throws an error. typesafe/jev-1.13 is the only working ID, and every response names the dated snapshot it served.
Measured latency and cost: 239–430 ms per decision, $1.3–2.7e-05 per invocation (roughly $13–27 per million decisions). Output is unmetered.
The answer shapes are not uniform
choice gives you choice + probabilities + confidence. noul (yes/no) does not:
{"type": "noul", "noul": 0.01}
For noul, the value is a flat scalar float between 0.0 and 1.0 representing true/yes likelihood (e.g., 0.01 means overwhelmingly false), not a structured dict with probability labels.
I had code reading answers.x.probabilities.true, which silently defaulted to 0.0 — so a "does this patch match the intent?" gate answered no to everything, including good patches. If you port Jev snippets around, check that field shape.
The failure mode worth designing against
My first version of the gate had the classic fallback: except Exception: return choices[0].
With a live key pointed at the wrong route, every call 400'd and the gate answered anyway:
triage("refactor auth across 14 modules") → bash_direct
risk("auth models, 31 dependents") → low (would have auto-applied)
verdict(exit 1, "could not read Username") → complete (would have ended the loop)
Confident, cheap, and wrong in the direction that costs you.
The fix that stuck: the gate returns unavailable plus a default chosen from the stakes — fail open to the cheapest path for low-stakes routing (restricted strictly to non-mutating checks), fail closed (high, abort) for the risky ones — and the process exit code explicitly indicates whether you got a model verdict or a policy default.
Two things I'd have missed without an end-to-end smoke test
git diff is blind to files a coding agent creates: they're untracked, so a patch review gate sees an empty diff and rejects a perfectly good change. Use git add -N . && git diff (or git add -A && git diff --cached, but remember to unstage cleanly).
I pointed the harness log inside the worktree, so __pycache__ and the run log itself landed in the diff. The gate called that scope creep (noul 0.47 vs 0.94 for the clean version) and it was completely right — plus the messier diff cost 2x because you're billed on input token size. Keep run logs outside your worktree or in .gitignore.
Happy to share the routing-gate code if anyone wants it; it's stdlib Python and talks directly to the OpenRouter alpha endpoint. Verify the alpha route before you build on it — I measured this on one box today.
Jev 1.13 媒體與示範
已核驗的公開連結,涵蓋 Jev 1.13 整合及 Jev 系列內容。社群示範不等於獨立模型基準測試。
X (Twitter)
TypeSafe AI ·
Jev 系列:TypeSafe 宣布公開亮相,並邀請開發者申請使用 Jev。
we are officially out of stealth! join the frontier and get access to Jev on our website (link on profile)
查看原文TypeSafe AI ·
Jev 系列:官方帳號宣布取消候補名單,並提供 TypeSafe 控制台入口。
Jev is now available to everyone. No waitlist. Start using it here: https://console.typesafe.ai/
查看原文Ruirui Wan ·
社群整合透過 OpenRouter 呼叫 Jev 1.13,協助引導 Ego Lite 中的瀏覽器操作。
https://pbs.twimg.com/media/HSf25e4aoAAv_lv.jpghttps://pbs.twimg.com/media/HSf25exbsAAIdXd.jpghttps://pbs.twimg.com/media/HSf25e2awAAA5uc.jpg查看原文Reddit
Tried TypeSafe's new "decision-only" model (Jev) as an agent router: 145-271ms end to end, curious if others have tested it
blackbarata ·
Jev 系列:開發者分享兩次代理分流實驗,並討論如何處理不確定的決策。
查看原文I built a side project to test TypeSafe's Jev model with no generative LLM that scores your project idea
stemonte ·
Jev 系列:開源示範專案透過平行問題評估和分類,為專案構想評分。
查看原文What I measured calling Jev (TypeSafe's decision model) through OpenRouter in Hermes
PoppaBear1950 ·
社群實測報告介紹透過 OpenRouter 整合 Jev 1.13,涉及請求格式、回應結構和錯誤處理陷阱。
展開全文
I spent today wiring TypeSafe's Jev — the "System One" decision model that launched on Sept 15 — into a decision gate that routes coding tasks. Most of the time went into finding the endpoint, so here is what's actually true as of 2026-09-20. Everything below is measured, not read off the docs. The endpoint nobody points you at It works on OpenRouter with an ordinary OPENROUTER_API_KEY: POST https://openrouter.ai/api/alpha/decisions Content-Type: application/json Authorization: Bearer $OPENROUTER_API_KEY { "model": "typesafe/jev-1.13", "state": "help! my payouts have been failing for 3 days", "questions": { "tier": { "type": "choice", "instructions": "pick a tier", "criteria": { "billing": "payments", "technical": "bugs" } } } } Response: { "model": "typesafe/jev-1.13-20260917", "answers": { "tier": { "type": "choice", "choice": "billing", "probabilities": { "billing": 0.87, "technical": 0.13 }, "confidence": 0.82 } }, "usage": { "input_tokens": 312, "output_tokens": 35, "cost": 1.31e-05 }, "provider": "TypeSafe" } The traps, each one measured: /chat/completions with typesafe/jev → 400 "is not a valid model ID". Jev does not generate text, so it isn't an autoregressive chat model. Don't try to shim it into standard completions. /api/v1/decisions → 404. The route is currently live under /api/alpha, not /api/v1. Wrapping the body in {"decisionsRequest": {...}} → 400 invalid_type ... path: ["model"]. The body must be flat: model, questions, and state at the root level. GET /api/v1/models (447 entries) lists no typesafe/* ID, and GET /api/v1/models/typesafe/jev-1.13 404s. Yet GET /api/v1/models/typesafe/jev-1.13/endpoints returns 200 with the full provider snapshot, pricing, context, and uptime. Any SDK preflight asserting "does the model exist in the list?" will falsely fail. Make a live call instead. There is no typesafe/jev-latest alias on OpenRouter; that alias throws an error. typesafe/jev-1.13 is the only working ID, and every response names the dated snapshot it served. Measured latency and cost: 239–430 ms per decision, $1.3–2.7e-05 per invocation (roughly $13–27 per million decisions). Output is unmetered. The answer shapes are not uniform choice gives you choice + probabilities + confidence. noul (yes/no) does not: {"type": "noul", "noul": 0.01} For noul, the value is a flat scalar float between 0.0 and 1.0 representing true/yes likelihood (e.g., 0.01 means overwhelmingly false), not a structured dict with probability labels. I had code reading answers.x.probabilities.true, which silently defaulted to 0.0 — so a "does this patch match the intent?" gate answered no to everything, including good patches. If you port Jev snippets around, check that field shape. The failure mode worth designing against My first version of the gate had the classic fallback: except Exception: return choices[0]. With a live key pointed at the wrong route, every call 400'd and the gate answered anyway: triage("refactor auth across 14 modules") → bash_direct risk("auth models, 31 dependents") → low (would have auto-applied) verdict(exit 1, "could not read Username") → complete (would have ended the loop) Confident, cheap, and wrong in the direction that costs you. The fix that stuck: the gate returns unavailable plus a default chosen from the stakes — fail open to the cheapest path for low-stakes routing (restricted strictly to non-mutating checks), fail closed (high, abort) for the risky ones — and the process exit code explicitly indicates whether you got a model verdict or a policy default. Two things I'd have missed without an end-to-end smoke test git diff is blind to files a coding agent creates: they're untracked, so a patch review gate sees an empty diff and rejects a perfectly good change. Use git add -N . && git diff (or git add -A && git diff --cached, but remember to unstage cleanly). I pointed the harness log inside the worktree, so __pycache__ and the run log itself landed in the diff. The gate called that scope creep (noul 0.47 vs 0.94 for the clean version) and it was completely right — plus the messier diff cost 2x because you're billed on input token size. Keep run logs outside your worktree or in .gitignore. Happy to share the routing-gate code if anyone wants it; it's stdlib Python and talks directly to the OpenRouter alpha endpoint. Verify the alpha route before you build on it — I measured this on one box today.
YouTube
Jev Explained: Demos and Use Cases
Syntax
Jev 系列:透過示範和實際使用情境介紹模型的運作方式。
查看原文What is Jev and How to Use it?
Codevolution
Jev 系列:面向開發者的教學,介紹結構化 AI 決策及如何在應用程式中使用 Jev。
查看原文I Tested Jev on 12 Real Use Cases. My Honest Thoughts.
Nate Herk | AI Automation
Jev 系列:創作者探索十二種使用情境,並分享試用模型的體驗。
查看原文