Jev currently supports two providers: Vercel AI Gateway, and TypeSafe AI direct. OpenRouter also serves Jev (typesafe/jev-1.13) through a dedicated decisions endpoint, so an OpenRouter key would be a useful third option.
Verified against the live API
typesafe/jev-1.13 is on OpenRouter ($0.042/M input, $0 output) and is reachable only via the decisions endpoint. POST /api/v1/chat/completions rejects it: "typesafe/jev-1.13 is a decisions model and cannot be used with the chat/completions endpoint."
- The working endpoint is
https://openrouter.ai/api/alpha/decisions — no /v1. The published docs page lists /api/v1/api/alpha/decisions, which 404s.
- The request shape is nearly identical to the existing TypeSafe direct call:
{ model, state: { task, skills }, questions: { skill_N: { type: "score", instructions, criteria } } }.
- The response returns
answers.skill_N.score on the same 0–4 scale the rubric already uses, plus usage.input_tokens / usage.output_tokens.
So evaluateJev needs a third branch: different URL, model: "typesafe/jev-1.13", and no ai-gateway-* headers.
Files involved
src/shared.ts:2 — JevProvider union
src/server/gateway.ts:12 — provider enum and error message
src/server/gateway.ts — keys record and status reporting
src/server/recommendations.ts:115 — evaluateJev branch
src/client/gateway-settings.tsx:53 — settings dropdown
One small gap: OpenRouter returns usage.cost as a number, while the parser currently reads providerMetadata.gateway.cost (recommendations.ts:197). Cost would report as unknown unless that is normalized.
Caveat: catalog size
The endpoint rejects large payloads. Testing up to Skillbox's own cap of 200 candidates:
- 120 candidates (~99 KB) — succeeded, 28.7k input tokens
- 150–200 candidates — intermittently failed with
max_tokens_exceeded, or HTTP 520
Context is 32000 tokens, so a large library can exceed what the endpoint accepts. Supporting OpenRouter well probably means chunking candidates, or capping below MAX_CANDIDATES.
Worth noting the endpoint is labelled alpha, so the contract may still move.
Happy to open a PR — I have a patch working end-to-end against a real key, including the settings UI.
Jev currently supports two providers: Vercel AI Gateway, and TypeSafe AI direct. OpenRouter also serves Jev (
typesafe/jev-1.13) through a dedicated decisions endpoint, so an OpenRouter key would be a useful third option.Verified against the live API
typesafe/jev-1.13is on OpenRouter ($0.042/M input, $0 output) and is reachable only via the decisions endpoint.POST /api/v1/chat/completionsrejects it: "typesafe/jev-1.13 is a decisions model and cannot be used with the chat/completions endpoint."https://openrouter.ai/api/alpha/decisions— no/v1. The published docs page lists/api/v1/api/alpha/decisions, which 404s.{ model, state: { task, skills }, questions: { skill_N: { type: "score", instructions, criteria } } }.answers.skill_N.scoreon the same 0–4 scale the rubric already uses, plususage.input_tokens/usage.output_tokens.So
evaluateJevneeds a third branch: different URL,model: "typesafe/jev-1.13", and noai-gateway-*headers.Files involved
src/shared.ts:2—JevProviderunionsrc/server/gateway.ts:12— provider enum and error messagesrc/server/gateway.ts—keysrecord and status reportingsrc/server/recommendations.ts:115—evaluateJevbranchsrc/client/gateway-settings.tsx:53— settings dropdownOne small gap: OpenRouter returns
usage.costas a number, while the parser currently readsproviderMetadata.gateway.cost(recommendations.ts:197). Cost would report as unknown unless that is normalized.Caveat: catalog size
The endpoint rejects large payloads. Testing up to Skillbox's own cap of 200 candidates:
max_tokens_exceeded, or HTTP 520Context is 32000 tokens, so a large library can exceed what the endpoint accepts. Supporting OpenRouter well probably means chunking candidates, or capping below
MAX_CANDIDATES.Worth noting the endpoint is labelled alpha, so the contract may still move.
Happy to open a PR — I have a patch working end-to-end against a real key, including the settings UI.