Gemini 4 Argon dans OpenCode : configuration et limites

Gemini 4 Argon peut être configuré dans OpenCode via son fournisseur Google natif. La question est de savoir ce qui se passe après la première réponse : le client conserve-t-il les parties signées, renvoie-t-il correctement les résultats des outils et reconnaît-il une réponse de continuation ? Nos vérifications hors ligne d’OpenCode v1.19.0 ont montré un traitement correct du texte et des messages d’outils, mais des lacunes pour la continuation des sorties longues et les flux interrompus.

Ce guide fournit une configuration de départ et précise exactement ce que ces résultats permettent d’affirmer. Ils ne prouvent pas qu’une intégration complète d’agent de programmation avec SeedRouter a été testée par des appels réels. Pour un client plus simple, avec une seule requête que vous déclenchez vous-même à chaque tour, utilisez le tutoriel de conversation Python.

Configurer Gemini 4 Argon dans OpenCode

Vérifiez la version installée avec opencode --version. Les résultats ci-dessous concernent la version publiée v1.19.0, testée le 14 octobre 2026. Une version plus récente nécessite sa propre vérification ; la présence d’une fonction dans une branche de développement ne prouve pas qu’une version installée la prend en charge.^[1]

Créez un répertoire de projet vide pour votre première vérification. Téléchargez-y la configuration OpenCode. La partie consacrée à la connexion est la suivante :

{
  "provider": {
    "google": {
      "npm": "@ai-sdk/google",
      "options": {
        "apiKey": "{env:SEEDROUTER_API_KEY}",
        "baseURL": "https://api.seedrouter.ai/v1beta"
      },
      "models": {
        "gemini-4-argon": {
          "name": "Gemini 4 Argon",
          "reasoning": true,
          "tool_call": true,
          "limit": { "context": 1048576, "output": 4096 },
          "options": {
            "thinkingConfig": { "thinkingLevel": "low", "includeThoughts": true }
          }
        }
      }
    }
  }
}

OpenCode prend en charge la substitution des variables d’environnement dans les fichiers de configuration.^[2] Définissez SEEDROUTER_API_KEY dans votre shell, sans inclure cette clé dans les commits du projet. Le fichier téléchargé sélectionne aussi google/gemini-4-argon, désactive le partage et les mises à jour automatiques, et n’autorise que l’outil read. Examinez ces autorisations avant de l’utiliser avec un dépôt existant. Les indicateurs reasoning et tool_call décrivent le comportement du client ; ils ne prouvent pas qu’un compte ou un service donné prend en charge toutes les opérations.

La valeur de sortie 4096 est un budget initial choisi délibérément pour cette configuration, pas le maximum officiel d’Argon. Le raisonnement consomme aussi ce budget. Consultez la référence API pour les règles de contexte, de sortie et de continuation.

Commencer par une requête courte

Après avoir examiné la configuration et les tarifs actuels, exécutez :

OPENCODE_CONFIG="$PWD/gemini-4-argon-opencode.json" \
OPENCODE_DISABLE_MODELS_FETCH=1 \
OPENCODE_DISABLE_AUTOCOMPACT=1 \
opencode run --model google/gemini-4-argon \
  "Explain a mutex in one sentence. Do not use tools."

Avec votre clé, cette commande envoie une véritable requête au modèle. OpenCode peut réessayer après un échec ou émettre des requêtes supplémentaires pendant l’exécution d’un agent : la commande ne garantit pas que vos dépenses seront limitées au coût d’un seul appel. Arrêtez le processus si la réponse est incomplète ou si les requêtes se répètent. Pour un contrôle strictement manuel, utilisez plutôt l’exemple Python.

Le chemin de requête natif doit se terminer par gemini-4-argon:streamGenerateContent?alt=sse. Dans la version testée, le fournisseur Google a envoyé les identifiants dans x-goog-api-key. Cela diffère des exemples cURL avec en-tête Bearer du tutoriel API général ; choisir un fournisseur OpenAI générique ne produit pas la même requête native.

Ce que les vérifications hors ligne ont établi

Le test utilisait la CLI publiée, une API simulée en local et des identifiants factices. Il a émis 17 requêtes sur l’interface de bouclage dans huit scénarios. Aucun modèle n’a généré les réponses, et les valeurs de tokens rapportées étaient artificielles. Ces observations décrivent le client, pas la qualité du modèle ni la facturation réelle.

Scénario	Comportement observé dans v1.19.0
Flux de texte natif	A fusionné les événements textuels distincts pour former la réponse attendue
Deuxième tour de conversation	A conservé dans les parties du modèle les signatures de raisonnement et de texte utilisées pour le test
Appel d’un outil de lecture et retour du résultat	A lu un fichier de test temporaire et renvoyé son contenu dans `functionResponse`
`MAX_TOKENS`	A signalé un arrêt pour limite de longueur, sans autre requête dans ce scénario de test
HTTP 400	S’est terminé avec une erreur sans réessayer dans ce scénario de test
HTTP 429	A réessayé une fois ; la réponse simulée suivante indiquait un succès

Le test confirme que thinkingConfig a été envoyé. Il ne prouve pas qu’un service réel a appliqué ce réglage. De même, transmettre une signature synthétique via l’historique ne démontre pas qu’une véritable signature sera acceptée dans une requête ultérieure.

Pourquoi les sorties longues demandent des vérifications supplémentaires

La réponse CONTINUATION d’Argon exige la requête d’origine et la dernière valeur de continuationToken au niveau racine. Pour reprendre cette génération, il ne faut pas ajouter la sortie partielle à l’historique de conversation ordinaire.^[3]

Dans notre test, OpenCode v1.19.0 a classé CONTINUATION comme une valeur inconnue. La requête suivante omettait le token et ajoutait la réponse partielle à l’historique. Lorsqu’un flux se terminait après une sortie partielle sans événement de fin, le client émettait aussi des requêtes ordinaires supplémentaires. Le service simulé a arrêté ce scénario après six appels ; ce nombre ne constitue pas une limite de nouvelles tentatives établie pour le client.

Cette configuration n’est donc pas une solution vérifiée pour le décodage long d’Argon. Obtenir une réponse courte ne résout pas ces cas. Avant de vous y fier pour de longues sessions de programmation, répétez les vérifications pertinentes avec la version exacte du client que vous comptez utiliser.

Questions sur la configuration OpenCode

Cela inclut-il des vérifications réelles des outils et de la facturation ?

Non. Le streaming de texte de base de SeedRouter a été validé séparément par un test local de bout en bout, mais cette vérification d’OpenCode utilisait des réponses simulées. La sélection réelle des outils, les signatures, les médias, les autorisations du compte et la facturation nécessitent encore leurs propres vérifications.

Puis-je utiliser à la place une configuration compatible OpenAI ?

Il s’agit d’un autre protocole, avec un autre périmètre de compatibilité. Ce guide vérifie le contenu natif et les signatures de Gemini. La documentation de Google sur le décodage long exclut son point de terminaison compatible OpenAI de cette fonctionnalité.^[3]

La désactivation de la compression automatique du contexte empêche-t-elle les nouvelles tentatives ?

Non. La compression et les nouvelles tentatives de requêtes sont deux comportements distincts. La variable d’environnement utilisée dans l’exemple ne garantit pas de limite stricte au nombre de requêtes ni au coût.

Choisir les prochaines vérifications

Pour utiliser Gemini 4 Argon dans OpenCode, commencez par un court échange de texte, puis vérifiez les comportements précis des outils et de l’historique dont votre travail a besoin. Traitez la continuation et les flux interrompus comme des cas de validation distincts. Gardez la page du modèle et la référence API native à portée de main avec la configuration du client, pour consulter facilement les détails du protocole et les tarifs actuels.