Il y a deux étapes distinctes : créer un nouveau lien de paiement OpenRouter et payer ce lien. La CLI peut automatiser le paiement d'un lien existant, mais elle ne crée pas pour vous le prochain lien de recharge OpenRouter.
Cette page explique la contrainte, puis passe en revue les solutions qui fonctionnent réellement en pratique. ROZO Checkout est un checkout tiers indépendant et n'est pas affilié à OpenRouter.
Séparer la création du lien de paiement et le paiement
L'auto top-up fonctionne en débitant un moyen de paiement enregistré à l'avance. Il faut que quelqu'un puisse déplacer votre argent sans que vous soyez présent à ce moment-là. Avec une carte, c'est précisément à cela que sert la carte enregistrée.
Un portefeuille auto-conservé peut signer chaque paiement de manière interactive, ou un logiciel local peut signer avec une clé que vous l'avez autorisé à utiliser. L'auto-conservation n'exclut donc pas l'automatisation en soi.
Pour un paiement sans surveillance, un signataire doit avoir le pouvoir de dépenser : par exemple, un portefeuille chaud local dédié utilisé par le mode optionnel --send de la CLI. C'est différent d'un service custodial qui détient votre solde ou d'une allowance de tokens qui permet à un contrat de dépenser.
Autoriser un signataire ne règle pas la création du lien de paiement. Gardez cette étape explicite au lieu de supposer qu'une tâche cron peut générer de nouvelles factures OpenRouter.
Ce qui casse vraiment quand le solde tombe à zéro
Il vaut la peine d'être concret, car la panne n'a rien d'élégant.
Un job de longue durée ne se met pas poliment en pause en attendant des fonds. Les requêtes commencent à échouer et, selon la façon dont votre client gère les erreurs, vous obtenez une rafale d'échecs, un batch partiellement terminé, ou une boucle de retry qui brûle du temps sur un solde vide. Tout reste cassé jusqu'à ce qu'un humain s'en aperçoive et recharge le compte à la main.
Le coût, ce n'est presque jamais la recharge elle-même. C'est l'exécution qu'il faut reprendre depuis le début, et le temps écoulé entre le moment où le solde tombe à zéro et celui où vous l'apprenez.
Les solutions qui tiennent la route
Aucune n'est astucieuse. Elles marchent parce qu'elles réduisent la fréquence à laquelle la question se pose.
- Dimensionnez le tampon selon votre consommation, pas selon le minimum. Si une grosse journée vous coûte un certain montant, gardez plusieurs jours de cela sur le solde. Recharger plus, moins souvent, vaut strictement mieux que recharger le minimum à répétition.
- Rechargez avant une longue exécution, pas pendant. Le moment où vous savez qu'un batch va coûter cher est le moment le moins coûteux pour ajouter des fonds.
- Surveillez le solde là où vous regardez déjà. Un chiffre que vous ne voyez jamais est un chiffre qui vous surprend. Mettez-le sur un chemin que vous empruntez de toute façon.
- Gardez une recharge assez rapide pour que la stratégie du tampon soit tenable. C'est là que nous pouvons aider : collez le payment link, confirmez dans votre portefeuille, et les crédits arrivent en général environ 2 minutes après la confirmation du paiement sur la chaîne. Le manuel n'est pénible que lorsqu'il est lent.
Automatiser avec la CLI ou un cron
OpenRouter exposait une API de crédits crypto qu'un script pouvait appeler. En octobre 2026, ce endpoint (POST /api/v1/credits/coinbase) renvoie 410 Gone : le lien de paiement doit donc être créé dans la page Credits d'OpenRouter.
Une fois le lien en main, son paiement peut être scripté. La CLI ROZO Checkout fait le devis et le paiement d'un lien en une commande, qu'un agent ou un cron peut lancer :
- npx @rozoai/checkout quote <link>
- npx @rozoai/checkout pay <link> --with usdt-solana --yes
Le chemin par défaut ne demande ni clé privée ni variables d'environnement : il crée une commande de dépôt à usage unique, affiche l'adresse et le montant exact, et attend que la facture soit réglée. Vous envoyez toujours depuis votre propre portefeuille, donc le principe d'auto-conservation ci-dessus tient. Pour un fonctionnement sans surveillance, l'option --send signe avec une clé locale sur les réseaux EVM ou Solana ; utilisez pour cela un portefeuille chaud dédié avec un petit solde, car le signataire local peut dépenser ses fonds.
Pour vérifier le paiement, exécutez npx @rozoai/checkout receipt <rozoPaymentId> --json. La commande renvoie le code 0 uniquement lorsque Coinbase indique que la facture est payée ; en v3, cela signifie CAPTURE_SUCCEEDED. Le code 3 signifie en cours ou inconnu, et le code 1 signifie expirée sans paiement ou à examiner par un humain. Un code 0 sur une commande status signifie seulement que la vérification s'est exécutée : lisez ses champs state, paymentOutcome et nextAction. Confirmez les crédits dans OpenRouter séparément.
Consultez le ROZO Checkout CLI README pour les commandes actuelles et les deux formats d'URL Coinbase pris en charge : payment link et payment session. Notre guide pour les agents IA couvre la CLI, le serveur MCP et la skill Claude Code.
Si vous voulez quand même une automatisation complète
Choisissez comment les paiements seront autorisés et décidez séparément comment obtenir les nouveaux liens de paiement.
La signature locale peut automatiser un paiement préparé sans solde custodial. Limitez les fonds accessibles à ce signataire, vérifiez le devis avant d'accorder ce pouvoir et contrôlez le reçu avant toute nouvelle tentative. Si vous utilisez plutôt un service custodial, examinez ses conditions d'accès, de retrait et de remboursement.
Pour la plupart des gens qui font tourner des agents, un tampon plus une recharge manuelle de 30 secondes représentent au final moins de risque opérationnel qu'un solde permanent conservé ailleurs.