Fremde LLMs & lokale Modelle in Claude Code einbinden

1Das Prinzip: Harness behalten, Motor tauschen

Claude Code spricht mit seinem Modell über die Anthropic-Messages-API. Alles, was diese API anbietet, kann als Motor dienen — egal ob es bei Anthropic läuft, bei einem anderen Anbieter oder auf deinem Rechner.

Drei Umgebungsvariablen steuern das komplett:

2Weg 1 — Lokales Modell mit Ollama (der einfachste)

Ollama bringt seit Version 0.14 (Januar 2026) einen nativen /v1/messages-Endpoint im Anthropic-Format mit. Drei Befehle, fertig.

# Linux
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3-coder

export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_AUTH_TOKEN=ollama
claude --model qwen3-coder

#!/bin/bash
export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_AUTH_TOKEN=ollama
exec claude --model qwen3-coder "$@"

3Weg 2 — Abo-Modelle über CLIProxyAPI (das claudex-Muster)

So nutzt du GPT 5.6 aus einem ChatGPT-Abo als Motor in Claude Code. Genau dieses Setup fahren wir bei H24 produktiv, inklusive aller Härtungsschritte. CLIProxyAPI meldet sich per OAuth bei deinem Abo an und stellt die Modelle lokal als Anthropic-kompatible API bereit.

mkdir -p /opt/cliproxy && cd /opt/cliproxy
# Binary des gewünschten Releases laden (Beispiel), dann:
sha256sum -c checksums.txt
chmod +x cli-proxy-api

host: "127.0.0.1"        # NUR localhost — wichtigste Zeile der Datei
port: 8317
remote-management:
  allow-remote: false
  disable-control-panel: true
auth-dir: "/opt/cliproxy/auths"  # chmod 700 — OAuth-Tokens liegen hier im Klartext!
api-keys:
  - "<32-BYTE-ZUFALLSSCHLÜSSEL>"  # openssl rand -hex 32
plugins:
  enabled: false
debug: false
logging-to-file: false
usage-statistics-enabled: false
request-log: false          # sonst landen Prompts im Log
request-retry: 3

chmod 600 config.yaml
mkdir -p auths && chmod 700 auths

./cli-proxy-api --config config.yaml --codex-device-login

[Unit]
Description=CLIProxyAPI (lokaler Multi-LLM-Proxy)
After=network.target

[Service]
Type=simple
ExecStart=/opt/cliproxy/cli-proxy-api --config /opt/cliproxy/config.yaml
WorkingDirectory=/opt/cliproxy
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/cliproxy
PrivateTmp=true

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now cliproxy
# Pflicht-Check: lauscht der Proxy wirklich NUR auf localhost?
ss -tlnp | grep 8317   # muss 127.0.0.1:8317 zeigen, nicht 0.0.0.0

curl -s http://127.0.0.1:8317/v1/models \
  -H "Authorization: Bearer <DEIN-API-KEY>" | head
# … und direkt als Claude-Code-Session:
ANTHROPIC_BASE_URL=http://127.0.0.1:8317 \
ANTHROPIC_AUTH_TOKEN=<DEIN-API-KEY> \
ANTHROPIC_MODEL=gpt-5.6-sol claude

4Der Wrapper: aus drei Exporten wird ein Befehl

Damit der Motorwechsel im Alltag ein Wort ist, kapseln wir das Setup in ein Wrapper-Skript. Unseres heißt claudex — Claude Code mit Fremd-Motor. Hier die generische, übertragbare Fassung (/usr/local/bin/claudex, chmod +x):

#!/bin/bash
# claudex — Claude Code mit alternativem Modell über lokalen Proxy.
# Native Claude-Abos werden NIEMALS durch diesen Proxy geleitet.
set -euo pipefail

PROXY_BASE=http://127.0.0.1:8317
DEFAULT_MODEL=gpt-5.6-sol

# API-Key aus geschützter Datei laden, nie hardcoden (chmod 600):
#   PROXY_TOKEN=<dein-key>
set -a; . /etc/cliproxy.env; set +a

# Health-Check: klare Fehlermeldung statt kryptischem API-Error
if ! curl -fsS --max-time 3 -o /dev/null \
    -H "Authorization: Bearer $PROXY_TOKEN" "$PROXY_BASE/v1/models"; then
  echo "FEHLER: Proxy ($PROXY_BASE) nicht erreichbar. systemctl status cliproxy" >&2
  exit 1
fi

export ANTHROPIC_BASE_URL="$PROXY_BASE"
export ANTHROPIC_AUTH_TOKEN="$PROXY_TOKEN"
export ANTHROPIC_MODEL="${CLAUDEX_MODEL:-$DEFAULT_MODEL}"
exec claude "$@"

So fühlt sich das im Alltag an

claude                    # normale Session, natives Claude-Abo
claudex                   # gleiche Skills & Memory, GPT als Motor
claudex --continue        # laufenden Verlauf mit GPT weiterführen
claude --continue         # … und zurück auf Claude
CLAUDEX_MODEL=gpt-5.6-terra claudex   # anderes Modell ad hoc

5Weg 3 — Router, wenn es viele Provider werden

Sobald du mehr willst als „ein Zweitmotor“ — etwa günstige Modelle für Routinejobs und starke für Architekturfragen — lohnt ein Router vor den Providern.

Das Prinzip bleibt identisch: Der Router bietet lokal einen Anthropic-kompatiblen Endpoint an, Claude Code zeigt per ANTHROPIC_BASE_URL darauf. Ein einmal gebauter Wrapper funktioniert für alle drei Wege.

6Sicherheits-Checkliste

Ein LLM-Proxy bündelt Zugänge zu deinen teuersten Accounts. Entsprechend behandeln.

• Nur localhost binden (127.0.0.1) und nach jedem Start mit ss -tlnp verifizieren. Ein offener LLM-Proxy im Internet ist ein gefundenes Fressen.
• Version pinnen, Checksumme prüfen, kein Auto-Update. Updates bewusst einspielen, Changelog lesen.
• Auth-Verzeichnis schützen: OAuth-Tokens liegen dort im Klartext → chmod 700, Backups davon verschlüsseln.
• API-Key des Proxys zufällig generieren (openssl rand -hex 32), in einer chmod 600-Datei oder im Passwort-Manager halten — nie ins Skript, nie ins Git.
• Request-Logging aus — sonst landen Prompts (inklusive Code und Daten) dauerhaft auf der Platte.
• Management-Panel und Plugins deaktivieren, wenn du sie nicht brauchst. Jede Fläche weniger.
• systemd-Sandbox nutzen: ProtectSystem=strict, NoNewPrivileges=true, minimale ReadWritePaths.
• Dedizierten Account für den Proxy-Login verwenden. Falls ein Anbieter die Duldung beendet, trifft eine Sperre nicht deinen Haupt-Zugang.

7Spielregeln & Risiken (Stand Juli 2026)

8Troubleshooting