[Feature] Support TypeSafe Jev (System One decisions API)

[Gyarados4157]

Motivation

TypeSafe's Jev (https://typesafe.ai, docs: https://docs.typesafe.ai/api) is a decision-only model: no chat completions, no streaming text. It is increasingly used in agent pipelines (routing, classification, scoring, moderation gates) alongside the chat models CLIProxyAPI already proxies.

Currently there is no way to put Jev behind CLIProxyAPI:

• Built-in channels are OAuth / API-key for vertex, aistudio, antigravity, claude, codex, kimi, xai, meta (plus *-api-key variants). No typesafe/jev channel exists.
• The generic openai-compatibility upstream requires an OpenAI-compatible POST /v1/chat/completions endpoint, which Jev does not speak.

Jev API shape (for reference)

• Base URL: https://api.typesafe.ai
• OpenAPI (anonymous): https://api.typesafe.ai/openapi.json, ReDoc at /redoc
• Decision call: POST /v1/systemone with { state, questions, model }, where questions are typed noul / choice / score; response carries per-question probability + confidence + token usage.
• Discovery: GET /v1/models
• Auth: Bearer API key (TYPESAFE_API_KEY, created at console.typesafe.ai)
• Gateways also expose it (OpenRouter Decisions API, Cloudflare Workers AI typesafe/jev, Vercel AI Gateway typesafe-ai/jev), but none of them is /v1/chat/completions either.

Key point: Jev is not a chat model — there is no text generation and no streaming — so protocol translation from chat/completions does not make sense. What is needed is a passthrough provider, not a chat adapter.

Proposal

Add a new provider type (e.g. typesafe-api-key, mirroring gemini-api-key / claude-api-key / codex-api-key), with:

• base-url (default https://api.typesafe.ai), api-key-entries, models (name/alias) so GET /v1/models can list Jev models,
• Passthrough of POST /v1/systemone (and GET /v1/models) to the configured upstream, with per-key load balancing / cooldown / retry consistent with other -api-key providers,
• Management API CRUD consistent with other providers.

Out of scope (at least initially): translating Jev decisions into chat completions; gateway-specific variants (OpenRouter/Cloudflare/Vercel) could come later via base-url override if the request shape matches.

Use case

Single local endpoint + single key management for both generative chat models and Jev decision calls in agent harnesses (e.g. Pi / Claude Code / Codex agents calling Jev MCP tools through the proxy for usage accounting, failover, and local routing).

Happy to provide a sample state + questions request/response pair or test against the live API if helpful.

[IRONICBo]

One proxy behavior worth locking down is avoiding silent failover from one Jev model or provider to another after a request is accepted. In Jev Social we persist the model identity, candidate set, and confidence beside the browser evidence; a cross-provider retry can make calibration and audit history ambiguous even when the response schema matches.

It may be safer to retry only transport failures against the same model, then surface the actual provider and model plus the upstream request ID in response metadata. The caller can still own the low-confidence or unavailable-model fallback explicitly.