Conclusion en cinq secondes : un même modèle peut consommer des quantités très différentes selon le contexte envoyé à chaque tour, le nombre d’appels, la quantité de sorties d’outils conservée, le moment de la compaction et la stratégie de retry. Si le modèle est le moteur, le harness est la transmission, l’injection, le GPS et l’équipe des stands.
1. « La même fenêtre de cinq heures, mais deux fois plus de travail » est une observation, pas un benchmark officiel
Un développeur a expliqué sur un réseau social qu’en passant de Codex à OpenCode tout en utilisant le même GPT-5.6 Sol via l’authentification ChatGPT, il avait l’impression d’obtenir plus de deux fois plus de travail dans les mêmes limites de cinq heures et hebdomadaires.
Les réponses évoquaient un autre harness, pi, une possible différence de taille de contexte et l’idée d’utiliser routing et télémétrie pour mesurer la consommation réelle.
La distinction essentielle est la suivante : aucune garantie officielle ne dit qu’OpenCode double le quota.
OpenAI explique officiellement que l’usage de Codex n’est pas un nombre fixe de messages. Il varie selon le modèle, le lieu d’exécution de la tâche, sa complexité, le contexte, le raisonnement, la vitesse et les outils. Certains plans comportent à la fois une fenêtre de cinq heures et une limite hebdomadaire.
Il est donc techniquement plausible qu’un changement de harness modifie fortement l’efficacité. Le facteur exact de deux n’est pas établi.
2. Qu’est-ce qu’un harness ? Tout ce qui entoure le cerveau
Le modèle seul est simple :
Sol = cerveau.
Mais un agent de code décide aussi :
- comment construire les system instructions
- quels fichiers lire
- combien d’historique conserver
- quels tool schemas exposer
- combien de sorties shell/GitHub garder
- combien de retries lancer
- combien de cycles plan, implémentation, review exécuter
- quand compacter le contexte
- quand utiliser des subagents
- comment décider que le travail est fini
Cet ensemble constitue le harness au sens large.
OpenAI emploie elle-même l’expression « Codex harness » et décrit un App Server reliant conversations du modèle, clients et outils.
Donc :
même modèle ne signifie pas même système.
Le même moteur dans deux véhicules de poids et de transmission différents n’aura pas la même consommation.
3. Ce qui brûle le carburant, c’est souvent le bagage transporté à chaque trajet
Une longue session peut transporter encore et encore :
- un historique volumineux
- un gros system prompt
- des règles de projet
- des schemas MCP
- des fichiers du repository
- des logs de terminal
- des résultats de tests
- des erreurs passées
- l’état des retries
Lire une grosse sortie une seule fois n’est pas forcément le pire.
Le vrai coût peut venir du fait qu’un active context énorme accompagne 10, 20 ou 30 appels du modèle.
L’orchestration compte aussi. Si un harness finit en 15 appels et un autre en 30 à cause de planification, recherches répétées et reviews successives, le même modèle aura une consommation totale différente.
Comme intuition :
consommation ≈ bagage × trajets × retries
Ce n’est pas une formule de facturation, mais c’est une bonne règle de conception.
4. Pourquoi OpenCode est intéressant : authentification ChatGPT, MCP et compaction
La documentation OpenCode permet de connecter OpenAI avec l’option ChatGPT Plus/Pro puis de s’authentifier dans le navigateur, séparément de l’entrée manuelle d’une API key.
OpenCode agit aussi comme client MCP pour des serveurs locaux et distants.
Par exemple :
OpenCode → GitHub MCP → MCP base de données → API maison → autres outils
OpenCode fournit aussi une compaction automatique. La documentation actuelle montre le mécanisme activé par défaut avec un checkpoint généré et environ 15 000 tokens récents conservés.
L’idée est :
conserver l’archive dans l’entrepôt sans transporter tout l’entrepôt à chaque requête.
Mais OpenCode avertit également que les serveurs MCP ajoutent du contexte. De gros ensembles d’outils comme GitHub MCP peuvent consommer beaucoup de tokens.
Brancher vingt MCP ne rend pas automatiquement l’agent surpuissant.
On peut aussi finir par lui attacher l’entrepôt sur le dos.
5. Tout piloter depuis ChatGPT via MCP repose presque sur la même architecture
Si ChatGPT est le contrôleur central et que MCP/connectors manipulent GitHub, des serveurs, le cloud et du stockage, on retrouve toujours :
modèle + harness + outils.
ChatGPT → MCP / connector → GitHub, serveur, cloud, stockage
ChatGPT gère les décisions ambiguës, MCP joue le rôle des mains, et les systèmes externes conservent l’état réel.
OpenCode suit le même principe :
OpenCode → MCP / shell / API → repository, serveur, cloud
La différence tient à l’endroit où vivent l’état conversationnel et la boucle d’outils, au moment de la compaction et au mécanisme de vérification finale.
Donc à la question « n’est-ce pas presque la même chose que tout contrôler depuis ChatGPT avec MCP ? » :
architecturalement, oui.
Même bâtiment, autre salle de contrôle.
6. ChatGPT peut-il déléguer un travail à OpenCode ?
OpenCode documente clairement son usage comme client MCP. Il propose également opencode serve, un serveur HTTP/OpenAPI headless, ainsi qu’un SDK et ACP.
Une architecture propre serait :
ChatGPT → bridge MCP léger → OpenCode Server → Sol → MCP / shell / API → GitHub et cloud
Le bridge peut n’exposer que quelques outils de haut niveau :
- lancer une tâche OpenCode
- consulter son statut
- récupérer le résultat final
Ainsi ChatGPT n’a pas besoin de transporter des dizaines de schemas GitHub ni des logs géants à chaque tour. La longue boucle d’exécution reste côté OpenCode et seul le résultat revient.
L’enjeu n’est pas simplement d’ajouter une application.
C’est de déplacer la frontière de la boucle de l’agent.
7. Pour réduire la consommation, réduisez les retours vers l’IA
Une bonne architecture consiste souvent à :
- déplacer les opérations déterministes vers des scripts
- stocker state et receipts hors du chat
- n’exposer que les outils nécessaires
- extraire et résumer les longs logs
- éviter de relire des fichiers inchangés
- sauvegarder la cause d’échec et la next action
- appeler le modèle coûteux seulement pour l’ambiguïté
- renvoyer le readback final de production
La répartition devient :
IA = ambiguïté
scripts/workflows = exécution déterministe
GitHub/DB/state = mémoire
Si l’IA doit redécouvrir « quelle est la prochaine étape ? » à chaque cycle, on paie pour refaire l’inventaire de l’entrepôt.
8. Ce qui n’est pas encore démontré
OpenAI documente que Work et Codex partagent une allowance et que la consommation varie notamment avec le contexte et les outils. Des fenêtres de cinq heures et hebdomadaires existent pour certains plans.
OpenCode documente l’authentification ChatGPT Plus/Pro.
En revanche, les sources officielles citées ne fournissent pas une règle universelle disant qu’OpenCode et Codex utilisent exactement la même fonction interne de mesure, ni qu’OpenCode apporte toujours un multiplicateur fixe d’efficacité.
Donc :
« J’ai obtenu deux fois plus » est une mesure intéressante.
« C’est toujours deux fois plus » n’est pas établi.
Un vrai benchmark doit fixer repository, modèle, tâche et critères de fin, puis mesurer appels, tokens, compactions, tool calls, retries, durée et résultat final des tests.
La bonne unité est la consommation par tâche réussie.
9. Conclusion : à l’ère des agents, le câblage compte presque autant que le moteur
Le choix du modèle reste essentiel.
Mais dans les tâches longues avec outils, la gestion du contexte, l’état, le nombre d’outils, les retries, la compaction et les critères de fin influencent aussi fortement la productivité.
Le modèle est le moteur.
Le harness est le reste du véhicule.
Quand vous commencez à relier plusieurs systèmes avec MCP, vous ne faites plus seulement « utiliser de l’IA ».
Vous concevez le lieu de travail de l’IA.
Et l’une des meilleures optimisations consiste parfois à rendre certaines étapes suffisamment mécaniques pour ne plus avoir besoin de rappeler l’IA.
Sources
[1] https://openai.com/index/unlocking-the-codex-harness/ [2] https://help.openai.com/ja-jp/articles/11369540 [3] https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex [4] https://opencode.ai/docs/providers [5] https://opencode.ai/v2/docs/mcp-servers [6] https://opencode.ai/v2/docs/compaction [7] https://dev.opencode.ai/docs/server/ https://dev.opencode.ai/docs/ja/sdk/ [8] https://opencode.ai/v2/docs/cli/acp/
Sources
- OpenAI, Unlocking the Codex harness: how we built the App Server openai.com
- OpenAI Help Center, ChatGPTプランでCodexを使う help.openai.com
- OpenAI Help Center, WorkとCodexでのGPT-6 Astraの利用量管理 help.openai.com
- OpenCode Docs, Providers opencode.ai
- OpenCode Docs, MCP servers opencode.ai
- OpenCode Docs, Compaction opencode.ai
- https://dev.opencode.ai/docs/ja/sdk/ dev.opencode.ai
- OpenCode Docs, ACP opencode.ai
