Les ingénieurs font tourner Claude Code et Codex toute la journée, et la facture tombe en fin de mois comme un seul chiffre indifférencié. Bromure Enterprise la ventile par repo, par fichier, par ingénieur et par modèle — pour que vous voyiez où vont réellement les tokens.
Le problème
Vous payez au token et vous naviguez à l'aveugle
Le coding IA est désormais un vrai poste de dépense, et il se facture au token. Mais la facture vous donne un total, pas une histoire. Quelles équipes l'alimentent ? Dans quels dépôts est-il coûteux de travailler ? La dépense achète-t-elle de la vélocité, ou un seul module legacy épineux dévore-t-il discrètement un quart du budget chaque fois que quelqu'un l'ouvre ?
Sans attribution, les seuls leviers de la direction sont grossiers : plafonner tout le monde, rationner les sièges, ou détourner le regard en espérant. Aucun de ceux-là n'est une décision — ce sont des suppositions. Et les ingénieurs qui génèrent le plus de valeur sont identiques, sur la facture, à ceux coincés dans un recoin coûteux du code.
La réponse de Bromure
La dépense de tokens, attribuée jusqu'au fichier
Parce que chaque agent s'exécute dans une VM Bromure, chaque token qu'il dépense est observé à la source. Bromure Enterprise consolide cela en une dépense que vous pouvez réellement lire : par dépôt, par les fichiers à l'intérieur de chaque dépôt, par ingénieur, par équipe et par modèle — en direct pendant les sessions, conservée de manière centralisée, requêtable.
Désormais, les recoins coûteux de votre code sont visibles. Le repo qui coûte 5× la médiane à travailler, le fichier unique que chaque agent relit un millier de fois, le modèle premium faisant un travail qu'un moins cher pourrait faire — ils cessent d'être invisibles et deviennent des choses que vous pouvez corriger, budgéter ou refacturer.
Visibilité sur les coûts IADisponible maintenant
Une dépense que vous pouvez présenter à la fois à la finance et à l'ingénierie
Connectez Bromure Agentic Coding à votre serveur d'entreprise et chaque session assistée par IA devient un enregistrement chiffré et attribuable. La finance voit où va le budget ; l'ingénierie voit où le code est coûteux à travailler. Mêmes données, deux publics.
Une treemap de votre budget de tokens
Chaque dépôt dimensionné selon les tokens qui y sont dépensés, explorable jusqu'aux fichiers individuels. Les parties coûteuses de votre code, classées, d'un coup d'œil.
Des consolidations prêtes pour la refacturation
Dépense regroupée par équipe, projet et centre de coûts — exportable vers les mêmes systèmes financiers que vous utilisez déjà pour allouer les coûts cloud et SaaS.
Budgets et alertes
Fixez un plafond mensuel par équipe ou par repo et soyez prévenu avant qu'il ne soit dépassé, pas après la facture. Repérez une boucle qui s'emballe le jour où elle commence, pas le jour où elle est facturée.
Vision sur le mix de modèles
Voyez la répartition des modèles sur chaque équipe et chaque repo, et trouvez le travail qui tourne sur un modèle premium quand un moins cher suffirait.
Comment ça marche
Coût par dépôt
Classez chaque repo par les tokens dépensés à y travailler. Les monorepos tentaculaires et le legacy sous-documenté ressortent immédiatement au lieu de se cacher dans un total mensuel.
Coût par fichier
Plongez dans un repo et voyez quels fichiers tirent la dépense. Un module de 12 000 lignes que chaque agent relit à chaque tâche devient une ligne de budget que vous pouvez désigner et refactorer.
Consolidations par ingénieur et par équipe
Attribuez la dépense aux équipes pour la refacturation et le budget — sans en faire une surveillance des individus. Allouez-la comme vous allouez n'importe quelle autre ressource partagée.
Ventilation par modèle
Voyez où un modèle coûteux fait un travail bon marché. Calibrez le modèle par défaut et regardez la courbe s'infléchir sans ralentir personne.
En pratique
D'un seul chiffre mensuel à une carte exploitable
Chaque session d'agent que vos ingénieurs lancent démarre dans une VM Bromure liée à leur identité, au dépôt sur lequel ils travaillent et au modèle qu'ils ont choisi. À mesure que l'agent lit des fichiers, appelle des outils et génère du code, Bromure enregistre la dépense de tokens contre exactement ce contexte — aucun SDK à instrumenter, aucun wrapper autour du modèle, aucun changement dans la façon dont les ingénieurs travaillent.
Dans la console d'entreprise, ces données deviennent une treemap. L'équipe plateforme l'ouvre et constate qu'un seul service de facturation legacy représente 28 % de la dépense du mois — et à l'intérieur, un unique fichier de 9 000 lignes que chaque agent relit en entier à chaque tâche. Ce n'est pas un problème d'IA ; c'est un problème de documentation et de modularité que la dépense vient de rendre visible.
Ils scindent le fichier, ajoutent un README ciblé, et regardent la dépense du mois suivant sur ce repo chuter des deux tiers. Le CFO obtient un chiffre qu'il peut défendre ; l'équipe plateforme obtient un élément de backlog avec une valeur en euros attachée ; les ingénieurs obtiennent un agent plus rapide. Personne n'a été rationné.
Architecture & intégration
Comment c'est réellement construit
Fin du marketing. Ce qui suit, c'est le socle technique sur lequel chaque déploiement de Bromure repose — le même que vous protégiez des effectifs BYOD ou que vous cloisonniez des niveaux de classification dans une agence régulée.
Isolation appliquée par l'hyperviseur
Chaque profil s'exécute dans sa propre VM Linux légère au-dessus du Virtualization.framework d'Apple — un noyau, un système de fichiers et une pile réseau distincts de l'hôte. L'image de base est un build Alpine signé et reproductible, cloné via APFS copy-on-write au lancement de la session (coût disque quasi nul). L'hôte ne peut pas lire la mémoire de la VM ; la VM ne peut pas lire le presse-papiers, le système de fichiers ou les adaptateurs réseau de l'hôte, sauf si la politique du profil l'autorise explicitement.
Identité : SSO pour les utilisateurs, mTLS pour les appareils
L'enrôlement et le lancement de session sont conditionnés à deux facteurs que votre organisation exploite déjà. OIDC / SAML contre Google Workspace, Okta, Microsoft Entra ou Authentik identifie l'utilisateur. Un certificat client mTLS par appareil, émis par votre PKI et lié à l'installation, identifie la machine. Révoquez l'un ou l'autre et la prochaine session refuse de se lancer — aucun agent à trafiquer, aucune politique locale à contourner.
Profile-as-code
Le profil de travail — liste de SaaS autorisés, posture téléchargement / presse-papiers / capture d'écran, configuration VPN, disposition clavier, CA racines, règles de sortie réseau — est un artefact déclaratif signé. Versionnez-le dans Git. Poussez-le via votre MDM ou l'endpoint de configuration Bromure. Les profils altérés échouent à la vérification de signature et la session refuse de démarrer. Ce qui tourne sur la machine de l'utilisateur est bit pour bit ce que vous avez écrit.
Plan réseau par profil
Chaque profil porte son propre NIC virtuel. Choisissez le NAT à travers l'hôte, le pont vers une interface physique, ou le tunnel via WireGuard, IKEv2 / IPsec ou Cloudflare WARP — tous terminés à l'intérieur de la VM, invisibles pour l'hôte. Ajoutez par-dessus des overrides DNS, des listes blanches de ports sortants, de l'isolation LAN et un proxy HTTP. La segmentation est appliquée par l'hyperviseur, pas par un autocollant sur le pare-feu.
Pipeline d'audit
Chaque requête — horodatage, verbe, URL, statut, utilisateur, profil, appareil — est capturée hors de la VM dans un flux JSON Lines résistant à l'altération et livrée au puits de logs que vous alimentez déjà (SIEM, data lake, archive de rétention). En option, enregistrement de session en en-têtes seuls ou corps complet pour le trafic suspect. Schéma stable, champs documentés, pas de vendor lock-in sur le format.
Éphémère par défaut, persistant sur opt-in
Fermez la fenêtre, la VM est détruite. Jetons, cookies, cache, téléchargements et tout malware qui a atterri pendant la session s'en vont avec. Les profils qui ont besoin d'état — un ensemble de favoris, une session sauvée, un SaaS connecté — optent pour un disque persistant chiffré LUKS, scellé sur le Keychain de macOS. La clé ne quitte jamais l'appareil de l'utilisateur.
Questions fréquentes
Les ingénieurs doivent-ils instrumenter quoi que ce soit ?
+
Non. Parce que l'agent s'exécute dans la VM Bromure, la dépense de tokens est observée à la source. Aucun SDK à ajouter, aucun proxy à configurer par repo, et aucun changement dans la façon dont les ingénieurs invoquent Claude Code, Codex ou Aider.
Comment attribuez-vous la dépense à un fichier précis ?
+
Bromure corrèle les lectures de fichiers, les éditions et les appels d'outils de l'agent au sein d'une session avec les tokens que cette session a consommés, puis consolide cela par chemin. Vous obtenez une vue par fichier dans chaque dépôt, pas seulement un total par repo.
Est-ce une surveillance des ingénieurs à titre individuel ?
+
C'est conçu pour l'allocation des coûts, pas pour la police de la performance. Les consolidations sont par défaut par équipe et par repo ; les données par ingénieur existent pour la refacturation et sont à accès contrôlé. Le but est de trouver le code coûteux, pas de classer les personnes.
Cela fonctionne-t-il à travers Claude Code, Codex et les autres ?
+
Oui. L'attribution se fait à la couche VM et session, donc elle est agnostique au modèle et à l'agent — n'importe quel agent que vous faites tourner dans Bromure est chiffré de la même façon, et la ventilation par modèle vous permet de les comparer directement.
Arrêtez de deviner où vont les tokens.
Transformez une facture mensuelle en une carte de votre code — par repo, par fichier, par équipe, par modèle.