Passthrough-API

​

Übersicht

http://localhost:8080/p/anthropic

POST /p/anthropic/v1/messages

POST /messages

​

Funktionsweise

/p/{provider}/{endpoint}

/p/anthropic/messages
/p/anthropic/v1/messages

Authorization: Bearer change-me

​

Zugriffskontrolle

• GOMODEL_MASTER_KEY – hat immer Passthrough-Zugriff.
• Verwaltete API-Keys – werden standardmäßig ohne Passthrough-Zugriff erstellt. Keys, die bereits vor Einführung des Passthrough-Zugriffs existierten, behalten ihn. Ein Key ohne Zugriff erhält 403 mit dem Fehlercode passthrough_access_denied.
• Modell-Allowlists – ein Body, der ein model nennt, wird gegen die Allowlist des Aufrufers geprüft. Ein Request, der kein Modell nennt, wirkt auf den gesamten Provider, daher muss die Allowlist den gesamten Provider (anthropic/) oder alles (/) freigeben. Ein auf anthropic/claude-sonnet-4-6 beschränkter Key kann POST /p/anthropic/v1/messages für dieses Modell aufrufen, aber nicht GET /p/anthropic/v1/models.

curl -X PUT "http://localhost:8080/admin/auth-keys/${KEY_ID}/passthrough-access" \
  -H "Authorization: Bearer $GOMODEL_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"passthrough_access": true}'

​

Beispiel mit dem Anthropic SDK

import os
from anthropic import Anthropic

client = Anthropic(
    base_url="http://localhost:8080/p/anthropic",
    auth_token=os.environ["GOMODEL_MASTER_KEY"],
)

message = client.messages.create(
    model="claude-3-haiku-20240307",
    max_tokens=16,
    messages=[
        {
            "role": "user",
            "content": "Reply with exactly ok",
        }
    ],
)

print(message.content[0].text)

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  baseURL: "http://localhost:8080/p/anthropic",
  authToken: process.env.GOMODEL_MASTER_KEY,
});

const message = await client.messages.create({
  model: "claude-3-haiku-20240307",
  max_tokens: 16,
  messages: [
    {
      role: "user",
      content: "Reply with exactly ok",
    },
  ],
});

console.log(message.content[0].text);

​

Aktuelle Einschränkungen

• openai, anthropic, openrouter, kilo, zai, sglang, vllm, llamacpp, llmd, deepseek, edenai und jev sind standardmäßig aktiviert.
• Chutes unterstützt Passthrough, erfordert aber eine explizite Freischaltung durch den Betreiber, da Passthrough provider-native Routen weiterleiten kann, die kein Modell identifizieren. Fügen Sie chutes nur dann zu ENABLED_PASSTHROUGH_PROVIDERS hinzu, wenn Sie diese Schnittstelle bewusst freigeben möchten.
• GoModel übersetzt weder Request-Bodys noch Response-Bodys von Passthrough.
• Das model, das ein JSON-Passthrough-Body nennt, wird unabhängig von der Body-Größe bis zum konfigurierten Body-Limit gegen die Modell-Allowlist des Aufrufers geprüft; ein größerer Body wird mit dem eigenen Fehler des Limits abgelehnt. Ein Body, der das model-Feld auf oberster Ebene wiederholt, wird abgelehnt, da sonst der Upstream entscheiden würde, welches gilt. Ein Request, der kein Modell nennt, benötigt eine providerweite Freigabe (siehe Zugriffskontrolle).
• Das Upstream-Konto wird gemeinsam genutzt. Ein Key mit Passthrough-Zugriff kann dort Objekte erreichen, etwa Dateien oder Batches, die andere Keys erstellt haben. Gewähren Sie passthrough_access nur Keys, denen Sie das gesamte Provider-Konto anvertrauen.
• Provider-native Fehler-Bodys und Statuscodes werden weitergereicht, statt in OpenAI-kompatible Responses umgewandelt zu werden.
• Features, die von OpenAI-kompatiblen Request- oder Response-Formen abhängen, gelten für Passthrough-Traffic möglicherweise nicht in gleicher Weise wie für /v1-Traffic.

​

Zugehörige Umgebungsvariablen

ENABLE_PASSTHROUGH_ROUTES=true
ALLOW_PASSTHROUGH_V1_ALIAS=true
ENABLED_PASSTHROUGH_PROVIDERS=openai,anthropic,openrouter,kilo,zai,sglang,vllm,llamacpp,llmd,deepseek,edenai,jev