Jev TypeScript-Schnellstart

Jev passt natürlich zu TypeScript: Du deklarierst die gewünschte Form und bekommst sie typisiert zurück. Hier ist der ganze Weg — Installation, Key, ein lauffähiges Beispiel und die drei Primitive — mehr als den Code gibt es nicht zu lesen.

Wenn du ohnehin schon aus TypeScript nach Jev greifst, willst du wahrscheinlich dasselbe, was dir TypeScript überall sonst gibt: einen Vertrag. Du deklarierst die benötigte Entscheidung — eine choice zwischen diesen Keys, einen score auf dieser Skala, ein kalibriertes Ja/Nein — und bekommst genau diese Form zurück, nie einen überflüssigen Absatz zum Parsen oder ein JSON, das gelegentlich fehlerhaft ist. Das ist der ganze Sinn eines "type-safe" AI-Aufrufs, und der Grund, warum Jev sich in eine typisierte Codebasis einfügt, ohne das defensive Parsing, das du um ein rohes LLM herum schreiben würdest.

1. Installieren

npm i @typesafe-ai/sdk

2. Key setzen

Hol dir einen jv_live_-Key auf der Pricing-Seite und leg ihn in deine Umgebung. Das SDK liest ihn automatisch, sodass nichts Sensibles im Quellcode landet.

export TYPESAFE_API_KEY=jv_live_...

3. Ein 30-Zeilen-Beispiel

Ein Aufruf, zwei typisierte Antworten — eine choice zum Routen und ein kalibriertes Ja/Nein, auf das du eine Schwelle setzen kannst:

import { TypeSafe } from "@typesafe-ai/sdk";

const client = new TypeSafe(); // reads TYPESAFE_API_KEY

const resp = await client.systemOne({
  model: "jev-latest",
  state: "Customer: I was charged twice and I am furious.",
  questions: {
    topic: {
      type: "choice",
      instructions: "What is the issue about?",
      criteria: { billing: "money problems", bug: "broken product" },
    },
    urgent: {
      type: "noul",
      instructions: "Escalate to a human now?",
    },
  },
});

// typed, calibrated — branch on it directly
if (resp.answers.urgent.noul > 0.7) escalate(ticket);
routeTo(resp.answers.topic.choice); // "billing" | "bug"

Beachte: kein Output-Parsing, keine Schema-Validierung, kein Retry-bei-kaputtem-JSON. resp.answers.topic.choice ist einer deiner criteria-Keys, weil das Modell nichts anderes zurückgeben kann, und resp.answers.urgent.noul ist eine Zahl zwischen 0 und 1. Das ist der Typvertrag bei der Arbeit.

Die drei Primitive

• choice — gibt einen deiner Keys zurück, mit Wahrscheinlichkeiten pro Option. Für Routing und Klassifizierung.
• score — gibt eine Zahl auf einer von dir definierten geordneten Skala zurück, plus eine Verteilung. Zum Bewerten von Qualität, Risiko, Priorität.
• noul — ein kalibriertes Ja/Nein mit einer Wahrscheinlichkeit. Für Gates und Checks.

Du kannst mehrere auf einmal in einem Aufruf fragen — das Beispiel oben fragt zwei — und jede kommt unabhängig typisiert zurück. Das reduziert Roundtrips: Eine Anfrage kann denselben Input klassifizieren, bewerten und gaten.

Ein Hinweis zur Kalibrierung

Die von Jev zurückgegebenen Wahrscheinlichkeiten sind kalibriert, d. h. eine 0,8 sollte über viele Aufrufe hinweg etwa 80% der Zeit richtig sein — aber Kalibrierung ist eine Eigenschaft des Aggregats, keine Garantie für eine einzelne Antwort. Setze Schwellen also gegen deine eigenen gelabelten Daten, statt anzunehmen, eine rohe Zahl sei "sicher genug". Der Vorteil eines gehosteten, fixierten Modells ist, dass eine einmal getunte Schwelle über Deploys hinweg bedeutsam bleibt, statt dir unter den Füßen wegzudriften.

Lieber ohne SDK?

Es ist ein einziger POST — sprich das Gateway direkt mit fetch und einem Bearer-Key an:

const r = await fetch("https://jevtypesafeai.com/api/v1/decide", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.JEV_API_KEY}`,
  },
  body: JSON.stringify({ state, questions }),
});
const { answers } = await r.json();

Brauchst du Batch, fertige endpoints oder die vollständige Feldreferenz? Die Docs decken die ganze Oberfläche ab.

FAQ

Siehe auch: API-Docs & Referenz · So nutzt du die API · Jev vs. ein LLM