Passthrough API

​

Przegląd

http://localhost:8080/p/anthropic

POST /p/anthropic/v1/messages

POST /messages

​

Jak to działa

/p/{provider}/{endpoint}

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

Authorization: Bearer change-me

​

Kontrola dostępu

• GOMODEL_MASTER_KEY – zawsze ma dostęp do passthrough.
• Zarządzane klucze API – domyślnie tworzone bez dostępu do passthrough. Klucze, które istniały przed wprowadzeniem dostępu do passthrough, go zachowują. Klucz bez dostępu dostaje 403 z kodem błędu passthrough_access_denied.
• Allowlisty modeli – body, które wskazuje model, jest sprawdzane z allowlistą wywołującego. Request, który nie wskazuje modelu, działa na całym providerze, więc allowlista musi obejmować całego providera (anthropic/) lub wszystko (/). Klucz ograniczony do anthropic/claude-sonnet-4-6 może wywołać POST /p/anthropic/v1/messages dla tego modelu, ale nie 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}'

​

Przykład z 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);

​

Obecne ograniczenia

• openai, anthropic, openrouter, kilo, zai, sglang, vllm, llamacpp, llmd, deepseek, edenai i jev są włączone domyślnie.
• Chutes obsługuje passthrough, ale wymaga jawnego włączenia przez operatora, ponieważ passthrough może przekazywać natywne ścieżki providera, które nie identyfikują modelu. Dodaj chutes do ENABLED_PASSTHROUGH_PROVIDERS tylko wtedy, gdy świadomie chcesz udostępnić tę powierzchnię.
• GoModel nie tłumaczy body requestów ani odpowiedzi passthrough.
• model wskazany w body JSON passthrough jest sprawdzany z allowlistą modeli wywołującego niezależnie od rozmiaru body, aż do skonfigurowanego limitu body; większe body jest odrzucane z błędem tego limitu. Body, które powtarza pole model najwyższego poziomu, jest odrzucane, ponieważ to upstream decydowałby, które wygrywa. Request, który nie wskazuje modelu, wymaga uprawnienia do całego providera (zobacz Kontrola dostępu).
• Konto upstreamu jest współdzielone. Klucz z dostępem do passthrough może sięgać do obiektów na nim, takich jak pliki czy batche, utworzonych przez inne klucze. Przyznawaj passthrough_access tylko kluczom, którym ufasz w zakresie całego konta providera.
• Natywne body błędów i kody statusu providera są przekazywane dalej, zamiast być konwertowane na odpowiedzi kompatybilne z OpenAI.
• Funkcje zależne od kompatybilnych z OpenAI kształtów requestów lub odpowiedzi mogą nie działać dla ruchu passthrough tak samo jak dla ruchu /v1.

​

Powiązane zmienne środowiskowe

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