Deine Checkliste für den Wechsel von Jev

1. Bestehende Integration erfassen

   Sichere deine bisherige Konfiguration und repräsentative Testfälle. Prüfe Fragetypen, Optionen, Bilder, Antwortauswertung und Wiederholungen. Bewahre den bisherigen Anbieter als bewusste Rückfalloption auf.

2. Basis-URL und Pfad setzen

   Verwende https://api.decisionmodels.io als Basis-URL und POST /v1/systemone für Text. Entferne einen vorhandenen /v1-Suffix, wenn dein Client den Pfad selbst ergänzt. Prüfe den tatsächlich gesendeten Pfad.

3. Eigenen API-Schlüssel erstellen

   Erstelle einen Decision-Models-Schlüssel im Dashboard und sende ihn als Authorization: Bearer. TypeSafe-Schlüssel, Guthaben und Konten werden nicht übertragen. Speichere den Schlüssel in einer Umgebungsvariable.

4. Modell-ID ersetzen

   Ersetze die TypeSafe-Modell-ID durch eine verfügbare Decision-Models-ID, etwa s1-fast. Prüfe GET /v1/models, statt einen TypeSafe-Alias zu übernehmen.

5. Verarbeitungsregion bewusst wählen

   Setze zum Beispiel S1-Region: eu. Zulässig sind eu oder global, soweit dein Schlüssel die Stufe erlaubt; ohne Header gilt dessen Standard. EU-Anfragen bleiben in der EU. Bei Peer-to-Peer erlaubt erst die Zustimmung am Schlüssel eine Verarbeitung weltweit. Verarbeitung und Vertragsbedingungen.

6. Fragen auf Modellgrenzen aufteilen

   Für s1-pro gelten bis zu 3 Textfragen je Anfrage, für s1-fast 1 und s1-vision 1. Weitere Fragen musst du selbst aufteilen. Der Dienst verwirft oder teilt sie nicht stillschweigend auf; zu viele Fragen ergeben 400 request_limit_exceeded. Prüfe außerdem Token- und Optionsgrenzen unten.

7. Fragetypen und Bilder prüfen

   Behalte state und das nach Fragenamen geordnete questions-Objekt bei. Nutze die unten beschriebenen Kriterienformen. Für Bilder verwendest du s1-vision über POST /v1/multimodal mit genau einem Bild im images-Array. Unterstützt sind PNG, JPEG und WebP als Daten-URL oder öffentliche HTTPS-URL; höchstens 4 MiB dekodiert und 2.000.000 Pixel. Die Textbeispiele unten testen keine Bildanfragen.

8. Antworten und Abrechnung auswerten

   Lies Ergebnisse anhand der Fragenamen unter answers. Erfasse usage.input_tokens, usage.output_tokens und usage.decisions sowie die gemeldete model_version. Tokenzahlen stammen vom Modell, einschließlich Bildpositionen bei Bildanfragen. Nutze für Geldbeträge die Nutzungsbelege im Dashboard; rechne keine Zeichen in abrechenbare Tokens um.

9. Fehler, Wiederholungen und Rückfall testen

   Teste ungültige Schlüssel, fehlendes Guthaben, Modellgrenzen, Ratenlimits und Zeitüberschreitungen. Nutze die Fehlercodes unten. Prüfe die Ergebnisse auf deinen eigenen Fällen und führe den Wechsel erst nach deinem Abnahmetest durch. Ein lokaler Vertragstest belegt keine Modellqualität oder Produktionsverfügbarkeit.

• noul: Ja/Nein-Frage; die Antwort noul ist die Wahrscheinlichkeit für „ja“.
• choice: criteria ist ein Objekt mit mindestens zwei stabilen Options-IDs. Die Antwort nennt choice, confidence und probabilities.
• score: criteria ist ein geordnetes Array mit mindestens zwei Stufen. score ist der wahrscheinlichkeitsgewichtete Mittelwert der Stufen-Indizes ab 0 und kann Nachkommastellen haben.

Jede Frage zählt einschließlich State, Kriterien und Prompt-Vorlage; bei s1-vision zählen auch Bildpositionen. Prüfe die vollständigen Eingabegrenzen.

Stand: 27. Oktober 2026. Die datierte Jev-Alternative-Seite und die Migrationshinweise (EN) beschreiben die Vertragsgrenze: eigene Schlüssel, Modell-IDs, Verarbeitungsstufen, Abrechnung, Limits, Metadaten und Fehler. Ein Wechsel zu einem anderen Modell erfordert eigene Ergebnistests. Bytegenaue Kompatibilität wird nicht behauptet.

Bewertungsrubriken brauchen bei uns mindestens zwei Stufen; TypeSafes veröffentlichtes Schema erlaubt auch eine einzelne Stufe. Überschreitungen der Fragegrenze sind nicht wiederholbare Fehler.

Mit Idempotency-Key erhältst du während einer laufenden Anfrage 202 in_progress. Nach Abrechnung oder bei unklarem Abrechnungsstatus folgt 409 idempotency_replay_unavailable mit Beleg und ohne zweite Belastung, aber ohne gespeicherte Antwort. Nach bestätigtem Fehlschlag ohne Antwort und Belastung darfst du denselben Schlüssel und Inhalt erneut senden. Ein anderer Inhalt unter demselben Schlüssel ergibt 409 idempotency_conflict. Nur eine bewusst neue Inferenz erhält einen neuen Schlüssel.

Jede der folgenden Dateien wurde unverändert gegen einen isolierten lokalen HTTP-Mock unseres veröffentlichten Vertrags getestet. Geprüft wurden Methode, Pfad, Bearer-Schlüssel, S1-Region und JSON-Inhalt sowie die Auswertung einer simulierten Antwort mit usage und model_version. Es gab keine Anfrage an den produktiven Dienst.

Setze DECISIONMODELS_API_KEY auf deinen Schlüssel. Die optionale Variable DECISIONMODELS_BASE_URL kann für Tests auf deinen lokalen Mock zeigen; ohne sie gilt die öffentliche API-Basis. Python-Beispiele benötigen Python 3.10 und die jeweils genannte Paketversion. Das Fetch-Beispiel ist JavaScript-kompatibles TypeScript, getestet mit Node.js 20.19.4.

LiteLLM entfernt das Anbieterpräfix typesafe/ vor dem Senden; am Server kam im Test s1-fast an. Für Ollama wurde nur der Python-Client getestet, nicht die CLI. Typisierte SDKs können zusätzliche Metadaten wie model_version verwerfen; die direkten HTTP-Beispiele erhalten sie.

curl --fail-with-body --silent --show-error --max-time 15 \
  "${DECISIONMODELS_BASE_URL:-https://api.decisionmodels.io}/v1/systemone" \
  -H "Authorization: Bearer $DECISIONMODELS_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'S1-Region: eu' \
  --data '{"model":"s1-fast","state":"Mia owns a red bicycle.","questions":{"color":{"type":"choice","instructions":"Which color is the bicycle?","criteria":{"red":null,"blue":null}}}}'

import os
import requests

base = os.environ.get("DECISIONMODELS_BASE_URL", "https://api.decisionmodels.io")
response = requests.post(
    base + "/v1/systemone",
    headers={
        "Authorization": "Bearer " + os.environ["DECISIONMODELS_API_KEY"],
        "S1-Region": "eu",
    },
    json={
        "model": "s1-fast",
        "state": "Mia owns a red bicycle.",
        "questions": {"color": {
            "type": "choice",
            "instructions": "Which color is the bicycle?",
            "criteria": {"red": None, "blue": None},
        }},
    },
    timeout=15,
)
response.raise_for_status()
print(response.json())

// JavaScript-compatible TypeScript; native fetch in Node.js.
const base = process.env.DECISIONMODELS_BASE_URL ?? "https://api.decisionmodels.io";
const response = await fetch(`${base}/v1/systemone`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.DECISIONMODELS_API_KEY}`,
    "Content-Type": "application/json",
    "S1-Region": "eu",
  },
  body: JSON.stringify({
    model: "s1-fast",
    state: "Mia owns a red bicycle.",
    questions: { color: {
      type: "choice",
      instructions: "Which color is the bicycle?",
      criteria: { red: null, blue: null },
    } },
  }),
  signal: AbortSignal.timeout(15000),
});
if (!response.ok) throw new Error(`HTTP ${response.status}: ${await response.text()}`);
console.log(await response.json());

import os
import litellm

response = litellm.systemone(
    model="typesafe/s1-fast",
    api_base=os.environ.get("DECISIONMODELS_BASE_URL", "https://api.decisionmodels.io"),
    api_key=os.environ["DECISIONMODELS_API_KEY"],
    extra_headers={"S1-Region": "eu"},
    state="Mia owns a red bicycle.",
    questions={"color": {
        "type": "choice",
        "instructions": "Which color is the bicycle?",
        "criteria": {"red": None, "blue": None},
    }},
    timeout=15,
)
print(response.model_dump())

import os
from ollama import Client

client = Client(
    host=os.environ.get("DECISIONMODELS_BASE_URL", "https://api.decisionmodels.io"),
    headers={
        "Authorization": "Bearer " + os.environ["DECISIONMODELS_API_KEY"],
        "S1-Region": "eu",
    },
    timeout=15,
)
response = client.systemone(
    model="s1-fast",
    state="Mia owns a red bicycle.",
    questions={"color": {
        "type": "choice",
        "instructions": "Which color is the bicycle?",
        "criteria": {"red": None, "blue": None},
    }},
)
print(response.model_dump())

Client-Dokumentation: LiteLLM System One · Ollama Python 0.6.3. Die Tests gelten für die genannten Versionen und das gezeigte Textbeispiel.

Behandle insbesondere diese Codes; die vollständigen Regeln stehen unter Fehler und Wiederholungen (EN).

• 400 invalid_request, request_limit_exceeded: Schema oder Modellgrenzen korrigieren; nicht unverändert wiederholen.
• 401 invalid_api_key, 402 insufficient_credit, 403 tier_not_allowed, 404 unknown_model: Schlüssel, Guthaben, Berechtigung oder Modellwahl korrigieren.
• 413 payload_too_large, 422 unsupported_modality: Eingabe verkleinern oder passende Modalität wählen.
• 429 rate_limit_exceeded: Retry-After beachten.
• 503 model_unavailable, capacity_limit, 504 inference_timeout: Die dokumentierte Wartezeit und den Abrechnungsstatus prüfen, bevor du erneut sendest. EU-Anfragen wechseln nie in eine Region außerhalb der EU.

Prüfe die vollständigen Migrationshinweise und deine eigenen Testfälle, bevor du produktive Anfragen umstellst.