Alimentez les agents de Warp depuis votre propre endpoint d'inférence.

Réponse rapide : réglages, URL, clé, id de modèles.

Ouvrez les réglages (Settings) de Warp et cherchez « inference endpoint » pour sauter directement à la configuration. Saisissez l'URL de l'endpoint, https://api.apisrouter.com/v1, votre clé APIsRouter comme identifiant, et l'id ou les id de modèles que vous voulez router via lui, par exemple claude-sonnet-4-6 et gpt-5.6-sol. Une fois enregistré, ces modèles apparaissent dans le sélecteur de modèle de Warp aux côtés des options intégrées. Le comportement de facturation est tout l'intérêt : quand vous sélectionnez explicitement un modèle routé via l'endpoint dans le sélecteur, Warp route la requête via votre endpoint au lieu de consommer les crédits AI de Warp, et le coût atterrit sur votre solde de passerelle où vous pouvez le voir par requête. La documentation de Warp décrit ce flux comme le miroir de leur configuration Bring Your Own API Key, donc cela vous semblera familier si vous avez déjà configuré du BYOK.

Endpoint URL:  https://api.apisrouter.com/v1
Credential:    sk-YOUR-APISROUTER-KEY
Model id(s):   claude-sonnet-4-6
               gpt-5.6-sol

then: select the endpoint-routed model
      in Warp's model picker

Comment Warp utilise l'endpoint.

Warp est le terminal agentique : ses agents rédigent des commandes, expliquent les échecs, exécutent des tâches à plusieurs étapes, et éditent du code depuis la même fenêtre où vous travaillez. La documentation de Warp elle-même énonce l'exigence clairement : l'endpoint doit implémenter l'API OpenAI Chat Completions sur /v1/chat/completions, et leur billet de lancement nomme les routeurs de modèles et les passerelles hébergées comme cibles prévues, donc une passerelle multi-fournisseurs est un citoyen de première classe ici, pas une astuce. Deux contraintes documentées valent la peine d'être connues avant de commencer. D'abord, l'endpoint doit être accessible publiquement : localhost, 127.0.0.1 et les URL de réseau privé sont rejetées au moment de la configuration, ce qui exclut de pointer Warp directement vers un serveur d'inférence local, mais est sans importance pour une passerelle hébergée. Ensuite, la sélection de modèle Auto de Warp consomme toujours des crédits Warp même quand un endpoint personnalisé est configuré ; seul le choix explicite d'un modèle routé via l'endpoint dans le sélecteur route via votre endpoint. Si votre dépense ne remonte pas dans la console de la passerelle, vérifiez quel modèle la session a réellement utilisé. La disponibilité dépend du plan : les endpoints d'inférence personnalisés sont proposés sur les plans Free et les plans payants éligibles pour les particuliers et les organisations de dix personnes ou moins, tandis que les organisations plus grandes ont besoin des paliers Business ou Enterprise de Warp. Cela vient directement de la documentation de Warp et peut changer de leur côté.

Choisir des modèles pour le travail d'agent en terminal.

Les agents de terminal facturent différemment du chat : chaque explication de commande, chaque nouvelle tentative et chaque résumé de sortie est une requête portant le contexte de session. Comme l'usage routé via l'endpoint atterrit dans la console de la passerelle par requête et par modèle, une semaine d'usage réel vous donne un chiffre honnête par modèle candidat, ce qui bat le fait de deviner à partir d'une page de tarifs, celle-ci incluse.

• claude-sonnet-4-6 comme choix du quotidien : génération de commandes fiable, usage d'outils solide, bon jugement sur les tâches à plusieurs étapes.
• gpt-5.6-sol pour du travail rapide et ciblé, où la latence par tour façonne la sensation du terminal.
• claude-opus-4-7 pour les sessions difficiles : débogage à travers plusieurs services, longues chaînes d'investigation, changements d'infrastructure que vous voulez voir raisonnés en profondeur.
• gpt-5.5 comme généraliste frontier à tester en A/B contre Claude sur vos propres workflows shell.
• deepseek-v4-pro comme choix économique pour un usage d'agent routinier à fort volume, où le tarif compte plus que la finition frontier.

Paiement à l'usage · en dessous du tarif officiel

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Modes d'échec spécifiques à Warp.

Comme toujours, prouvez la moitié passerelle avec deux commandes curl, le listing des modèles et une completion de chat, avant de déboguer le côté Warp. Si curl réussit et que Warp échoue, le problème est dans le formulaire d'endpoint ou la sélection du sélecteur de modèle, nulle part ailleurs.

• Endpoint rejeté à l'enregistrement : Warp refuse par conception les URL localhost et de réseau privé. L'endpoint doit être accessible publiquement ; une URL de passerelle hébergée passe ce contrôle.
• La dépense continue de toucher les crédits Warp : la session est sur la sélection de modèle Auto, qui utilise toujours les crédits Warp. Choisissez explicitement le modèle routé via l'endpoint dans le sélecteur.
• Modèle introuvable : l'id que vous avez tapé dans la config de l'endpoint ne correspond pas au catalogue de la passerelle. Copiez les id depuis le listing /v1/models octet pour octet.
• 401 depuis l'endpoint : le champ credential contient une clé périmée ou tronquée. Interrogez en curl le listing des modèles avec la même clé pour confirmer en dehors de Warp.
• Fonctionnalité totalement invisible : vérifiez votre plan. Les endpoints personnalisés sont disponibles pour les particuliers et petites organisations sur les plans Free et les plans payants éligibles ; les organisations plus grandes ont besoin de Business ou Enterprise selon la doc de Warp.

Qui route Warp via une passerelle.

• Les développeurs qui veulent Claude derrière les agents de Warp sur un solde prépayé, avec un démarrage gratuit et sans carte.
• Les gros utilisateurs d'agent dont la consommation de crédits Warp a dépassé leur plan, qui déplacent leurs choix de modèle explicites vers leur propre endpoint facturé à l'usage.
• Les acheteurs de modèles qui comparent des modèles de codage sur de vrais workflows de terminal, où chaque candidat n'est qu'un id de plus dans la config de l'endpoint.
• Les équipes de dix personnes ou moins qui standardisent sur une seule clé de passerelle afin que les agents de terminal, d'éditeur et de CI partagent un seul journal d'usage.
• Les personnes qui font déjà tourner d'autres outils via une passerelle et veulent Warp sur la même clé et la même console.

Vérifiez l'endpoint et confirmez le routage.

Lancez les deux vérifications standard avec la clé et l'id exacts que vous avez configurés dans Warp. Si les deux réussissent, la passerelle est prête et tout problème restant se trouve dans les réglages de Warp ou la sélection de modèle. Lancez ensuite une vraie tâche d'agent dans Warp avec le modèle de l'endpoint explicitement sélectionné, et confirmez que la requête apparaît dans la console APIsRouter avec le modèle et le nombre de tokens attendus. Cette seule confirmation attrape immédiatement le piège du mode Auto, et à partir de là, la console est votre registre par requête de ce que dépense réellement le terminal.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

Questions fréquentes