Cloud Mac + OpenRouter: Persönliches Enterprise-AI-Gateway — Praxisguide

2026 haben viele Einzelentwickler gleichzeitig Cursor, OpenClaw, eigene Skripte und zwei oder drei CLI-Agenten im Einsatz. Jedes Tool verlangt einen eigenen API-Key, jeder Anbieter eine andere Base-URL. Das eigentliche Problem ist nicht, ob das Modell stark genug ist, sondern dass keine einheitliche AI-Gateway-Schicht existiert: Schlüssel verstreut, Abrechnungen nicht nachvollziehbar, ein Provider-Ausfall legt alles lahm. Dieser Leitfaden zeigt einen nachbaubaren Weg: VPSSpark Cloud Mac als Control- und Execution-Plane, OpenRouter für Upstream-Modellaggregation, LiteLLM als selbst gehostete Gateway-Hülle—in etwa einer halben Stunde ein persönliches, unternehmensreifes Setup mit virtuellen Schlüsseln, Budget-Sicherungen und Modell-Fallback.

Warum Cloud Mac + OpenRouter—und nicht nur OpenRouter?

OpenRouter ist ein verwaltetes Gateway: Registrierung, Key erhalten, loslegen. Die offizielle Dokumentation beschreibt eine API, die weitgehend OpenAI Chat Completions-kompatibel ist—ideal für schnelle Integration. Gelöst wird damit die Upstream-Aggregation, nicht Ihre Governance-Grenze: Sie können Cursor und OpenClaw keine separat widerrufbaren Keys ausstellen, kaum teamweite Spend Caps über die Provider-Abrechnung legen und schon gar nicht Gateway und macOS-native Toolchain (Xcode, AppleScript, lokales MCP) auf derselben Execution-Plane betreiben.

Der Cloud Mac vereint Control Plane und Apple-Ökosystem-Execution. Der Gateway-Prozess läuft per launchd dauerhaft, Geheimnisse liegen nur in der Server-.env. OpenClaw, lokales Git oder iOS-Builds erfordern kein Hin- und Herschieben von Kontext auf den Laptop. Wer bereits ein Gateway auf einem Linux-VPS betreibt, kann den VPS für IM/Webhooks reservieren und den Cloud Mac für Gateway plus Builds nutzen—die Aufteilung beschreibt die Entscheidungsmatrix OpenClaw-Gateway und CI/CD auf Linux-VPS. Unterschiede bei launchd auf dem Cloud Mac: Cloud-Mac-launchd-FAQ.

Architektur: Aufgaben der drei Ebenen

Klären Sie die Zuständigkeiten, bevor Sie konfigurieren—das verhindert die meisten späteren Konflikte.

Checkliste vor dem Start (15 Minuten)

Der Reihe nach abhaken—so vermeiden Sie die meisten Verbindungsprobleme.

• OpenRouter-Konto mit API-Key und monatlichem Credit-Limit.
• Cloud Mac per SSH erreichbar, Architektur arm64 (Apple Silicon), macOS 14+.
• Homebrew installiert; Python 3.11+ oder Docker Desktop (eine Option—hier der leichte pip-Weg).
• Gateway bindet nur 127.0.0.1:4000; Remote-Zugriff über Tailscale oder SSH-Tunnel, Port 4000 nicht öffentlich exponieren.
• Cursor/OpenClaw auf dem Laptop können per SSH-Schlüssel auf den Cloud Mac zugreifen (Passwort-Login deaktiviert).

Grundlagen und Auswahl eines Cloud Mac: Mac-VPS- und Cloud-macOS-Leitfaden (2026).

Schritt 1: OpenRouter-Upstream einrichten

In der OpenRouter-Konsole einen Key mit dem Namen cloud-mac-gateway anlegen. Credit-Limit aktivieren (z. B. 20 USD/Monat) als harte Sicherung. Den Key sofort auf dem Cloud Mac speichern—nicht in Git.

Upstream vom Cloud Mac aus testen ($OPENROUTER_API_KEY ersetzen):

export OPENROUTER_API_KEY="sk-or-v1-xxxxxxxx"

                curl -s https://openrouter.ai/api/v1/chat/completions \
                  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "model": "openai/gpt-4o-mini",
                    "messages": [{"role": "user", "content": "ping"}]
                  }' | head -c 400

JSON mit choices bedeutet: Upstream erreichbar. Modell-IDs im Format provider/model; vollständige Liste auf der OpenRouter-Models-Seite. Üblich: anthropic/claude-sonnet-4, openai/gpt-4o, google/gemini-2.5-pro-preview.

Schritt 2: LiteLLM-Gateway auf dem Cloud Mac installieren

LiteLLM ist ein Open-Source-LLM-Gateway; Dokumentation unter docs.litellm.ai. Es kapselt OpenRouter hinter einem eigenen OpenAI-kompatiblen Endpunkt und bietet Virtual Keys sowie Spend Tracking.

# 云 Mac SSH 会话内
                brew install python@3.12
                python3.12 -m venv ~/ai-gateway/.venv
                source ~/ai-gateway/.venv/bin/activate
                pip install 'litellm[proxy]'

                mkdir -p ~/ai-gateway && cd ~/ai-gateway

config.yaml anlegen—das Routing-Herz des Gateways. Im Beispiel Standardmodell Claude Sonnet mit Fallback auf GPT-4o mini (OpenRouter-models-Array löst Fallback aus):

model_list:
                  - model_name: smart
                    litellm_params:
                      model: openrouter/anthropic/claude-sonnet-4
                      api_key: os.environ/OPENROUTER_API_KEY
                      models:
                        - openrouter/anthropic/claude-sonnet-4
                        - openrouter/openai/gpt-4o-mini

                  - model_name: fast
                    litellm_params:
                      model: openrouter/openai/gpt-4o-mini
                      api_key: os.environ/OPENROUTER_API_KEY

                litellm_settings:
                  drop_params: true
                  set_verbose: false

                general_settings:
                  master_key: os.environ/LITELLM_MASTER_KEY
                  database_url: "sqlite:///./litellm.db"

Im selben Verzeichnis .env anlegen (Berechtigung chmod 600):

OPENROUTER_API_KEY=sk-or-v1-xxxxxxxx
                LITELLM_MASTER_KEY=sk-local-master-xxxxxxxx

Proxy starten (zuerst im Vordergrund):

cd ~/ai-gateway
                source .venv/bin/activate
                set -a && source .env && set +a

                litellm --config config.yaml --host 127.0.0.1 --port 4000

In einem zweiten Terminal Loopback-Test mit dem Master Key:

curl -s http://127.0.0.1:4000/v1/chat/completions \
                  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "model": "smart",
                    "messages": [{"role": "user", "content": "gateway ok?"}]
                  }'

Schritt 3: launchd für Dauerbetrieb (7×24)

Nach erfolgreicher Prüfung das Gateway an launchd übergeben, damit SSH-Trennung den Prozess nicht beendet. Datei ~/Library/LaunchAgents/com.vpsspark.litellm.plist anlegen:

<?xml version="1.0" encoding="UTF-8"?>
                <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
                 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
                <plist version="1.0">
                <dict>
                  <key>Label</key><string>com.vpsspark.litellm</string>
                  <key>ProgramArguments</key>
                  <array>
                    <string>/Users/YOUR_USER/ai-gateway/.venv/bin/litellm</string>
                    <string>--config</string>
                    <string>/Users/YOUR_USER/ai-gateway/config.yaml</string>
                    <string>--host</string><string>127.0.0.1</string>
                    <string>--port</string><string>4000</string>
                  </array>
                  <key>EnvironmentVariables</key>
                  <dict>
                    <key>OPENROUTER_API_KEY</key><string>sk-or-v1-xxx</string>
                    <key>LITELLM_MASTER_KEY</key><string>sk-local-master-xxx</string>
                  </dict>
                  <key>RunAtLoad</key><true/>
                  <key>KeepAlive</key><true/>
                  <key>StandardOutPath</key>
                  <string>/Users/YOUR_USER/ai-gateway/litellm.log</string>
                  <key>StandardErrorPath</key>
                  <string>/Users/YOUR_USER/ai-gateway/litellm.err</string>
                </dict>
                </plist>

Laden und prüfen:

launchctl load ~/Library/LaunchAgents/com.vpsspark.litellm.plist
                launchctl list | grep litellm
                curl -fsS http://127.0.0.1:4000/health || echo "check logs"

Ausführlichere Schritte zu Dauerbetrieb und Fehlerbehebung: Cloud-Mac-launchd-FAQ, Abschnitt Login-Session vs. Hintergrund-Daemon—Gateway und OpenClaw können getrennte plist-Dateien nutzen.

Schritt 4: Cursor, OpenClaw und Skripte anbinden

Alle Clients ändern zwei Einstellungen: Base URL zeigt auf Ihr Gateway, API Key ist ein Virtual Key (Master Key nur für Verwaltung).

Cursor: Einstellungen → Models → Override OpenAI Base URL → http://127.0.0.1:4000/v1 (läuft Cursor auf dem Laptop und das Gateway auf dem Cloud Mac: zuerst ssh -L 4000:127.0.0.1:4000 user@cloud-mac oder Tailscale-Adresse). Modellnamen smart / fast, passend zu model_name in config.yaml.

OpenClaw: Laut Gateway-Konfigurationsdokumentation LLM-Provider auf OpenAI-kompatibel setzen: OPENAI_API_BASE=http://127.0.0.1:4000/v1, OPENAI_API_KEY=<virtual-key>. OpenClaw direkt auf dem Cloud Mac benötigt keinen Tunnel. OpenClaw auf Linux-VPS: LiteLLM auf den VPS verlagern oder privates Netzwerk nutzen—Master Key nicht in öffentliches Compose-Repository auf dem VPS schreiben.

Skripte: Jeder OpenAI-SDK-Code ändert nur base_url:

from openai import OpenAI

                client = OpenAI(
                    base_url="http://127.0.0.1:4000/v1",
                    api_key="sk-virtual-cursor-xxxxxxxx",
                )

                resp = client.chat.completions.create(
                    model="smart",
                    messages=[{"role": "user", "content": "总结今日 commit"}],
                )
                print(resp.choices[0].message.content)

Modell-Routing und Kostenkontrolle

Ein unternehmensreifes Gateway geht nicht um „Modell aufrufen“, sondern um den richtigen Zeitpunkt für teure Modelle. Drei Routing-Regeln für den persönlichen Stack:

• Standard: fast—Vervollständigung, Formatierung, einfache Fragen mit gpt-4o-mini, Kosten oft ein Zehntel von Sonnet-Klasse.
• Explizit smart—Architektur, komplexe Refactorings, Multi-Datei-Reasoning: Client oder OpenClaw auf smart mit OpenRouter-Fallback-Kette.
• Zweischichtige Budgets—OpenRouter-Konsole setzt Gesamt-Credit-Cap; LiteLLM Virtual Keys pro Client—beide müssen auslösen, bevor wirklich abgeschaltet wird.

OpenRouter akzeptiert models-Arrays für Provider-Fallback. LiteLLM model_list trennt Geschäftsaliasse (smart/fast) von echten Modell-IDs—Modellwechsel nur in YAML, Clients unverändert.

Sicherheits-Baseline (Pflicht, keine Option)

Häufigste Vorfälle bei persönlichen Gateways: Keys in Git oder Gateway ungeschützt im Internet. Mindestens fünf Regeln:

• .env und plist-Geheimnisse nicht versionieren; .gitignore für .env, *.db, litellm.log.
• LiteLLM nur an 127.0.0.1; Remote-Zugriff per SSH -L oder Tailscale; bei Mehrbenutzerbetrieb Nginx + mTLS.
• OpenRouter-Key kompromittiert: sofort in der Konsole rotieren. GitHub Secret Scanning hilft, aktive Rotation ist dennoch Pflicht.
• Regelmäßig sqlite3 litellm.db für Spend-Logs und Abgleich mit OpenRouter-Dashboard—bei Anomalien Virtual Keys sofort widerrufen.
• FileVault auf dem Cloud Mac, SSH nur mit Schlüssel. Wie bei Linux-Gateway-Auslieferung: Änderungen und Geheimnisse getrennt auditieren.

FAQ

LiteLLM überspringen und Clients direkt an OpenRouter? Möglich für minimale Solo-Setups. Sie verlieren Virtual Keys, einheitliche Logs und lokale Routing-Aliasse. Ab dem zweiten Client bauen Sie die Gateway-Schicht ohnehin nach.

Gateway auf Cloud Mac oder Linux-VPS? Nur LLM-Weiterleitung ohne macOS-Tools: VPS günstiger. OpenClaw + MCP + Xcode-Automatisierung: ein Cloud Mac für Execution und Gateway ist einfacher.

Was, wenn OpenRouter ausfällt? Zweiten Upstream in LiteLLM model_list (z. B. direkter Anthropic-Key als Notfallroute) oder fast vorübergehend auf OpenRouter-Free-Tier-Modell.

Steigt die Latenz? Ein zusätzlicher Proxy-Hop: meist einstellige bis niedrige zweistellige Millisekunden—vernachlässigbar gegenüber LLM-Inferenz. Engpässe liegen bei Modellwahl und Region, nicht bei LiteLLM.