Le chapitre un fait tourner une mission de bout en bout en quatre-vingt-dix secondes. Les sept autres ouvrent les pièces qu'elle a traversées : le conseil qui relit un plan, la carte du code, l'équipage, les règles, les routines, l'argent et le journal d'audit. Commencez où vous voulez, partez quand vous voulez. Sans inscription, sans mur, sans rien à installer.
Simulation guidée. Données scénarisées, vrai déroulé du produit.
Étape 1 sur 6
Voici Carth en 90 secondes. Rien ici n'est en direct, tout ici est le fonctionnement réel.
Vous allez faire les deux choses qu'une personne fait réellement dans Carth : écrire le brief, et décider si le travail part en production. L'équipage fait tout ce qu'il y a entre les deux, et vous le regardez depuis le même écran que votre équipe.
Choisir vos moteursBriefer une missionValider ce qui part
Choisissez les moteurs qui animent votre équipage.
Carth dirige chaque rôle vers un fournisseur, avec vos propres clés. Choisissez les deux ici, et la suite de la visite portera leur nom.
Au catalogue seulement
GeminiGrok
Leurs modèles sont suivis et tarifés dans votre catalogue, et aucun agent ne leur est envoyé tant qu'un adaptateur n'est pas livré. Les noms des fournisseurs sont les marques de leurs propriétaires.
Un rôle réglé sur Codex bascule sur Claude quand la commande Codex n'est pas installée sur la machine, et ce repli est enregistré comme un événement. C'est le comportement réel, pas un raccourci pris pour cette page.
Étape 3 sur 6
Écrivez le brief.
Une phrase simple sur le résultat que vous voulez. Modifiez-la si vous voulez : elle est reprise dans toute la suite de la visite.
Type de travail FonctionnalitéDépôt bakery-siteAgents en parallèle 3
Dans votre cockpit, ceci envoie un planificateur qui lit le dépôt en lecture seule et revient avec des tâches, des hypothèses et un coût approximatif avant le moindre centime dépensé. Ici, c'est un enregistrement qui se joue.
Étape 4 sur 6
L'équipage prend le relais.
Planification, construction, relecture. Vous pouvez fermer l'onglet et revenir vers une décision qui vous attend.
m_4f21c9
Créez une page d'accueil pour notre boulangerie avec un formulaire de commande
relire les diffs
Planification
Construction
Relecture
PlanificateurClaude
ConstructeurClaude
RelecteurClaude
Analystepas sur celle-ci
Ce que fait l'équipage
00:04Le planificateur a lu le dépôt en lecture seule et a découpé ceci en 3 tâches.
00:11Plan validé. 3 tâches envoyées, 3 agents au travail en même temps.
00:26Le constructeur travaille dans un worktree isolé sur mission/m_4f21c9/t1.
01:12Preuves enregistrées sur la mission : deux dessins et une série de tests.
01:48Le relecteur a trouvé un problème dans le formulaire de commande. Le constructeur l'a corrigé.
02:05Les diffs vous attendent. Rien n'a été commité ni poussé.
Dans le vrai cockpit, le plan est aussi une porte : vous le lisez et vous le validez avant qu'un agent ne dépense quoi que ce soit. Cette visite le valide à votre place pour que l'ensemble tienne en moins de deux minutes.
Étape 5 sur 6
Votre porte. Les images d'abord, le diff en dessous.
Celui qui valide n'est pas toujours celui qui lit le code, alors le travail se montre avant de plaider.
m_4f21c9
Créez une page d'accueil pour notre boulangerie avec un formulaire de commande
relire les diffs
3 fichiers modifiés+214-6mission/m_4f21c9/t1
Preuves
Ce que l'équipage a enregistré pour montrer son travail.
La page d'accueil, dessinée d'après votre phraseLe formulaire de commandeTests, tous au vert
Fusionner et déployer ?
Enregistré avec votre nom et l'heure.
Le constructeur ajuste le formulaire de commande...
Tour 2. Vous l'avez renvoyé, le constructeur l'a modifié, et le relecteur l'a repassé. Cette boucle tourne à l'intérieur du port autant de fois qu'il le faut, et vous n'en voyez que le résultat.
Valider commite le travail sur sa propre branche. Fusionner vers develop et promouvoir en production sont deux appuis de plus après celui-ci, chacun tenu par un rôle et chacun enregistré. Rien ici ne fusionne tout seul.
Étape 6 sur 6
En production.
C'est ce que fait votre vrai cockpit, avec vos dépôts et vos règles.
Vous avez écrit une ligne. L'équipage l'a planifiée, construite et relue avant qu'on ne vous demande quoi que ce soit.
Chaque construction s'est faite dans un worktree isolé. Votre branche principale n'a jamais été touchée.
Rien n'a bougé avant que vous n'appuyiez sur valider, et le journal porte votre nom et l'heure.
Voilà pour le chapitre un. La suite de la visite ouvre les autres pièces du cockpit : le conseil qui relit un plan avant qu'il ne tourne, la carte que l'équipage lit, l'équipage lui-même, les règles dans lesquelles il travaille, le travail qui se fait à heure fixe, ce que tout cela coûte, et ce qui est consigné.
Chapitre 2 sur 8 3 séquences
Avant de valider un plan, soumettez-le à un conseil.
Le plan que vous venez de valider n'avait qu'un seul modèle derrière lui. Council remet ce même plan à trois sièges à la fois, chacun le lisant de son côté, et vous rend où ils s'accordent, où ils divergent et le raisonnement derrière chaque position. Sur Enterprise.
Un plan, trois sièges
Vous choisissez les modèles qui siègent. Chaque siège reçoit le même plan de mission, le relit seul avec des outils en lecture seule, et ne voit jamais la réponse d'un autre siège : rien de ce que dit l'un ne peut donc tirer les autres vers lui.
Les liens barrés sont tout l'enjeu. Il n'existe aucun canal entre les sièges : les trois lectures ne se rencontrent pour la première fois que sur votre écran.
Ce qui revient
Les trois réponses sont mises côte à côte par arithmétique et non par un quatrième modèle. Là où les verdicts coïncident, c'est l'accord ; là où ils diffèrent, c'est la divergence ; et chaque position reste attribuée au siège qui l'a tenue.
Claude OpusRéservesLa tâche 2 envoie le formulaire de commande vers une route qui n'existe pas encore, et rien dans le plan ne la crée.
Claude SonnetApprouveTrois petites tâches, et les tests nommés dans la tâche 3 couvrent le formulaire demandé par le brief.
CodexRéservesLa même route manquante, et un formulaire public sans aucune limite de débit devant lui.
Deux des trois ont soulevé la route manquante : c'est montré comme deux sièges qui la soulèvent, et non comme un score.
Ici, ils divergent, et c'est cette divergence que vous êtes venu chercher. Un siège aurait lancé le plan, deux non, et ce qui mérite d'être lu, c'est la route dont aucun d'eux n'a été prévenu par les autres. Un agent qui se donne raison à lui-même n'est pas un second avis.
Qui siège, et à quelle fréquence
Le conseil de cette installation
SiègesTrois, toujours
Siègent aujourd'huiClaude Opus, Claude Sonnet, Codex
Peuvent siégerClaude et Codex
Ce mois-ci4 séances de conseil sur 20 utilisées
Les sièges vous appartiennent. Seul un moteur capable de faire tourner un agent peut en occuper un, parce qu'un modèle qui ne peut pas lire vos dépôts et rendre compte ne relit rien du tout. Les trois ne peuvent pas tenir le même modèle : des modèles identiques produisent des réponses corrélées, ce qui est une illusion de consensus qui coûte cher.
Un conseil, c'est plusieurs minutes de travail facturé sur trois moteurs : l'allocation se compte donc par installation et par mois calendaire. Le décompte est lu dans le journal des exécutions, qui est aussi le registre de ce qui a été demandé et quand.
Council est sur Enterprise. Il relit le plan, avant que quoi que ce soit ne soit construit, et il est donc convoqué depuis une mission dont le plan attend à sa porte ; le relecteur croisé au chapitre un est celui qui lit le travail fini. Les verdicts ci-dessus sont scénarisés, comme tous les autres chiffres de cette visite. Les trois sièges, le refus et l'allocation mensuelle sont ceux du produit.
Chapitre 3 sur 8 3 séquences
L'équipage lit la carte avant d'écrire une ligne.
Carth construit un graphe de vos dépôts et le garde. Chaque mission part de cette carte, donc un agent ne paie pas pour redécouvrir votre base de code à chaque question qu'on lui pose.
La carte
Un point est un fichier. Une couleur est une communauté trouvée par le graphe. Les traits gris sont les rares endroits où une partie de la base de code en atteint une autre.
62Points d'entrée du backend
143Appels depuis les écrans
138Bien reliés
5À regarder
Une communauté
Le graphe regroupe les fichiers qui changent ensemble. Celle-ci est le parcours de commande : dix-huit fichiers, un tunnel d'achat, et les deux traits fins qui en sortent sont les seuls endroits où le reste de la base de code y touche.
Commande18 fichiers, 2 liens sortants
Un nœud
POST /api/orders
CommunautéCommande
Appelé par24 écrans
VerdictBien relié
Les points d'entrée les plus utilisés viennent en premier, parce qu'en modifier un touche le plus d'écrans. Les appels qui ne correspondent à aucune route sont listés à part, et c'est en général du vieux code.
Code a trois vues dans le cockpit : ce graphe, l'écart de version entre develop et main, et les exports bruts qui alimentent les deux. La disposition dessinée ici est échantillonnée sur une vraie carte de 2105 nœuds répartis en 134 communautés ; les chiffres à côté sont scénarisés, comme tout le reste de cette visite.
Chapitre 4 sur 8 3 séquences
Faites connaissance avec l'équipage, puis nommez le vôtre.
Une mission distribue des rôles génériques : planificateur, implémenteur, relecteur, évaluateur. La composition décide qui les tient. Quel moteur répond à chaque rôle se règle une pièce plus loin, dans Réglages, et la dernière séquence dit où.
La composition
Les rôles sont génériques. Les agents qui les tiennent ne le sont pas : chacun a une catégorie, une expertise et des mots-clés, et une mission envoie celui dont les mots-clés correspondent à la tâche.
SherlockInvestigationLit avant de toucher. Reproduit le problème d'abord.
MaestroImplémentationConstruit la modification dans son propre worktree.
VeraÉvaluationLa porte avant la vôtre : elle passe ou elle renvoie.
CipherSécuritéSécurité applicative. Gagne une relecture sur un mot-clé.
WardenSécuritéInfrastructure et exploitation.
Une mission envoie Cipher avec le prompt système de Cipher, pas un relecteur sans visage.
Votre propre agent
Décrivez le spécialiste que vous auriez aimé avoir. Un agent en lecture seule rédige le profil, et rien n'est enregistré tant que vous n'avez pas lu chaque champ.
Vous avez écritUn agent qui connaît notre tunnel d'achat et qui refuse qu'un prix soit calculé à deux endroits.
Nom
Sable
Catégorie
Relecture
Expertise
Tunnel d'achat, prix, totaux de commande
Mots-clés
checkoutpricetotalcart
Modèle
Défaut de la catégorie Sonnet 5
Garde-fou qu'il porte
Ne jamais réimplémenter un total de commande. Utiliser celui qui fait foi.
Enregistrer l'agentRédigé en lecture seule. Vous modifiez chaque champ avant qu'il existe.
La matrice des rôles, qui vit dans Réglages
Équipage, c'est le flux en direct et la composition, rien d'autre. La table ci-dessous est un panneau de Réglages, ouvert depuis le menu du compte en bas de la barre latérale. Elle est montrée ici parce qu'elle est l'autre moitié de la même histoire : la composition dit qui sont les agents, la matrice dit quel moteur répond à quel rôle.
Mode : BalancedEco et Max quality remplissent la même table en un appui
Quel moteur répond à quel rôle
Rôle
Moteur
Modèle
Effort
Planificateur
Claude
Opus 5
high
Implémenteur
Codex
GPT-5.6 Terra
défaut du fournisseur
Relecteur
Claude
Sonnet 5
medium
Évaluateur, Vera
Claude
Haiku 4.5
low
C'est le choix que vous avez fait au chapitre un, écrit en entier. Un réglage propre à une mission l'emporte sur la table, et un rôle sans ligne garde sa valeur par défaut.
Équipage a deux vues : le flux en direct des missions en cours, et la composition. La composition modifie qui fait quoi, elle est donc réservée à l'admin, et une personne qui ne l'est pas arrive sur le flux en direct. Réglages est réservé à l'admin pour la même raison, et c'est pourquoi la matrice des rôles se tient derrière le menu du compte plutôt que dans la barre latérale.
Chapitre 5 sur 8 3 séquences
Les lignes à l'intérieur desquelles l'équipage travaille.
Trois choses différentes vivent ici, et la différence entre elles est tout l'enjeu : un garde-fou bloque une action, une règle est une consigne que chaque agent porte, et une compétence est une commande que vous pouvez lancer.
Un garde-fou, et une compétence
Garde-fouNe jamais toucher à main
PreToolUse / Bash
Un script qui tourne avant l'outil. Le code de sortie 2 bloque l'action, le code 0 l'autorise.
Actif, il applique
Compétence/release-notes
Commande en markdown
Transforme le travail fusionné de la veille en notes de version. Disponible dans les nouvelles sessions de la console dès que vous l'enregistrez.
Active
Désactiver un garde-fou demande une confirmation, parce qu'il cesse d'appliquer. Désactiver une compétence renomme simplement le fichier, et la réactiver le restaure à l'identique.
Une règle de fonctionnement
Règlevérifier, ne pas deviner
developmentlivrée avec le produit
Lire le code, lancer la commande, vérifier la configuration. Ne jamais présenter une supposition plausible comme un fait.
Active, dans le contexte de chaque agent
Les règles actives sont pliées dans le prompt de chaque agent, sur les missions comme dans la console. Une règle est une consigne, pas une contrainte : c'est le garde-fou au-dessus qui arrête réellement une commande.
Une mission, bloquée
Bloquée par Ne jamais toucher à main
git push origin main
Le constructeur a tenté de pousser. Le garde-fou l'a arrêté avant que la commande ne tourne, la tentative figure dans le journal de la mission avec l'heure, et le travail attend toujours dans son worktree. Rien n'a été poussé.
Mise en attente par le budget du jour
20,00 $ sur 20,00 $ utilisés
La file a atteint le plafond du jour, alors elle a mis la mission suivante en attente avec un événement de budget et vous l'a dit, au lieu de la lancer et de le découvrir après. Un plafond à zéro veut dire aucun plafond, jamais « tout bloquer ».
Sous ces trois choses, il y a une liste que les agents ne peuvent pas discuter. Les exécutions autorisées à écrire se voient refuser git push, git commit, git reset, rm, sudo, docker, npm publish et le reste de la liste rouge, et elles restent enfermées dans leur propre worktree. Chaque commit, chaque fusion et chaque déploiement est un appui humain distinct.
Chapitre 6 sur 8 3 séquences
Du travail permanent, à l'heure dite.
Vous en activez une, vous réglez l'heure, et vous revenez vérifier qu'elle a tourné. Trois sont livrées avec le produit et les trois sont éteintes tant que personne ne les allume.
Une routine
Veille de sécuritéActive
Compare les versions de vos dépendances aux alertes en cours et dépose au backlog tout ce qui est élevé ou moyen. Rapport seulement.
HebdomadaireLundi07:00
Prochaine exécutionlun. 18 août, 07:00
Dernière exécutionlun. 11 août, 07:00
RésultatA bien tourné
Historique6 exécutions gardées
Chaque exécution garde un petit rapport, et celle qui a lancé une mission renvoie vers elle.
Ce qu'elle a déposé
L'exécution de lundi a trouvé deux alertes et les a déposées. L'une est devenue une mission, et cette mission a rejoint la file exactement là où une mission écrite par vous l'aurait rejointe : en attente d'une personne.
m_7c04a1
Alertes de dépendances, semaine du 11 août
en attente de validation
Déposée par Veille de sécurité, pas par une personne. Elle attend à la même porte.
Ce qu'une routine ne peut pas faire
Elle ne peut pas fusionner.
Elle ne peut pas déployer.
Elle ne peut pas promouvoir en production.
Elle peut regarder, rapporter, et déposer du travail qu'une personne validera.
Une routine passe son tour quand l'exécution précédente tourne encore, ou quand le budget du jour est déjà dépensé. Si la machine était éteinte à l'heure prévue, elle tourne une seule fois au tic suivant plutôt que de rattraper une semaine d'un coup.
Les trois routines livrées sont Contrôle de la mémoire, quotidienne et rapport seulement ; Veille de sécurité, hebdomadaire et rapport seulement ; et Santé des serveurs, quotidienne, qui interroge les adresses que vous avez configurées et ne consomme aucun token d'IA. Au-delà, un admin peut écrire une routine qui lance une mission d'agent ou une simple commande locale à heure fixe.
Chapitre 7 sur 8 3 séquences
Ce que ça a coûté, par mission, par modèle, par rôle.
Des dollars réels là où l'exécution les a rapportés, un prix tiré de votre catalogue de modèles là où seuls les tokens sont revenus, et la mention estimation quand c'en est une. Un chiffre n'est jamais inventé pour remplir la colonne.
Les sept derniers jours
12,84 $ est.Dépense9,41 $ réels et 3,43 $ estimés
1,9 MTokens1,4 M en entrée, 0,5 M en sortie, sur 84 exécutions
3,10 $Consommation du jour, sur 20 $ de budget16,90 $ restants
~21,40 $ est.ÉconomiePar rapport à tout faire tourner sur Opus 5
La tuile d'économie est une estimation et le dit. Elle compare ce que vous avez dépensé à ce que les mêmes tokens auraient coûté sur un modèle de référence que vous choisissez.
Par mission
Chaque exécution du projet, rassemblée sur la mission qui l'a demandée
Mission
Exéc.
Tokens entrée / sortie
Coût
Page d'accueil et formulaire de commande m_4f21c9
9
412k / 98k
2,41 $
Maestro, GPT-5.6 Terra codex
4
240k / 61k
1,47 $
Planificateur, Opus 5 claude
2
121k / 24k
0,88 $
Vera, Haiku 4.5 claude
3
51k / 13k
0,06 $
Alertes de dépendances m_7c04a1
3
96k / 21k
0,42 $
Réécrire la page des tarifs m_2b81e0
6
188k / 44k
abonnement
Cette dernière ligne est le comportement réel, pas un trou dans les données : une exécution sur un abonnement Max ne remonte aucun montant, alors le cockpit écrit « abonnement » plutôt qu'un prix qu'il n'a pas.
Par modèle, et si ça valait le coup
Des tokens transformés en travail qui a été gardé
Modèle
Exéc.
Coût
Tokens / exéc. réussie
Gaspillage
GPT-5.6 Terra
22
5,90 $
34k
4,1 %
Opus 5
12
3,60 $
41k
0,0 %
Sonnet 5
41
3,10 $
19k
2,6 %
Haiku 4.5 meilleur rapport
9
0,24 $
7k
0,0 %
Le gaspillage, ce sont les tokens dépensés sur des exécutions ratées ou annulées. Une exécution qui a échoué, a été relancée puis a réussi compte comme une reprise et non comme du gaspillage, parce que le travail est bien arrivé. La même table existe par rôle.
Dépenses couvre chaque exécution du projet, pas seulement les missions : les tours de console et le conseiller entrent dans les mêmes chiffres. La vue est en lecture seule et calculée à l'ouverture. Là où un modèle n'a pas de prix dans votre catalogue, la ligne indique « pas de tarif » plutôt que d'afficher un zéro.
Chapitre 8 sur 8 4 séquences
Rien ne franchit l'ouverture sans un nom dessus.
La dernière chose à savoir est celle qui ne change pas avec le brief : ce que l'équipage ne peut pas faire, et ce qui est écrit noir sur blanc dès qu'une personne décide quelque chose.
Qui a validé quoi, et quand
11 août 14:02Maya a validé m_4f21c9 tâche 13 fichiers, +214 / -6
11 août 14:06Maya a fusionné vers develop m_4f21c9branche mission/m_4f21c9/t1
11 août 16:31Leo a promu en production bakery-siteresponsable des mises en production
Trois appuis, trois noms, trois heures. Le journal d'audit est durable : effacer les missions ne l'efface pas.
Vos clés, et ce qu'on remet à un agent
Les clés sont en écriture seule. Le cockpit vous dira qu'une clé existe. Il ne rendra pas sa valeur, ni à vous ni à un agent.
Les agents démarrent sans vos secrets. Pas de jeton du cockpit, pas de répertoire du cockpit, et aucune variable dont le nom ressemble à un jeton, un secret, une clé ou un mot de passe.
Le texte est nettoyé avant d'être enregistré. Clés privées, JWT, clés d'API, chaînes de connexion et adresses e-mail sont retirées à l'entrée du journal, pas à sa sortie.
Où le travail se fait
Un worktree par tâche. Chaque tâche de code se construit sur sa propre branche de mission dans sa propre copie de travail, donc les agents en parallèle ne se gênent jamais et votre branche principale n'est pas dans la pièce.
On ne peut pas pointer un agent vers le cockpit. Si un répertoire de travail devait tomber dans le stock des missions ou le fichier des secrets, le processus est refusé avant de démarrer.
Un conteneur par entreprise. Vos dépôts, vos clés et l'historique de vos missions y restent.
Les trois portes, dans l'ordre
Le planVous lisez ce qu'il compte faire, et ce que ça coûtera, avant le moindre centime dépensé.
La relectureVous lisez les images, les tests et le diff, et vous validez ou vous renvoyez.
La mise en productionFusionner et promouvoir sont deux appuis de plus, chacun tenu par un rôle, chacun enregistré.
Voilà toute la visite.
Sept chapitres, un seul argument : l'équipage va vite à l'intérieur du port, et une personne qui a un nom se tient dans l'unique ouverture.
Vous avez écrit une ligne et l'équipage l'a planifiée, construite et relue avant qu'on ne vous demande quoi que ce soit.
Il a lu la carte d'abord, travaillé sous vos règles, et n'a jamais pu sortir de son propre worktree.
Tout ce que ça a coûté tient sur une page, par mission, par modèle et par rôle.
Rien n'a bougé avant que quelqu'un n'appuie sur valider, et le journal porte un nom et une heure.
Chaque formule commence par une courte candidature, parce que chaque entreprise retenue a un appel de mise en route avec une personne. Nous répondons sous deux jours ouvrés.
Tous les chapitres
La touche Échap ouvre et ferme cette liste.
La même chose, à l'écrit
Toute la visite, en treize paragraphes.
Tout ce que la version guidée vous montre, sans le guide : la mission d'abord, puis les sept pièces qu'elle a traversées. Les données sont scénarisées ; le comportement est celui du produit.
Bienvenue
Carth est un cockpit où un équipage d'agents IA nommés planifie, construit et relit le travail sur le produit, et où une personne valide ce qui part en production. Vous y faites deux choses : écrire le brief, et décider.
Choisir vos moteurs
Chaque rôle tourne sur un fournisseur que vous connectez avec votre propre clé. Claude et Codex font tourner les missions aujourd'hui. Gemini et Grok se tiennent dans le catalogue de modèles, suivis et tarifés, sans qu'aucun agent ne leur soit encore envoyé. Un rôle réglé sur Codex bascule sur Claude quand la commande Codex n'est pas installée, et ce repli est enregistré.
Briefer une mission
Vous écrivez des phrases simples sur le résultat que vous voulez, vous choisissez un type de travail et les dépôts concernés. Le planificateur lit ensuite ces dépôts en lecture seule et revient avec des tâches, des hypothèses et un coût approximatif, et vous validez ce plan avant que rien ne tourne.
Regarder l'équipage
Les tâches validées se déploient en éventail, trois agents à la fois par défaut. Chaque tâche de code se construit dans son propre worktree git sur une branche de mission, de sorte que le travail parallèle ne se gêne jamais et que votre branche principale reste intacte. Un relecteur lit le résultat, lance les contrôles et attache les preuves, et le travail faible est renvoyé à l'intérieur du port avant de vous parvenir.
Votre porte de relecture
La porte s'ouvre sur les images : les dessins et les séries de tests que l'équipage a enregistrés, puis le résumé du diff, puis le diff lui-même. Vous validez ou vous renvoyez. Renvoyer ajoute un tour de correction au brief, et le constructeur se remet au travail.
En production
Valider commite le travail sur sa branche. Le fusionner vers develop et le promouvoir en production sont des appuis distincts, chacun tenu par un rôle et chacun enregistré avec une personne, un moment et les preuves qui vont avec.
Council
Vous choisissez les modèles qui siègent. Un plan qui attend à sa porte peut être soumis à un conseil de trois sièges : chacun relit ce même plan seul, avec des outils en lecture seule, et ne voit jamais la réponse d'un autre siège. Les trois réponses sont ensuite mises côte à côte par arithmétique et non par un quatrième modèle. Là où les verdicts coïncident, c'est l'accord ; là où ils diffèrent, c'est la divergence ; et chaque position reste attribuée au siège qui l'a tenue, avec son propre raisonnement. Un agent qui se donne raison à lui-même n'est pas un second avis. Les sièges se configurent, seul un moteur capable de faire tourner un agent peut en occuper un, les trois ne peuvent pas tenir le même modèle, et l'allocation d'exécutions se compte par installation et par mois calendaire. Council est sur Enterprise.
Code
Carth garde un graphe de vos dépôts : fichiers et symboles en nœuds, rassemblés dans les communautés qui changent ensemble, avec les points d'entrée que vos écrans appellent reliés aux routes qui répondent. Les missions partent de cette carte au lieu de redécouvrir la base de code. La destination Code montre aussi l'écart de version entre develop et main, et les exports bruts dont les deux vues sont issues.
Équipage
La composition dit qui sont les agents : un nom, une catégorie, une expertise et des mots-clés, de sorte qu'une tâche de sécurité envoie Cipher plutôt qu'un relecteur sans visage. Vous pouvez décrire votre propre spécialiste, faire rédiger son profil en lecture seule, modifier chaque champ, et l'enregistrer. Quel fournisseur et quel modèle répond à chaque rôle générique, c'est la matrice des rôles, avec les modes Eco, Balanced et Max quality qui remplissent toute la table en un appui : c'est un panneau de Réglages et non une vue d'Équipage, et Réglages et ses sections s'ouvrent depuis le menu du compte en bas de la barre latérale.
Règles
Trois choses souvent confondues. Un garde-fou est un script qui tourne avant l'outil et peut bloquer l'action net. Une règle de fonctionnement est une consigne pliée dans le prompt de chaque agent, sur les missions comme dans la console. Une compétence est une commande en markdown que vous pouvez lancer. Désactiver un garde-fou demande une confirmation, parce qu'il cesse d'appliquer. Sous les trois, les exécutions autorisées à écrire se voient refuser une liste rouge fixe qui comprend git push, git commit, rm et sudo, et restent enfermées dans leur propre worktree.
Automatisations
Les routines sont des agents et des commandes qui tournent à heure fixe : vous en activez une, vous réglez quotidien, hebdomadaire ou mensuel avec une heure, vous la lancez à la demande, et vous lisez le rapport de chaque exécution. Trois sont livrées avec le produit et toutes sont éteintes par défaut : contrôle de la mémoire, veille de sécurité et santé des serveurs. Une routine passe son tour quand l'exécution précédente tourne encore ou quand le budget du jour est dépensé. Elle peut regarder, rapporter et déposer du travail qu'une personne validera. Elle ne peut ni fusionner, ni déployer, ni promouvoir.
Dépenses
Les tokens et le prix de chaque exécution du projet, missions, tours de console et conseiller compris, par période, mission, modèle, fournisseur et rôle. Des dollars réels là où l'exécution les a rapportés, un prix tiré de votre catalogue et marqué comme estimation là où seuls les tokens existent, « pas de tarif » là où un modèle n'a pas de prix, et « abonnement » là où l'exécution tournait sur un abonnement qui ne remonte aucun montant. L'efficacité relie l'usage aux résultats : tokens par exécution réussie, coût par mission acceptée, et gaspillage, qui compte les exécutions ratées ou annulées mais pas une reprise qui a fini par réussir.
Sécurité
Les clés des fournisseurs sont en écriture seule : le cockpit confirme qu'une clé existe et ne rend jamais sa valeur. Les agents démarrent sans le jeton du cockpit, sans son répertoire et sans rien qui ressemble à un secret, et on ne peut pas les pointer vers le stock des missions ou le fichier des secrets. Le texte est nettoyé de ses clés, jetons, chaînes de connexion et adresses e-mail avant d'être écrit dans le moindre journal. Chaque tâche de code se construit dans son propre worktree, chaque entreprise tourne dans son propre conteneur, et le journal d'audit qui dit qui a validé quoi et quand est durable : effacer les missions ne l'efface pas.