state (den zu bewertenden Text oder Datensatz) und eine Map typisierter
Fragen, und die Antwort ist eine kalibrierte Wahrscheinlichkeit pro Frage.
Kev ist eine Familie kleiner Open-Weight-Modelle,
die dieselbe API implementieren, sodass ein einziger Provider-Typ jev beide abdeckt.
Es gibt drei Fragetypen:
GoModel stellt
jev-Modelle auf zwei Arten bereit:
- Die Decisions API von OpenAI unter
POST /v1/decisions, die dieselben drei Arten von Fragen stellt (predicatefürnoul). GoModel übersetzt den Request in System One und die Antwort zurück, sodass OpenAI SDKs und fürgpt-6-lunageschriebene Clients unverändert mit Jev und Kev funktionieren. - System One selbst unter
POST /v1/systemone, nativ ohne Übersetzung weitergeleitet, für die TypeSafe SDKs; dieser Endpunkt ist auch verfügbar, wenn nur einopenrouter-Provider konfiguriert ist. Passthrough unter/p/jev/...erreicht alle anderen Upstream-Routen.
/responses und /v1/embeddings geben für jev-Modelle
invalid_request_error zurück und verweisen auf beide Entscheidungs-Endpunkte.
Konfiguration
Für die gehostete API genügt der Key als gesamte Einrichtung:Die Standard-Basis-URL ist
https://api.typesafe.ai, der Origin, den die
TypeSafe SDKs verwenden; ein abschließendes /v1 wird akzeptiert und entfernt,
sodass beide Schreibweisen denselben Server ansprechen. Um die gehostete API und
ein lokales Kev parallel zu betreiben, registrieren Sie das zweite unter einem
Namen mit Suffix: JEV_KEV_BASE_URL=... erstellt den Provider jev-kev,
erreichbar unter /p/jev-kev/.... In config.yaml funktioniert jeder Name,
etwa kev: {type: jev, base_url: ...}, und dieser Name erscheint in Logs, in
der Nutzung und als Modellpräfix.Überprüfen
kev-latest als Modell; er antwortet auch auf
jev-latest. Derselbe Request funktioniert unter /p/jev/v1/systemone, diese
Passthrough-Route überspringt jedoch virtuelle Modelle und Guardrails; siehe
den nativen Endpunkt.
Dieselbe Frage über die Decisions API, mit einem OpenAI SDK oder curl:
Die TypeSafe SDKs verwenden
Die SDKs sendenPOST {base_url}/v1/systemone. Richten Sie sie daher auf das
Gateway selbst und authentifizieren Sie sich mit Ihrem GoModel-Key:
TYPESAFE_BASE_URL=http://localhost:8080 und
TYPESAFE_API_KEY=change-me in der Umgebung. Bei mehreren System-One-Providern
benennen Sie das Modell mit seinem Provider (kev/kev-latest) oder über ein
virtuelles Modell.
Die Modellauflistung der SDKs erwartet das Format von TypeSafe, während
/v1/models des Gateways dem OpenAI-Format folgt; listen Sie Upstream-Modelle
über /p/jev/v1/models auf.
System One API
POST /v1/systemone ist ein Gateway-Endpunkt und kein reiner Proxy: Er wendet
virtuelle Modelle, Guardrails auf state, den Response-Cache, Failover, Audit
und Nutzungserfassung an und leitet den Request nativ weiter, ohne ihn zu
übersetzen. /v1/systemone/permute und /v1/systemone/separate von Kev
funktionieren auf dieselbe Weise. Das vollständige Verhalten, einschließlich
OpenRouter, das Jev ebenfalls nativ bereitstellt, finden Sie unter
System One API.
Alle anderen Upstream-Routen sind über Passthrough
erreichbar, ohne virtuelle Modelle, Guardrails oder Caching:
Upstream-Fehler behalten ihren Statuscode, wobei der Body des Providers in der
Fehlermeldung des Gateways enthalten ist: Eine fehlerhafte Frage kommt als
422
von TypeSafe zurück und nennt das betroffene Feld, und 429 oder 529
bedeuten, dass Sie die Last reduzieren und es erneut versuchen sollten.
Modelle, Zugriffskontrolle und Kosten
GET /v1/models listet auf, was der Upstream meldet, als jev/jev-latest usw.
TypeSafe listet seine Aliase auf (jev-latest, jev-preview); ein Kev-Server
listet seinen Checkpoint (kev-latest) und die Aliase, auf die er antwortet.
Versionierte IDs wie jev-1.13.0 werden vom Feld model akzeptiert,
unabhängig davon, ob sie gelistet sind. Die Modelle sind als Utility-Modelle
ohne Generierungsmodus kategorisiert: Sie beantworten /v1/decisions und
/v1/systemone, aber keinen Chat. Ein Provider, dessen Basis-URL die gehostete
API von TypeSafe ist, meldet für seine Modelle die Fähigkeit vision; jede
andere Basis-URL wird als Kev-Server betrachtet, dessen Modelle vision: false
melden, und GoModel lehnt Bild-Requests an sie ab.
Jeder System-One-Request nennt sein Modell, daher wenden sowohl /v1/systemone
als auch die Passthrough-Schnittstelle die
Modell-Allowlist des Aufrufers wie bei jedem anderen
Request an.
Eine festgelegte Version wie jev-1.13.0 funktioniert, ohne deklariert zu
werden; wie nicht gelistete Namen geroutet werden, erfahren Sie unter
Modelle.
usage.input_tokens und usage.output_tokens der Response werden erfasst,
sodass System-One-Aufrufe in der Usage API und im Dashboard unter dem Modell
erscheinen, das geantwortet hat (jev-1.13.0 oder der Kev-Checkpoint). Jev
wird pro Input-Token abgerechnet und ist nicht im Upstream-Modellkatalog
enthalten; deklarieren Sie seine Preise beim Provider, damit diese Zeilen mit
Kosten versehen werden, oder legen Sie sie im
Editor für Preis-Overrides fest: