Engineers lassen den ganzen Tag Claude Code und Codex laufen, und die Rechnung landet zum Monatsende als eine einzige undifferenzierte Zahl. Bromure Enterprise schlüsselt sie bis zum Repo, zur Datei, zum Engineer und zum Modell auf — sodass Sie sehen, wohin die Tokens tatsächlich gehen.
Das Problem
Sie zahlen pro Token und fliegen blind
KI-Coding ist jetzt ein echter Posten, und er wird pro Token abgerechnet. Aber die Rechnung gibt Ihnen eine Summe, keine Geschichte. Welche Teams treiben sie? In welchen Repositories ist das Arbeiten teuer? Kauft die Ausgabe Geschwindigkeit, oder frisst ein knorriges Legacy-Modul still ein Viertel des Budgets, jedes Mal, wenn es jemand öffnet?
Ohne Attribution sind die einzigen Hebel, die die Führung hat, stumpf: alle deckeln, Seats rationieren oder wegschauen und hoffen. Keiner davon ist eine Entscheidung — es sind Vermutungen. Und die Engineers, die den meisten Wert erzeugen, sehen auf der Rechnung identisch aus zu denen, die in einer teuren Ecke der Codebasis feststecken.
Bromures Antwort
Token-Ausgaben, attribuiert bis hinunter zur Datei
Weil jeder Agent in einer Bromure-VM läuft, wird jedes Token, das er ausgibt, an der Quelle beobachtet. Bromure Enterprise rollt das zu Ausgaben auf, die Sie tatsächlich lesen können: pro Repository, pro Datei innerhalb jedes Repositorys, pro Engineer, pro Team und pro Modell — live, während Sitzungen laufen, zentral aufbewahrt, abfragbar.
Jetzt sind die teuren Ecken Ihrer Codebasis sichtbar. Das Repo, dessen Bearbeitung das 5-fache des Medians kostet, die eine Datei, die jeder Agent tausendmal neu liest, das Premium-Modell, das Arbeit erledigt, die ein günstigeres könnte — sie hören auf, unsichtbar zu sein, und werden zu Dingen, die Sie beheben, budgetieren oder als Chargeback verrechnen können.
KI-KostentransparenzJetzt verfügbar
Ausgaben, die Sie sowohl Finance als auch Engineering vorlegen können
Verbinden Sie Bromure Agentic Coding mit Ihrem Enterprise-Server, und jede KI-gestützte Sitzung wird zu einem kostengenauen, attribuierbaren Datensatz. Finance sieht, wohin das Budget geht; Engineering sieht, wo das Arbeiten in der Codebasis teuer ist. Dieselben Daten, zwei Zielgruppen.
Eine Treemap Ihres Token-Budgets
Jedes Repository nach den darin ausgegebenen Tokens dimensioniert, bis hinunter zu einzelnen Dateien aufschlüsselbar. Die teuren Teile Ihrer Codebasis, gerankt, auf einen Blick.
Chargeback-fertige Rollups
Ausgaben gruppiert nach Team, Projekt und Kostenstelle — exportierbar in dieselben Finanzsysteme, die Sie bereits zur Allokation von Cloud- und SaaS-Kosten nutzen.
Budgets und Alerts
Setzen Sie eine monatliche Obergrenze pro Team oder Repo und werden Sie benachrichtigt, bevor sie gesprengt ist, nicht erst nach der Rechnung. Erkennen Sie eine durchgehende Schleife am Tag, an dem sie beginnt, nicht am Tag, an dem sie abrechnet.
Einblick in den Modell-Mix
Sehen Sie die Modellaufteilung über jedes Team und Repo hinweg und finden Sie die Arbeit, die auf einem Premium-Modell läuft, obwohl ein günstigeres genügen würde.
So funktioniert es
Kosten pro Repository
Ordnen Sie jedes Repo nach den Tokens, die fürs Arbeiten darin ausgegeben wurden. Wuchernde Monorepos und unzureichend dokumentiertes Legacy treten sofort hervor, statt sich in einer Monatssumme zu verstecken.
Kosten pro Datei
Bohren Sie in ein Repo hinein und sehen Sie, welche Dateien die Ausgaben treiben. Ein 12.000-Zeilen-Modul, das jeder Agent bei jeder Aufgabe neu liest, wird zu einem Budgetposten, auf den Sie zeigen und den Sie refaktorieren können.
Rollups pro Engineer & pro Team
Attribuieren Sie Ausgaben Teams für Chargeback und Budgetierung — ohne es in Überwachung von Einzelpersonen zu verwandeln. Allokieren Sie sie so, wie Sie jede andere geteilte Ressource allokieren.
Aufschlüsselung pro Modell
Sehen Sie, wo ein teures Modell günstige Arbeit erledigt. Passen Sie die Voreinstellung passend an und beobachten Sie, wie sich die Kurve biegt, ohne dass jemand langsamer wird.
In der Praxis
Von einer Monatszahl zu einer handlungsfähigen Karte
Jede Agenten-Sitzung, die Ihre Engineers ausführen, startet in einer Bromure-VM, die an ihre Identität, das Repository, in dem sie arbeiten, und das gewählte Modell gebunden ist. Während der Agent Dateien liest, Tools aufruft und Code generiert, zeichnet Bromure die Token-Ausgaben gegen genau diesen Kontext auf — kein SDK zu instrumentieren, kein Wrapper um das Modell, keine Änderung daran, wie Engineers arbeiten.
In der Enterprise-Konsole wird aus diesen Daten eine Treemap. Das Plattform-Team öffnet sie und sieht, dass ein Legacy-Billing-Service 28 % der Monatsausgaben ausmacht — und darin eine einzige 9.000-Zeilen-Datei, die jeder Agent bei jeder Aufgabe vollständig neu liest. Das ist kein KI-Problem; es ist ein Dokumentations- und Modularitätsproblem, das die Ausgaben gerade sichtbar gemacht haben.
Sie teilen die Datei auf, fügen ein fokussiertes README hinzu und beobachten, wie die Ausgaben für dieses Repo im nächsten Monat um zwei Drittel fallen. Der CFO bekommt eine Zahl, die er verteidigen kann; das Plattform-Team bekommt einen Backlog-Eintrag mit einem Dollar-Wert daran; die Engineers bekommen einen schnelleren Agenten. Niemand wurde rationiert.
Architektur & Integration
Wie es tatsächlich gebaut ist
Hier endet das Marketing. Was folgt, ist das technische Fundament, auf dem jedes Bromure-Deployment sitzt — ob Sie eine BYOD-Belegschaft schützen oder Klassifizierungsstufen innerhalb einer regulierten Behörde trennen.
Hypervisor-erzwungene Isolation
Jedes Profil läuft in einer eigenen, leichten Linux-VM auf Basis von Apples Virtualization.framework — mit eigenem Kernel, eigenem Dateisystem und eigenem Netzwerk-Stack, getrennt vom Host. Das Base-Image ist ein signierter, reproduzierbarer Alpine-Build, beim Sitzungsstart via APFS Copy-on-Write geklont (nahezu kein Plattenplatz-Overhead). Der Host kann den VM-Speicher nicht lesen; die VM kann weder Clipboard, Dateisystem noch Netzwerkadapter des Hosts lesen — es sei denn, die Profil-Richtlinie erlaubt es ausdrücklich.
Identität: SSO für Nutzer, mTLS für Geräte
Enrollment und Sitzungsstart sind durch zwei Faktoren abgesichert, die Ihre Organisation bereits betreibt. OIDC / SAML gegen Google Workspace, Okta, Microsoft Entra oder Authentik identifiziert den Nutzer. Ein pro Gerät ausgestelltes mTLS-Client-Zertifikat, aus Ihrer PKI und an die Installation gebunden, identifiziert die Maschine. Widerrufen Sie eines von beiden — und die nächste Sitzung startet nicht. Kein Agent zum Manipulieren, keine lokale Richtlinie, die sich umgehen lässt.
Profile-as-Code
Das Arbeitsprofil — erlaubte SaaS-Liste, Download-/Clipboard-/Screenshot-Haltung, VPN-Konfiguration, Tastaturlayout, Root-CAs, Netzwerk-Egress-Regeln — ist ein signiertes, deklaratives Artefakt. Versionieren Sie es in Git. Verteilen Sie es über Ihr MDM oder den Bromure-Config-Endpoint. Manipulierte Profile fallen durch die Signaturprüfung, und die Sitzung weigert sich zu starten. Was auf der Maschine des Nutzers läuft, ist bitgenau das, was Sie verfasst haben.
Netzwerk-Ebene pro Profil
Jedes Profil bringt seine eigene virtuelle NIC mit. Wählen Sie NAT über den Host, Bridge auf ein physisches Interface oder Tunneling via WireGuard, IKEv2 / IPsec oder Cloudflare WARP — alles in der VM terminiert, für den Host unsichtbar. Legen Sie DNS-Overrides, ausgehende Port-Whitelists, LAN-Isolation und einen HTTP-Proxy darüber. Segmentierung wird vom Hypervisor erzwungen — nicht von einem Aufkleber auf der Firewall.
Audit-Pipeline
Jede Anfrage — Zeitstempel, Verb, URL, Status, Nutzer, Profil, Gerät — wird außerhalb der VM in einem manipulationssicheren JSON-Lines-Stream erfasst und an den Log-Sink geliefert, den Sie bereits befüllen (SIEM, Data Lake, Retention-Archiv). Optional Headers-Only oder vollständige Sitzungsaufzeichnung für verdächtigen Traffic. Stabiles Schema, dokumentierte Felder, kein Vendor-Lock-in auf das Format.
Ephemer per Default, persistent nur auf Wunsch
Fenster schließen — die VM wird zerstört. Tokens, Cookies, Cache, Downloads und jede Malware, die während der Sitzung gelandet ist, gehen mit. Profile, die Zustand brauchen — ein Bookmarks-Set, eine gespeicherte Sitzung, eine eingeloggte SaaS — können optional eine LUKS-verschlüsselte persistente Disk aktivieren, mit einem Schlüssel im macOS-Keychain. Der Schlüssel verlässt das Gerät des Nutzers nie.
Häufige Fragen
Müssen Engineers irgendetwas instrumentieren?
+
Nein. Weil der Agent in der Bromure-VM läuft, werden die Token-Ausgaben an der Quelle beobachtet. Es gibt kein SDK hinzuzufügen, keinen Proxy pro Repo zu konfigurieren und keine Änderung daran, wie Engineers Claude Code, Codex oder Aider aufrufen.
Wie attribuieren Sie Ausgaben einer bestimmten Datei?
+
Bromure korreliert die Datei-Reads, -Edits und Tool-Aufrufe des Agenten innerhalb einer Sitzung mit den Tokens, die diese Sitzung verbraucht hat, und rollt es dann pro Pfad auf. Sie bekommen eine Pro-Datei-Ansicht innerhalb jedes Repositorys, nicht nur eine Pro-Repo-Summe.
Ist das Überwachung einzelner Engineers?
+
Es ist für Kostenallokation gebaut, nicht für Leistungskontrolle. Rollups stehen standardmäßig auf Team und Repo; Pro-Engineer-Daten existieren für Chargeback und sind zugriffskontrolliert. Das Ziel ist, teuren Code zu finden, nicht Menschen zu ranken.
Funktioniert es über Claude Code, Codex und andere hinweg?
+
Ja. Attribution geschieht auf der VM- und Sitzungsschicht, also ist sie modell- und agentenagnostisch — jeder Agent, den Sie in Bromure laufen lassen, wird auf dieselbe Weise kostenmäßig erfasst, und die Aufschlüsselung pro Modell lässt Sie sie direkt vergleichen.
Hören Sie auf zu raten, wohin die Tokens gehen.
Verwandeln Sie eine Monatsrechnung in eine Karte Ihrer Codebasis — pro Repo, pro Datei, pro Team, pro Modell.