Gemini 4 Carbon et Hydrogen fonctionnent idéalement en binôme : Carbon planifie, Hydrogen construit. Confiez la Tâche à un Agent planificateur sous Carbon, laissez-le rédiger les sous-tâches assorties de critères d'acceptation, transmettez-les à des Agents exécutants et vérificateurs sous Hydrogen, et renvoyez tout échec répété au planificateur. Vous ne payez ainsi le tarif des modèles de pointe que pour les étapes nécessitant véritablement leur niveau de discernement.
Pourquoi associer Gemini 4 Carbon et Hydrogen ?
Google a lancé Gemini 4 Hydrogen le 12 novembre 2026 en le qualifiant d'« outil du quotidien pour les flux de travail agentiques ». Deux jours plus tôt, le 10 novembre, le journal des modifications de l'API Gemini annonçait la disponibilité générale de Gemini 4 Carbon. Pour la première fois ce mois-ci, vous pouvez donc mobiliser à la fois le modèle le plus puissant de Google et son modèle d'exécution rapide au service d'une même Tâche.
L'argumentaire de Google en faveur d'Hydrogen mise pleinement sur cette complémentarité. L'article de lancement indique que Carbon peut agir en tant que coordinateur tandis qu'Hydrogen propulse « des agents exécutants et vérificateurs chargés d'implémenter et de tester des modifications simultanément dans des espaces de travail isolés ». Le guide de l'API Gemini le formule plus directement : laissez Carbon concevoir les interfaces ou résoudre les blocages complexes, puis déléguez les modifications de code, les sous-tâches parallèles entre agents et l'exécution des tests à Hydrogen.
Il s'agit là d'un modèle d'orchestration, et non d'une fonctionnalité propre au modèle, que vous pouvez mettre en place sur votre propre tableau dès aujourd'hui. Si vous préférez intégrer cette logique directement au tableau plutôt que de vous reposer sur un script local, c'est sur Sharkly que vivent vos Tâches, vos Agents et vos revues.
Ce que fait l'Orchestrator de Google, en un paragraphe
Orchestrator est une option de modèle au sein de Google Antigravity qui alterne entre un planificateur (Carbon ou Argon) et Hydrogen au sein d'une même conversation. Selon la documentation d'Antigravity, le planificateur commence par une phase en lecture seule, établit un plan assorti de déclencheurs explicites de replanification, puis confie l'exécution à Hydrogen. Hydrogen lui rend la main dès qu'il rencontre une friction.
La documentation cite trois signaux de friction particulièrement pertinents à reprendre à votre compte :
- Une étape de vérification qui échoue à deux reprises.
- Une interface qui se comporte différemment de ce que prévoyait le plan.
- Un choix de conception que le plan n'a pas tranché.
Google indique que sur Terminal-Bench, Orchestrator a atteint un taux de réussite quasi identique à celui de Carbon tout en consommant 24 % de quota en moins et en s'exécutant 19 % plus vite en moyenne. Les deux articles de Google divergent quant à la version du benchmark (l'article de lancement mentionne la version 4.0, tandis que l'article d'Antigravity indique la 4.1) ; en attendant que Google clarifie la situation, tenez-vous-en à l'appellation Terminal-Bench.
Orchestrator conserve un agent unique dans votre conversation, utilise une configuration figée sans contrôle sur le niveau de réflexion, et, dans sa variante Carbon, est réservé à Google AI Ultra. Un tableau d'équipe répartit cette même division du travail entre plusieurs Agents, rendant le plan et les passages de relais visibles par tous.
L'argument financier : tarification de Gemini 4 Hydrogen vs Carbon
Tarifs des tokens issus de la page des tarifs de l'API Gemini, consultée le 13 novembre 2026 :
| Modèle | API model id | Entrée / 1 M | Sortie / 1 M | Offre gratuite |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
2,00 $ jusqu'au 30 nov., puis 4,00 $ | 10,00 $ jusqu'au 30 nov., puis 20,00 $ | Non |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
1,50 $ | 7,50 $ | Oui, avec quotas de requêtes |
Examinez bien les dates avant d'établir un budget prévisionnel. Jusqu'au 30 novembre, Hydrogen n'est que 25 % moins cher par token que Carbon. À partir du 1er décembre, il devient 62,5 % moins cher. Ces deux chiffres résultent de nos calculs basés sur les tarifs officiels de Google.
Voici ce que cela donne sur une exécution type, toujours d'après nos calculs. Prenons le tour d'un exécutant qui lit 200 k tokens et en génère 40 k (la sortie incluant les tokens de réflexion). Sur Carbon après le 1er décembre, le coût s'élève à 0,80 $ + 0,80 $ = 1,60 $. Sur Hydrogen, il est de 0,30 $ + 0,30 $ = 0,60 $. Répétez cela 30 fois par jour tout au long d'un sprint, et la différence cesse d'être une simple erreur d'arrondi.
Le coût unitaire par token sous-estime la différence réelle. Google précise que Carbon « consomme davantage de tokens de réflexion par tour afin d'éprouver des hypothèses et de valider les cas limites », or la tarification de sortie intègre cette réflexion. Une même modification sur Carbon facturera donc très probablement un volume de tokens de sortie supérieur, en plus d'un tarif plus élevé. Google ne publiant aucun chiffre de coût moyen par tâche pour ce binôme, évaluez-le sur votre propre dépôt avant d'avancer une quelconque économie.
La vitesse constitue l'autre atout majeur : Google indique qu'Hydrogen accomplit ses tâches 2,5 fois plus vite que Gemini 3.8 Flash avec son réglage par défaut high.
Répartir le travail dans votre équipe d'agents : à chaque rôle son modèle
La séparation planificateur/exécutant formalise une division du travail claire : un Agent prend en charge le plan et les arbitrages complexes, des Agents plus économiques assurent l'exécution, et un vérificateur valide le résultat avant toute revue humaine. Chaque rôle se voit attribuer le modèle dont le coût et les capacités d'analyse correspondent aux besoins.
| Rôle | Modèle | Niveau de réflexion | Responsabilités |
|---|---|---|---|
| Planificateur | gemini-4-carbon |
medium par défaut, high pour les Tâches complexes |
Analyse de la base de code, rédaction des sous-tâches avec critères d'acceptation, replanification |
| Exécutant (1 à n) | gemini-4-hydrogen |
high (par défaut) |
Modifications de code, mises à jour de paquets, tests, à raison d'une sous-tâche chacun |
| Vérificateur | gemini-4-hydrogen |
high, xhigh pour les diffs à risque |
Exécution des vérifications selon les critères d'acceptation du planificateur |
| Humain | n/a | n/a | Validation du plan pour les Tâches d'envergure, acceptation du résultat |
Deux précisions issues de la documentation de Google sous-tendent ce tableau. Carbon et Argon utilisent par défaut le niveau medium et plafonnent à high, tandis qu'Hydrogen est configuré par défaut sur high et propose en plus xhigh. Google met toutefois en garde : le niveau xhigh augmente la latence ainsi que la consommation de tokens et « peut entraîner une réflexion excessive sur les requêtes simples ». Réservez xhigh au vérificateur pour les diffs touchant à l'authentification, aux paiements ou aux migrations de données.
Que doit rédiger le planificateur ?
Ce que produit le planificateur sert de contrat pour tous les intervenants en aval. Un bon plan comprend une sous-tâche par modification indépendante, le périmètre des fichiers concernés, la commande prouvant le bon fonctionnement et la condition entraînant un renvoi. Si un exécutant ne peut déterminer avec certitude si son travail est achevé, c'est que le plan est incomplet.
Quand le travail doit-il revenir au planificateur ?
Reprenez la liste de déclencheurs établie par Google et rendez-la explicite. Un exécutant renvoie une sous-tâche dès lors que sa vérification échoue deux fois, qu'une interface ne correspond pas au plan ou qu'un arbitrage de conception s'impose. Il la renvoie accompagnée des logs, du diff produit jusqu'alors et de la question soulevée. Il ne doit jamais relancer discrètement la tentative sur un modèle plus puissant, car cela masquerait le coût de l'offre économique derrière la facture d'un modèle haut de gamme.
Mise en place dans Sharkly
Dans Sharkly, un Agent est un coéquipier d'IA exécuté via un Runtime sur un Computer connecté, et une Crew désigne un groupe d'Agents et d'humains coordonné par un Agent leader. Cette structure s'adapte parfaitement à la séparation planificateur/exécutant, sans nécessiter la moindre ligne de code de liaison. Le planificateur assume le rôle de leader de la Crew ; les exécutants et le vérificateur en sont les membres.
Chaque Agent dispose de son propre Runtime et de son propre Default model, comme illustré dans le panneau ci-dessus (qui fait tourner Claude Code). Pour cette configuration, attribuez à chaque Agent un Runtime capable de communiquer avec l'API Gemini, comme Gemini CLI, et définissez le modèle par Agent : Carbon pour le planificateur, Hydrogen pour les autres. Si la liste des modèles n'affiche pas encore les nouveaux identifiants, indiquez le modèle dans la configuration propre au Runtime. Gemini CLI lit également la variable d'environnement GEMINI_MODEL, selon sa documentation de référence de configuration, et les Agents prennent en charge les variables d'environnement individuelles.
Rédigez ensuite les règles de coordination dans les instructions de la Crew :
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
Attribuez la Tâche à la Crew. L'exécution commence par le leader, conformément à la documentation de Crews : le leader prend connaissance de la Tâche et des instructions de la Crew, puis mentionne les membres pour des contributions spécifiques, et leurs résultats sont regroupés au sein de la même Tâche. Utilisez des répertoires de travail temporaires afin que chaque exécutant dispose de son propre worktree. N'activez le répertoire de Tâche partagé de la Crew que lorsque les sous-tâches doivent s'appuyer successivement sur les modifications locales des unes et des autres.
Les tâches bloquées restent visibles : les exécutions en échec ou interrompues aboutissent dans l'Inbox, et tout Agent en attente d'une intervention humaine apparaît dans la section Task Chats de la barre latérale. C'est précisément là qu'aboutit la flèche en pointillés lorsque le planificateur ne parvient pas à corriger le plan.
Techniques avancées
Exploitez l'alternance de modèles via l'API pour une longue Tâche. La documentation de Google indique que vous pouvez acheminer les phases de planification vers gemini-4-carbon et les phases d'exécution vers gemini-4-hydrogen au sein d'une même session multi-tours à l'aide de previous_interaction_id, sans aucune modification de schéma. C'est l'astuce d'Orchestrator directement intégrée à votre propre code, particulièrement utile au cours de l'exécution d'un Agent unique.
Prenez garde aux limites par requête. Hydrogen peut renvoyer jusqu'à 65 536 tokens par étape (hop) hors streaming, tandis que Carbon et Argon en renvoient au maximum 32 768 par étape REST hors streaming. Réservez les générations volumineuses, telles que les suites de tests et les spécifications de migration, aux exécutants.
Oubliez la mise en cache explicite sur Hydrogen. Hydrogen ne prend pas en charge la mise en cache explicite de contexte. La mise en cache implicite s'active sur les requêtes d'au moins 4 096 tokens et applique une réduction de 95 % sur les tokens d'entrée mis en cache ; veillez donc à placer le contexte partagé du dépôt au tout début de chaque prompt destiné aux exécutants.
Les alternatives à la séparation planificateur/exécutant
- Hydrogen seul. La documentation de Google le recommande pour les montées de version de paquets, la déduplication, la génération de structures de code (scaffolding), les tests unitaires de fonctions bien circonscrites et la documentation. Aucun planificateur n'est requis.
- Carbon seul. Idéal pour la conception de systèmes distribués, l'analyse des conditions de concurrence (race conditions) ou les migrations multi-dépôts, où chaque étape exige une grande profondeur d'analyse.
- Orchestrator dans Antigravity. Un seul utilisateur, une seule conversation, des passages de relais automatiques, sur les forfaits qui l'intègrent.
- Un routeur statique. Qualifiez la Tâche en amont et orientez-la vers un unique modèle. Google souligne toutefois les limites de cette approche sur les processus longs, où le niveau de complexité évolue en cours de route. Nous avions abordé cette méthode préalable dans notre article sur l'aiguillage des Tâches d'agents avec l'API Gemini Decisions.
Cas d'usage concrets
Triage d'incidents à grande échelle. La démonstration du SDK Antigravity conçue par Google associe des agents Hydrogen pour le tri et le développement à un agent Carbon dédié aux refactorisations, aux nouvelles fonctionnalités et aux contrôles de sécurité. Sur un tableau de projet, cela correspond à un Agent Hydrogen gérant la file d'attente entrante et à un leader sous Carbon intervenant sur tout élément étiqueté refactoring ou sécurité.
Découpage d'une fonctionnalité en sous-tâches parallèles. Le planificateur décompose une modification d'API en plusieurs volets (schéma, contrôleur et client) ; trois exécutants les réalisent dans des worktrees distincts ; le vérificateur exécute enfin les tests de contrat.
Conclusion
Carbon planifie, Hydrogen construit et un humain valide. La tarification rend cette répartition particulièrement avantageuse dès le 1er décembre, les signaux de friction évitent que des erreurs à faible coût ne dégénèrent en itérations dispendieuses, et le tableau consigne chaque passage de relais au sein de la Tâche à la vue de toute l'équipe. Pour approfondir ce paradigme, découvrez ce qu'est l'orchestration d'agents d'IA ainsi que notre règle de routage de modèles pour les Crews.
Votre prochaine étape : connectez un Computer à Sharkly, créez un Agent planificateur sous Carbon et un exécutant sous Hydrogen, rassemblez-les dans une Crew avec les instructions ci-dessus, et confiez-lui une Tâche que vous délégueriez d'ordinaire à un collègue pour une demi-journée. Sharkly proposant un forfait gratuit, ce test ne vous coûtera que les tokens Gemini consommés.
FAQ
Quelle est la différence entre Gemini 4 Carbon et Hydrogen ?
Carbon est le modèle frontière le plus performant de Google, conçu pour le raisonnement à long terme ainsi que pour les travaux complexes d'architecture, de débogage et de sécurité. Hydrogen est le modèle rapide et économique de la gamme Gemini 4, taillé pour le développement quotidien et l'exécution d'agents. Carbon utilise par défaut le niveau de réflexion medium et plafonne à high ; Hydrogen utilise par défaut high et propose le niveau xhigh.
Gemini 4 Hydrogen est-il moins cher que Carbon ?
Oui. Hydrogen est facturé 1,50 $ par million de tokens d'entrée et 7,50 $ par million de tokens de sortie. Carbon coûte 2 $ et 10 $ jusqu'au 30 novembre 2026, puis 4 $ et 20 $ à compter du 1er décembre. De plus, Hydrogen propose un niveau gratuit soumis à des quotas sur l'API Gemini, ce qui n'est pas le cas de Carbon.
Le vérificateur doit-il tourner sous Carbon plutôt que sous Hydrogen ?
Pas par défaut. Google préconise Hydrogen pour les agents exécutants et vérificateurs fonctionnant en parallèle. Utilisez le réglage xhigh pour le vérificateur lors de diffs sensibles, et ne réescaladez la Tâche vers le planificateur sous Carbon qu'après deux échecs consécutifs d'une vérification.
Sharkly choisit-il automatiquement le modèle pour chaque Tâche ?
Non. Vous définissez le modèle pour chaque Agent via son Runtime, et les instructions de la Crew déterminent quel Agent prend en charge chaque volet de la Tâche. Sharkly centralise la Tâche, les exécutions, les passages de relais et la revue.
