展开全文
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 系列:创作者探索十二种使用场景,并分享试用模型的体验。
查看原文