API-Referenz

SUB&SUB stellt einen Multi-Provider-Relay unter https://api.subnsub.com/v1 bereit. OpenAI-Clients sprechen /v1/chat/completions an; Anthropic-Clients /v1/messages. Derselbe sk-cf-...-Key routet beide — du wählst das Modell im Request-Body und der Relay wählt das Upstream.

Schnellstart

Drei Dinge, die du brauchst:

1. Base-URL: https://api.subnsub.com/v1 (OpenAI-Clients) oder https://api.subnsub.com (Anthropic-Clients — das SDK hängt /v1/messages selbst an)
2. API-Key: sk-cf-..., ausgestellt über die Konsole
3. Modell: eines der 21 verifizierten Modelle — z. B. gpt-5.4-mini oder claude-haiku-4.5

Authentifizierung

Jede Anfrage muss einen Authorization: Bearer sk-cf-...-Header tragen. Keys werden über die Konsole ausgestellt und als SHA-256-Hashes gespeichert — sobald du den Erstellungsbildschirm verlässt, ist der Klartext für immer weg, also speichere ihn sofort.

Endpoints

POST /v1/chat/completions

Sende eine Chat-Completion-Anfrage. Die Request-Struktur entspricht der OpenAI Chat Completions API — die OpenAI-SDKs funktionieren unverändert.

POST /v1/messages

Anthropic-nativer Endpoint für die claude-*-Modelle — das Anthropic-SDK (anthropic-sdk-python, @anthropic-ai/sdk, claude-code) funktioniert unverändert gegen diesen Pfad. Richte deine Base-URL auf https://api.subnsub.com und authentifiziere dich über den x-api-key-Header (die Authorization-Bearer-Form funktioniert ebenfalls, falls dein Client sie bevorzugt).

GET /v1/models

Listet die Modelle auf, die du tatsächlich aufrufen kannst. Der Relay führt die OpenAI- und Anthropic-Kataloge von sub2api zusammen und filtert auf die 21 herunter, die wir Ende-zu-Ende gegen den aktuellen Account-Pool getestet haben — Phantom-IDs, die zur Routing-Zeit 503 liefern, oder beim ersten Token ein Upstream-400, werden ausgeblendet. Ist jedes konfigurierte Upstream unerreichbar, gibt der Endpoint 502 models_unreachable zurück statt einer irreführenden leeren Liste.

# sample response (truncated)
{
  "object": "list",
  "data": [
    { "id": "gpt-5.4-mini",      "type": "model", ... },
    { "id": "gpt-5.4",           "type": "model", ... },
    { "id": "claude-sonnet-4.5", "type": "model", ... },
    { "id": "claude-haiku-4.5",  "type": "model", ... },
    ...
  ]
}

Verfügbare Modelle

Zwei Upstream-Familien. Die 7 OpenAI-Modelle routen zu geteilten Accounts der ChatGPT-Klasse; die 14 Claude-Modelle routen über einen Kiro-Reverse-Proxy auf AWS CodeWhisperer. Die Sätze pro Token hängen vom Tier ab (siehe Preise) — derselbe Key funktioniert für beide.

OpenAI

Anthropic

Reasoning-Aufwand

Jedes OpenAI-Modell oben ist ein Reasoning-Modell — das Backend kann mehr oder weniger "Denk"-Tokens aufwenden, bevor es sichtbare Ausgabe erzeugt. Setze reasoning_effort im Request-Body von OpenAI /v1/chat/completions, um das Budget zu steuern. Verwende für Claude das Anthropic-native thinking-Request-Feld (oder wähle eine -thinking-Modellvariante) — siehe den Abschnitt /v1/messages. Die OpenAI-Modelle akzeptieren dieselben fünf Aufwandswerte:

# Two equivalent forms — pick whichever your SDK supports
{
  "model": "gpt-5.4-mini",
  "reasoning_effort": "high",
  "messages": [ ... ]
}

{
  "model": "gpt-5.5",
  "reasoning": { "effort": "xhigh" },
  "messages": [ ... ]
}

Streaming

Setze "stream": true, um Server-Sent Events zu empfangen. Der letzte Chunk trägt einen usage-Block (wir erzwingen stream_options.include_usage upstream, sodass Token-Zählungen immer ausgegeben werden), danach schließt ein wörtliches data: [DONE] den Stream.

# Streaming format (line by line)
data: {"id":"resp_...","choices":[{"delta":{"content":"Hi"}}]}

data: {"id":"resp_...","choices":[{"delta":{"content":"!"}}]}

data: {"id":"resp_...","choices":[],"usage":{"prompt_tokens":18,"completion_tokens":11,"total_tokens":29}}

data: [DONE]

Websuche

Hänge :online an eine beliebige vom Endpoint unterstützte Modell-ID an, und der Relay führt vor dem Weiterleiten an das Modell eine Websuche durch und stellt die Ergebnisse der Konversation voran, damit die Antwort auf frischen Daten basiert. Der Suffix funktioniert auf /v1/chat/completions und /v1/messages (Letzteres erfordert weiterhin eine claude-*-Basis); es sind keine suchspezifischen Request-Felder erforderlich.

# Same call as before — just :online on the model
curl https://api.subnsub.com/v1/chat/completions \
  -H "Authorization: Bearer sk-cf-xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini:online",
    "messages": [
      {"role": "user", "content": "What did Anthropic ship this week?"}
    ]
  }'

So funktioniert es: Der Relay entfernt :online, nimmt die jüngste User-Nachricht als Query (auf 400 Zeichen begrenzt), ruft Tavily für bis zu 3 Ergebnisse mit extrahiertem Seitentext (falls verfügbar) auf, plus eine optionale von Tavily generierte Zusammenfassung, und stellt sie dann demselben User-Turn als klar abgegrenzten <search_results>-Block voran, bevor die Anfrage upstream gesendet wird. Der Suchaufruf hat einen Timeout von 8 Sekunden. Die Ergebnisse werden bewusst in die User-Rolle eingefügt — niemals in den System-Prompt — sodass nicht vertrauenswürdige Snippets nicht auf System-Priorität angehoben werden können.

Der <search_results>-Block sieht so aus. Ihm geht eine einzeilige Anweisung voraus, die das Modell anweist, den Block als nicht vertrauenswürdige externe Daten zu behandeln und nummerierte Einträge inline zu zitieren:

<search_results query="What did Anthropic ship this week?" retrieved="2026-05-21">
Summary: <short LLM-generated synthesis of the result set>

[1] Anthropic launches Opus 4.8
URL: https://www.anthropic.com/news/opus-4-8
<extracted page text, or short snippet if extraction failed — up to ~2000 chars>

[2] ...
</search_results>

Wann :online verwenden

Der Relay macht einen einzigen Tavily-Aufruf pro Anfrage und fügt die Ergebnisse ein — es ist keine agentische Suchschleife. Das Modell entscheidet nicht anhand des Gesehenen, erneut zu suchen, wie es Perplexity Sonar oder das Browse-Tool von ChatGPT tun. Plane diese Einschränkung ein:

Formuliere die letzte User-Nachricht als eigenständige Suchanfrage. Die Suche läuft gegen den wörtlichen Text deines jüngsten User-Turns (auf 400 Zeichen begrenzt), sodass konversationelle Rückfragen wie "und was ist mit der neuesten Version?" zu nutzlosen Queries ohne Kontext werden. Wiederhole in einem Mehrturn-Chat das Thema, wenn du :online hinzufügst — z. B. "neueste Version des Anthropic Python SDK" statt "die neueste".

Für Fragen, die mehrstufige Synthese brauchen (Vergleichen-und-Gegenüberstellen, tiefe Recherche), zerlege sie in mehrere Turns und füge jedem :online hinzu. Das Modell liest die frischen Ergebnisse jedes Turns; du steuerst die nächste Query manuell. Beachte, dass der eingefügte <search_results>-Block nur upstream gesendet wird — er wird nicht an deinen Client zurückgespiegelt und nicht in die nächste Anfrage übernommen. Wenn also ein späterer Turn von Details früherer Quellen abhängt, bitte das Modell, sie in seiner sichtbaren Antwort zusammenzufassen. Ein One-Shot-Recherchemodus wird nicht unterstützt.

Fehler

Der Umschlag hängt davon ab, welchen Endpoint du aufgerufen hast — der Relay gibt Fehler im Protokoll zurück, das zum SDK des Aufrufers passt, und Upstream-Fehler werden wörtlich durchgereicht.

OpenAI-Pfade (/v1/chat/completions, /v1/responses, /v1/models) — OpenAI-Umschlag:

{ "error": { "message": "...", "type": "...", "code": "..." } }

Anthropic-Pfade (/v1/messages, /v1/messages/count_tokens) — Anthropic-Umschlag:

{ "type": "error", "error": { "type": "...", "message": "..." } }

Der Anthropic-Umschlag verwendet eine andere Struktur — kein code-Feld, und der Diskriminator type: "error" steht auf oberster Ebene (wobei das innere error.type die Kategorie angibt, z. B. authentication_error, invalid_request_error, permission_error, api_error). Anthropic-SDKs parsen diese Struktur bereits; gewöhnliche OpenAI-SDK-Fehlerhandler tun das nicht, rufe /v1/messages also mit einem Anthropic-SDK auf (oder nutze rohes HTTP).

Die Statuscodes sind über beide Protokolle hinweg die kanonischen HTTP-Codes:

Preise & Abrechnung

Pay-as-you-go, abgerechnet pro Token in Mikrodollar (1 Mikro = $0,000001 = 1/10.000 Cent), sodass Anfragen unter einem Cent genau erfasst werden. Die Sätze gelten pro 1M Tokens, nach Tier — siehe die Modelltabelle, welchem Tier jedes Modell zugeordnet ist.

Die Sätze des Ultra-Tiers entsprechen Anthropics veröffentlichtem Opus-Listenpreis — direkte Weitergabe, ohne Marge. Die anderen Tiers laufen dank der gepoolten Abo-Grundlage unter ihren Upstream-Sätzen.

Reasoning-Tokens (wenn du reasoning_effort bei OpenAI setzt oder eine Claude--thinking-Variante nutzt) zählen als Ausgabe-Tokens zum Tier-Satz des Modells — es gibt keinen separaten Aufschlag für hohen Aufwand, aber eine tief denkende Anfrage kann leicht 10–50× mehr Ausgabe-Tokens erzeugen als eine ohne Aufwand, sodass die Dollar-Rechnung entsprechend skaliert.

Anthropic-Prompt-Caching wird als separater Posten abgerechnet: Cache-Writes mit 1,25× und Cache-Reads mit 0,10× des Eingabe-Satzes des Tiers. Ein haiku-4.5-Cache-Hit kostet also 0.20 × 0.10 = $0.02 per 1M tokens, und ein sonnet-4.5-Cache-Hit kostet 0.75 × 0.10 = $0.075 per 1M tokens. Cache-Spalten werden in jeder Settle-Zeile erfasst, sodass die Konsole die Aufschlüsselung zeigen kann.

Das Guthaben wird in Echtzeit abgezogen, sobald jede Anfrage zurückkehrt — bei Streaming-Anfragen läuft die Abrechnung, nachdem der [DONE]-Chunk eingetroffen ist. Sieh dir dein Live-Guthaben und die Abrechnungen pro Anfrage unter /console#billing an.

Rate-Limits

Heute keine Rate-Limits pro Key. Die Nebenläufigkeit des Upstream-Account-Pools & das serverseitige Throttling von OpenAI gelten; wenn du an diese stößt, gibt der Relay 429 mit einem retry-after-Header zurück. Limits für RPM / TPM pro Key kommen nach dem MVP.