Cloud Mac + OpenRouter : construire votre AI Gateway personnel de niveau entreprise

En 2026, beaucoup de devs indépendants jonglent entre Cursor, OpenClaw, des scripts maison et deux ou trois agents CLI. Chaque outil veut sa clé API, chaque fournisseur sa propre base URL. Le vrai problème n'est pas la puissance du modèle, c'est l'absence d'une passerelle IA unifiée : clés éparpillées, factures incohérentes, et un fournisseur en panne qui bloque tout. Ce guide vous propose une stack reproductible : Cloud Mac VPSSpark comme plan de contrôle et couche d'exécution, OpenRouter pour l'agrégation upstream, LiteLLM comme coque gateway auto-hébergée—un point d'entrée « perso mais pro » avec clés virtuelles, plafonds budgétaires et repli de modèles en une trentaine de minutes.

Pourquoi Cloud Mac + OpenRouter—et pas OpenRouter seul ?

OpenRouter est une gateway managée : inscription, clé, c'est parti. Sa documentation officielle décrit une API largement compatible OpenAI Chat Completions—idéal pour brancher vite. Ce qu'il résout, c'est l'agrégation upstream, pas votre périmètre de gouvernance : pas de clés révocables séparément pour Cursor et OpenClaw, pas de plafonds d'équipe au-dessus de la facturation fournisseur, et surtout pas de colocalisation gateway + toolchain macOS native (Xcode, AppleScript, MCP local) sur la même couche d'exécution.

Le Cloud Mac fusionne plan de contrôle et exécution dans l'écosystème Apple. Le processus gateway tourne sous launchd ; les secrets restent dans le .env du serveur. OpenClaw, Git local ou déclenchement de build iOS : inutile de rapatrier le contexte sur le portable. Si vous avez déjà une gateway sur un VPS Linux, gardez le VPS pour IM/webhooks et dédiez le Cloud Mac au gateway + builds—voir la matrice CI/CD gateway OpenClaw sur VPS Linux. Pour launchd côté Cloud Mac : FAQ launchd Cloud Mac.

Architecture : rôle de chaque couche

Clarifiez les responsabilités avant de configurer—vous éviterez la plupart des conflits ensuite.

Checklist avant de commencer (15 minutes)

Cochez dans l'ordre—vous éliminez la majorité des problèmes de connexion.

• Compte OpenRouter avec clé API et plafond de crédit mensuel.
• Cloud Mac accessible en SSH, architecture arm64 (Apple Silicon), macOS 14+.
• Homebrew installé ; Python 3.11+ ou Docker Desktop (au choix—ici le chemin pip, le plus léger).
• Gateway en écoute sur 127.0.0.1:4000 uniquement ; accès distant via Tailscale ou tunnel SSH, jamais le port 4000 exposé publiquement.
• Cursor / OpenClaw sur le portable peuvent SSH vers le Cloud Mac (auth par clé, mot de passe désactivé).

Premiers pas Cloud Mac : guide Mac VPS et macOS dans le cloud (2026).

Étape 1 : configurer l'upstream OpenRouter

Dans la console OpenRouter, créez une clé nommée cloud-mac-gateway. Activez un credit limit (ex. 20 $/mois) comme coupe-circuit. Une fois la clé obtenue, écrivez-la immédiatement sur le Cloud Mac—jamais dans Git.

Vérifiez l'upstream depuis le Cloud Mac (remplacez $OPENROUTER_API_KEY) :

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

Du JSON avec choices = upstream OK. Les ID modèles suivent provider/model ; liste complète sur la page Models d'OpenRouter. Courants : anthropic/claude-sonnet-4, openai/gpt-4o, google/gemini-2.5-pro-preview.

Étape 2 : installer le gateway LiteLLM sur le Cloud Mac

LiteLLM est une gateway LLM open source ; la doc est sur docs.litellm.ai. Elle encapsule OpenRouter derrière votre propre point de terminaison compatible OpenAI, avec clés virtuelles et suivi des dépenses.

# 云 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

Créez config.yaml—le cœur du routage. L'exemple ci-dessous met Claude Sonnet par défaut avec repli sur GPT-4o mini (le tableau models d'OpenRouter déclenche le fallback) :

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"

Dans le même répertoire, créez .env (permissions chmod 600) :

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

Démarrez le proxy (d'abord au premier plan) :

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

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

Dans un autre terminal, test loopback avec la 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?"}]
                  }'

Étape 3 : launchd pour disponibilité 24/7

Une fois validé, confiez le gateway à launchd pour qu'une déconnexion SSH ne l'arrête pas. Créez ~/Library/LaunchAgents/com.vpsspark.litellm.plist :

<?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>

Chargez et vérifiez :

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

Pour la persistance Cloud Mac et le dépannage : FAQ launchd Cloud Mac, section session de connexion vs démon en arrière-plan—gateway et OpenClaw peuvent avoir chacun leur plist sans interférer aux redémarrages.

Étape 4 : brancher Cursor, OpenClaw et les scripts

Tous les clients modifient deux réglages : base URL vers votre gateway, clé API = clé virtuelle (master key réservée à l'admin).

Cursor : Réglages → Models → Override OpenAI Base URL → http://127.0.0.1:4000/v1 (si Cursor est sur le portable et le gateway sur le Cloud Mac : tunnel d'abord avec ssh -L 4000:127.0.0.1:4000 user@cloud-mac, ou adresse Tailscale). Noms de modèles smart / fast, alignés sur model_name dans config.yaml.

OpenClaw : Selon la documentation de configuration gateway, définissez le fournisseur LLM en compatible OpenAI : OPENAI_API_BASE=http://127.0.0.1:4000/v1, OPENAI_API_KEY=<virtual-key>. OpenClaw sur le Cloud Mac lui-même : pas de tunnel. OpenClaw sur VPS Linux : migrez LiteLLM sur le VPS ou utilisez le réseau privé—ne mettez jamais la master key dans un dépôt compose public sur le VPS.

Scripts : tout code OpenAI SDK ne change que 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)

Routage des modèles et maîtrise des coûts

Une gateway « pro », ce n'est pas « appeler un modèle », c'est savoir quand utiliser le modèle cher. Trois règles pour une stack perso :

• Par défaut fast : complétion, formatage, Q&R simples sur gpt-4o-mini—coût souvent un dixième des modèles type Sonnet.
• Passage explicite à smart : architecture, refactors complexes, raisonnement multi-fichiers—basculez client ou règles OpenClaw vers smart (chaîne de repli OpenRouter).
• Double plafond : console OpenRouter pour le cap crédit global ; clés virtuelles LiteLLM par client—les deux doivent déclencher avant coupure réelle.

OpenRouter accepte un tableau models pour le repli fournisseur. Le model_list LiteLLM découple les alias métier (smart/fast) des ID réels—changez de modèle dans le YAML, zéro modification côté client.

Baseline sécurité (obligatoire)

Incidents les plus fréquents sur gateway perso : clés dans Git, ou gateway exposé sur Internet. Cinq règles minimum :

• .env et secrets plist hors dépôt ; .gitignore pour .env, *.db, litellm.log.
• LiteLLM lié à 127.0.0.1 uniquement ; accès distant via SSH -L ou Tailscale ; Nginx + mTLS si usage multi-utilisateurs.
• Clé OpenRouter compromise : rotation immédiate en console. OpenRouter collabore avec GitHub Secret Scanning, mais la rotation proactive reste la norme.
• Exportez régulièrement les logs de dépense via sqlite3 litellm.db et comparez au tableau de bord OpenRouter—trafic anormal = révocation des clés virtuelles.
• FileVault sur le Cloud Mac, SSH par clé uniquement. Comme pour la livraison gateway Linux : auditez séparément les changements et les secrets.

FAQ

Peut-on sauter LiteLLM et pointer les clients directement sur OpenRouter ? Oui, pour un setup solo minimal. Vous perdez clés virtuelles, logs unifiés et alias de routage locaux. Dès le deuxième client, vous reconstruirez la couche gateway.

Gateway sur Cloud Mac ou VPS Linux ? Simple relais LLM sans besoin macOS : le VPS coûte moins. OpenClaw + MCP + automatisation Xcode : un Cloud Mac pour exécution + gateway est plus simple.

Si OpenRouter tombe ? Ajoutez un second upstream dans model_list LiteLLM (ex. clé Anthropic directe en route d'urgence), ou pointez temporairement fast vers un modèle free tier OpenRouter.

La latence augmente-t-elle ? Un saut proxy supplémentaire : généralement quelques millisecondes à quelques dizaines—négligeable face à l'inférence LLM. Les goulots viennent du choix de modèle et du routage régional, pas de LiteLLM.