MacWhisper ne parle pas à Claude, LLM Bridge, si
Un petit proxy local traduit les requêtes entre les interfaces OpenAI et Anthropic, pour que les outils de dictée et de rédaction puissent aussi utiliser Claude via LangDock ou Anthropic.

MacWhisper ne connaît que l’interface OpenAI
Dans MacWhisper, tu peux renseigner un fournisseur personnalisé, mais il doit prendre en charge l’interface OpenAI Chat Completions. Claude ne la prend pas en charge. Anthropic et LangDock attendent des requêtes au format Messages, avec une structure différente, par exemple pour les prompts système et les images. Si tu utilises les modèles Claude via le point de terminaison européen de LangDock ou directement chez Anthropic, ce type d’outil ne te sera pas utile.
J’ai donc créé LLM Bridge : un petit proxy qui s’exécute localement sur ton ordinateur, reçoit les requêtes OpenAI et les transmet au format Anthropic. La réponse suit le chemin inverse. La version 0.1.0 est disponible dès maintenant sur GitHub.
Ce que traduit la Bridge
Le proxy propose /v1/chat/completions et /v1/models avec et sans streaming. En streaming, il convertit les Server-Sent Events d’Anthropic en fragments OpenAI, afin que le texte arrive dans le client comme l’outil s’y attend. Sont traduits : les prompts système, les images encodées en Base64, les outils avec appels de fonction, stop, temperature, max_tokens et le mode JSON.
Comme serveur amont, tu renseignes LangDock, par exemple la région EU, ou directement Anthropic. Dans les clients, tu utilises un alias à la place de l’ID de modèle complète : haiku pointe vers l’ID que tu as configurée dans la Bridge. Si l’ID change, tu la corriges à un seul endroit, et non dans chaque outil. Si tu préfères travailler sans alias, tu écris upstream-id/modell-id comme nom de modèle, par exemple langdock-eu/claude-sonnet-4-6-default.
L’idée : demander séparément à chaque outil de prendre en charge Claude prend du temps, et tous les fabricants ne le feront pas. Un traducteur centralisé résout le problème d’un seul coup pour tous les programmes qui acceptent un fournisseur compatible avec OpenAI.
En cas de problème, par exemple si l’ID de modèle est incorrecte, le client reçoit une erreur au format OpenAI avec un message compréhensible.
Comment configurer la Bridge dans MacWhisper
Au premier lancement, la Bridge crée une configuration avec LangDock EU et l’alias haiku et génère un jeton d’accès local aléatoire. Tu enregistres la clé API de ton fournisseur amont et récupères la liste des modèles, qui affiche les ID réels de ton espace de travail. Un clic sur un ID crée l’association avec l’alias. L’ID prédéfini n’est qu’une supposition : vérifie-le donc à cette étape. Un bouton de test envoie ensuite un seul jeton et indique si la chaîne fonctionne jusqu’à Claude. La clé est stockée dans le trousseau système (Trousseau d’accès macOS, Gestionnaire d’informations d’identification Windows, Secret Service Linux), jamais dans le fichier de configuration.
Tu crées ensuite un fournisseur compatible avec OpenAI dans MacWhisper :
| Champ | Valeur |
|---|---|
| URL de base | http://127.0.0.1:4000/v1 |
| Clé API | le jeton d’accès local des réglages de la passerelle |
| Nom du modèle | l’alias, par exemple haiku |
MacWhisper ne voit donc jamais ta véritable clé API, mais uniquement le jeton local.
Aussi sur le serveur
Pour utiliser la passerelle sans interface, par exemple sur une machine Linux, lance le programme en ligne de commande. Il utilise la même configuration et les mêmes statistiques que l’application :
llm-bridge set-key langdock-eu # saisir la clé à l’abri des regards, elle est stockée dans le trousseau
llm-bridge test haiku # test de connexion
llm-bridge serve # proxy au premier plan, port par défaut 4000
llm-bridge stats --range 30d # statistiques des 30 derniers jours
Sur un serveur sans trousseau, une variable d’environnement telle que LLM_BRIDGE_KEY_LANGDOCK_EU dans l’unité systemd suffit.
Compter sans lire
Pour chaque requête, Bridge enregistre une ligne dans une base de données SQLite locale : horodatage, modèle, jetons d’entrée, de sortie et de cache, temps de réponse et statut. L’interface de statistiques, disponible en allemand ou en anglais, affiche ces données par modèle et par client ; Bridge identifie le client grâce au User-Agent. L’export CSV est intégré.
Les prompts et les réponses ne sont pas enregistrés. Tu vois quel outil consomme combien de jetons, sans qu’aucun journal de tes textes ne soit créé. Si un client interrompt un flux, Bridge enregistre la requête avec les jetons comptabilisés jusque-là et le statut 499. Les réponses interrompues apparaissent donc aussi sur la facture.
Les jetons d’entrée dans l’interface comprennent les jetons de lecture et d’écriture du cache, comme OpenAI "prompt_tokens compte. Si tu compares les chiffres à la facturation de ton fournisseur, garde-le à l’esprit.
N’importe quel site web peut solliciter localhost
Lors de la sécurisation, j’ai remarqué quelque chose qui passe facilement inaperçu avec les services locaux. Un proxy sur 127.0.0.1 semble protégé, car personne ne peut y accéder depuis l’extérieur. Mais ton navigateur tourne sur le même ordinateur. Un site web tiers peut, via fetch() envoyer des requêtes à http://127.0.0.1:4000 envoyer, et un proxy non protégé les traiterait, aux frais de ta clé API. Grâce au DNS rebinding, qui fait soudainement pointer un nom de domaine tiers vers 127.0.0.1, le site pourrait même lire les réponses.
Bridge rejette donc les requêtes dont l’en-tête Origin ne pointe pas vers localhost, 127.0.0.1 ou [::1] affiche. Tant qu'elle n'écoute qu'en local, cela vaut aussi pour l'en-tête Host, qui bloque le rebinding.Content-Type: application/json ne peut envoyer sans vérification CORS préalable. Les programmes sans navigateur, donc aussi MacWhisper, n'envoient pas d'en-tête Origin et passent donc sans entrave. À cela s'ajoute le jeton d'accès créé au premier démarrage. Si tu le supprimes dans les paramètres, le proxy est ouvert à tous les programmes de l'ordinateur.
Le deuxième volet concerne l'upstream. La passerelle ne suit aucune redirection, car la clé API pourrait sinon être envoyée vers une destination tierce. Elle indique plutôt la nouvelle adresse, que tu saisis toi-même. Les upstreams doivent utiliser https://, http:// est autorisé uniquement pour localhost. La configuration et les statistiques ne sont lisibles que par ton propre utilisateur.
Application de la zone de notification, mises à jour et téléchargement
L'application de la zone de notification est construite avec Tauri 2, fonctionne sous macOS, Windows et Linux et inclut l'interface des statistiques. Elle démarre au besoin à l'ouverture de session et l'icône de la zone de notification te permet de démarrer et d'arrêter le proxy. Le cœur du proxy est écrit en Rust avec axum. Le code source est disponible sous licence MIT sur GitHub.
L'application installe elle-même les nouvelles versions. Elle télécharge une mise à jour en arrière-plan, vérifie sa signature et ne redémarre que lorsque le proxy n'a traité aucune requête pendant cinq minutes. Une dictée en cours n'est ainsi pas interrompue. Si tu ne le souhaites pas, désactive cette option dans les paramètres. Sur le serveur, le programme en ligne de commande se met à jour avec llm-bridge update, puis tu redémarres le service.
Tu trouveras la page du produit à l’adresse it-guy.ai/projects/llm-bridge, les paquets prêts à l’emploi sur la page des versions sur GitHub. Les téléchargements macOS sont signés avec un Apple Developer ID et notariés. Sous Windows et Linux, les paquets ne sont pas signés : vérifie la somme de contrôle par rapport au fichier SHA256SUMS dans la version.
Créé par Martin Schmid, avec l’aide de Claude Sonnet 5.5 (révisé avec Claude Opus 5.5) et validé après vérification personnelle du contenu. Sont applicables nos mentions et clause de non-responsabilité.