Claude Code vs Codex: contrôles et facture tokens

Claude Code vs Codex: ce qui a bougé en juillet 2026

La question Claude Code vs Codex ne se joue plus seulement sur « qui écrit le meilleur patch ». Fin juillet 2026, les notes produit et les synthèses terrain convergent: les agents coding se battent aussi sur les contrôles d'approbation, la reprise de travail, l'auth des outils (MCP), les artifacts partageables et les surfaces de revue.

Côté Codex, les notes OpenAI autour du 20 juillet (surfaces iOS et tâches) apportent:

• Des formulaires interactifs dans les transcripts et le rendu Mermaid
• La récupération de prompt et la reprise de goals bloqués ou limités en usage
• Des listes de tâches plus lisibles et un travail cross-device plus fiable

Aucun de ces points ne rend le modèle plus intelligent. Tous rendent la tâche opérable.

Côté Claude Code, les digests de juillet listent:

• Un navigateur in-app et les commandes /doctor et /fork
• Le partage public d'artifacts et les rôles éditeur Team/Enterprise
• Des artifacts capables d'appeler les connecteurs MCP du lecteur
• Un auto mode élargi sur des plateformes cloud (Bedrock, Agent Platform Google, Microsoft Foundry selon les notes de synthèse)

Là encore, on parle d'un OS d'agent, plus seulement d'un chat.

Le 7 juillet 2026, le changelog GitHub pour JetBrains ajoute Codex comme agent provider en preview publique, avec des hooks, une gestion MCP enrichie, des modèles custom admin et des réglages d'approbation pour les sessions Copilot CLI. Le choix d'agent devient une policy IDE, plus seulement un goût personnel.

La vraie guerre: les modes d'approbation

Un agent coding sans contrat d'approbation reste une démo. Avec un contrat, il devient un outil d'équipe. Les deux stacks poussent des curseurs: tout demander, auto-approuver certains edits, des modes auto ou full access, une sandbox OS ou une policy applicative.

Les synthèses comparatives (Firecrawl en juin 2026, puis les suites) décrivent deux postures. Codex s'appuie fort sur la sandbox OS (read-only, workspace-write, danger-full-access, avec le réseau souvent coupé par défaut). Claude Code pousse une couche applicative riche: des hooks sur des dizaines d'événements de cycle de vie, et un Auto mode avec classifieur comme alternative plus sûre au skip total des permissions. Ces postures sont documentées, pas figées: revérifie-les sur ta version.

Ce que tu dois figer en équipe, quel que soit l'outil: quelles actions sont automatiques (le format, le lint local), quelles actions demandent un clic (une migration, un secret, un push sur main), et ce qui est interdit (la prod live, le paiement, la suppression large). Écris-le sur une page, versionnée comme du code.

Si chaque dev garde son mode yolo personnel, la stack n'existe pas vraiment: tu accumules juste des incidents futurs.

Pourquoi la facture tokens flambe (subagents, workflows dynamiques)

Dès que tu lances des subagents, des workflows dynamiques ou des modes multi-agents (côté OpenAI, le réglage ultra illustre plusieurs agents en parallèle), tu multiplies les fenêtres de contexte et les tours d'outils. Le coût ne ressemble plus à celui d'un chat: tu paies N contextes plus l'orchestration.

On ne publie pas ici de multiplicateur magique universel. Les retours terrain varient selon le repo, les MCP actifs, la taille des diffs et la durée de session. La seule règle honnête consiste à mesurer en interne: les tokens en entrée et en sortie, le coût, la durée, le pourcentage de PRs acceptées sans rework.

Certains leviers marchent sur les deux stacks:

• Une tâche par session et un plan fichier avant toute génération large
• Moins de MCP actifs et des scripts déterministes pour le mécanique
• Un compact ou un résumé intentionnel plutôt qu'une session monstre
• Un plafond de tours et l'interdiction des modes full-access hors d'une sandbox nommée

Si le budget tokens n'a pas d'owner, il n'y a pas de budget. Assigne un owner (le tech lead ou l'équipe platform) et une alerte hebdo.

Ce qu'on garde du guide Claude Code (sans le réécrire)

L'hygiène de session détaillée (la dump zone, compact vs clear, un CLAUDE.md court, les skills, les permissions) vit dans le guide evergreen Claude Code. Cet actu ne la duplique pas: il date les changements produit et pose la policy d'équipe.

Le partage est simple. Si ton problème est « la session pourrit et le modèle divague », lis d'abord le guide. Si ton problème est « on hésite entre deux agents et la facture monte », reste ici.

Un principe reste transversal aux deux outils: ce qui doit survivre hors session s'écrit dans le repo (le plan, les ADR, le handoff, les tests). Un transcript d'agent n'est pas une documentation d'équipe.

La discipline de revue reste la même que pour le code humain: l'auth, le paiement, les migrations et les PII restent en ownership humain (voir aussi la revue de code IA et le human in the loop).

Policy équipe minimale en une page

Une page suffit, avec huit rubriques:

1. L'outil standard par type de job (Claude Code terminal-first pour les refactors locaux, Codex pour les goals cloud si l'équipe vit déjà dans les surfaces OpenAI)
2. Le mode d'approbation par environnement (le dev local, la CI, le monorepo sensible)
3. L'allowlist MCP et les secrets
4. Les interdits explicites
5. Le plafond de tokens par jour et par projet
6. Le format de plan fichier obligatoire au-delà de N fichiers touchés
7. Les logs et qui lit les incidents
8. Un owner nommé et une date de revue

Standardise d'abord les primitives de policy, ensuite le vendor. Si chaque IDE a ses hooks et ses approvals sans contrat commun, tu empiles de la dette de gouvernance.

Les artifacts partageables et les connecteurs MCP du lecteur ont un upside évident (une mini-app de revue) et un risque réel: l'identité, le scope, l'audit. Note dans la policy quel artifact peut appeler quels outils, et ce qui se passe hors du contexte d'origine.

Côté forme, un fichier POLICY-AGENTS.md (ou équivalent) dans le repo d'équipe suffit, avec une PR obligatoire pour le modifier.

Faut-il dual-stack Claude Code + Codex ?

Un dual-stack non gouverné apporte une double courbe d'apprentissage, une double surface d'incident et des comparaisons au feeling sur Slack. Un dual-stack gouverné assigne un outil par classe de job, avec les mêmes règles d'approbation et de budget, et des evals internes partagées.

Pour beaucoup de PME, un outil standardisé plus une policy écrite bat deux outils adoptés « parce que le leaderboard a bougé ». Tu peux toujours ouvrir un second agent en bac à sable pour un POC de 2 semaines, avec un owner et une date de fin.

Les critères de choix ne font pas un ranking absolu:

• La profondeur du harness et des hooks, souvent citée pour Claude Code
• Les surfaces cloud, mobile et la reprise de goals, souvent citées pour Codex
• L'intégration IDE déjà payée (Copilot, JetBrains)
• La conformité et la facturation existantes

Revalide ces critères sur ta stack, pas sur un thread Reddit.

Les sources de cette synthèse, à rouvrir avant de figer une décision: Developers Digest « Codex and Claude Code in July 2026: Agent Controls Are the Feature » (26 juil. 2026), Firecrawl « Claude Code vs Codex » (3 juin 2026), le changelog GitHub JetBrains Codex provider (7 juil. 2026), les notes produit OpenAI et le What's New de Claude Code.

Si vous voulez écrire la policy agents et le routing d'outils sur un process réel, on peut cadrer en 20-40 minutes.

Questions fréquentes