The Decisions endpoint
OpenRouter's official classification cookbook calls https://openrouter.ai/api/alpha/decisions with an OPENROUTER_API_KEY and the model id typesafe/jev-1.13. It sends state and typed questions, then validates the returned answers — the same request shape as the direct TypeSafe API, covered in the API and SDK guide.
{
"model": "typesafe/jev-1.13",
"state": { "message": "The upload fails after I choose a PDF." },
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle this message?",
"criteria": { "technical": "Errors and broken product functionality", "billing": "Invoices and charges", "other": "None of those" }
}
}
}
This is a request-shape example, not a captured model result. The endpoint is an alpha surface, so check the current cookbook for the version and provider-specific error behavior rather than pinning this page's values forever.
jev-router is a different product
The public OpenRouter model catalogue also lists typesafe/jev-router, which selects a model for a request. That is routing, not a typed decision: it returns "which model should answer," not a Choice, Score or Noul for your question. A normal chat-model selector therefore does not tell you which Decisions models or aliases the decision endpoint will accept.
Keep the two roles apart when you write tests. A routing call is evaluated by whether the chosen model was a good fit; a decision call is evaluated by whether the answer was correct and calibrated.
Community clients and recipes
Because the endpoint follows the System One shape, community clients wrap it for many hosts. jev-cookbook documents tested recipes such as support triage and database indexing over OpenRouter. jev-openrouter-skill and openrouter-jev-mcp document an agent skill and an MCP server. jevymarket documents a prediction-market bot driven by Jev via OpenRouter, openclaw-jev-openrouter documents another integration, and philippdubach/pi-jev-router uses OpenRouter as the transport for a Pi router.
These are community projects, not official OpenRouter or TypeSafe products. Their READMEs own the compatibility and cost claims; the coding-agent overview explains how a router differs from a decision tool.
Authentication, versions and errors
Decide up front which credential you will use. The direct TypeSafe endpoint reads TYPESAFE_API_KEY; the OpenRouter route reads OPENROUTER_API_KEY. Do not ship either key in a browser bundle, and keep the call on a server or in a local process.
- Pin the model id you tested, and know whether an alias can move to a new release.
- Handle a timeout, a quota or rate-limit response, and a malformed or missing answer.
- Log which model actually answered so comparisons stay honest.
- Validate the returned answers against the questions you sent before your code uses them.
TypeSafe direct vs OpenRouter
| Consideration | Direct TypeSafe API | OpenRouter Decisions |
|---|---|---|
| Endpoint | POST https://api.typesafe.ai/v1/systemone | https://openrouter.ai/api/alpha/decisions |
| Credential | TypeSafe console key | OpenRouter key |
| Maturity | Documented product API | Documented alpha surface |
| Model id | TypeSafe model selector | Versioned id such as typesafe/jev-1.13 |
| Extra options | Direct SDKs and adapters | Provider routing and billing across models |
A small first integration
Begin with one decision and a labeled set of your own examples, and validate transport and response handling without granting the model authority over an external action. Then test ambiguous inputs, missing confidence, malformed responses and retries. If your goal is a chat model router rather than a typed decision, read the integrations overview first; if your goal is a pip-installable client, start with the SDK section.