Engineers run Claude Code and Codex all day, and the bill lands at month-end as one undifferentiated number. Bromure Enterprise breaks it down to the repo, the file, the engineer, and the model — so you can see where the tokens actually go.
The problem
You're paying by the token and flying blind
AI coding is now a real line item, and it's billed by the token. But the invoice gives you a total, not a story. Which teams are driving it? Which repositories are expensive to work in? Is the spend buying velocity, or is one gnarly legacy module quietly eating a quarter of the budget every time someone opens it?
Without attribution, the only levers leadership has are blunt: cap everyone, ration seats, or look away and hope. None of those are decisions — they're guesses. And the engineers generating the most value look identical, on the invoice, to the ones stuck in an expensive corner of the codebase.
Bromure's answer
Token spend, attributed all the way down to the file
Because every agent runs inside a Bromure VM, every token it spends is observed at the source. Bromure Enterprise rolls that up into spend you can actually read: by repository, by the files inside each repository, by engineer, by team, and by model — live as sessions run, retained centrally, queryable.
Now the expensive corners of your codebase are visible. The repo that costs 5× the median to work in, the one file every agent re-reads a thousand times, the premium model doing work a cheaper one could — they stop being invisible and start being things you can fix, budget for, or charge back.
AI cost visibilityAvailable now
Spend you can put in front of finance and engineering both
Connect Bromure Agentic Coding to your enterprise server and every AI-assisted session becomes a costed, attributable record. Finance sees where the budget goes; engineering sees where the codebase is expensive to work in. Same data, two audiences.
A treemap of your token budget
Every repository sized by the tokens spent in it, drillable down to individual files. The expensive parts of your codebase, ranked, at a glance.
Chargeback-ready rollups
Spend grouped by team, project, and cost center — exportable to the same finance systems you already use to allocate cloud and SaaS cost.
Budgets and alerts
Set a monthly ceiling per team or repo and get told before it's blown, not after the invoice. Spot a runaway loop the day it starts, not the day it bills.
Model-mix insight
See the model split across every team and repo, and find the work running on a premium model when a cheaper one would do.
How it works
Cost by repository
Rank every repo by the tokens spent working in it. Sprawling monorepos and under-documented legacy surface immediately instead of hiding inside a monthly total.
Cost by file
Drill into a repo and see which files drive the spend. A 12,000-line module every agent re-reads on each task becomes a budget line you can point at and refactor.
Per-engineer & per-team rollups
Attribute spend to teams for chargeback and budgeting — without turning it into surveillance of individuals. Allocate it the way you allocate any other shared resource.
Per-model breakdown
See where an expensive model is doing cheap work. Right-size the default and watch the curve bend without slowing anyone down.
In practice
From one monthly number to an actionable map
Every agent session your engineers run launches inside a Bromure VM tied to their identity, the repository they're working in, and the model they chose. As the agent reads files, calls tools, and generates code, Bromure records the token spend against exactly that context — no SDK to instrument, no wrapper around the model, no change to how engineers work.
In the enterprise console, that data becomes a treemap. The platform team opens it and sees that one legacy billing service accounts for 28% of the month's spend — and inside it, a single 9,000-line file that every agent re-reads in full on every task. That's not an AI problem; it's a documentation-and-modularity problem the spend just made visible.
They split the file, add a focused README, and watch the next month's spend on that repo fall by two-thirds. The CFO gets a number they can defend; the platform team gets a backlog item with a dollar value attached; the engineers get a faster agent. Nobody got rationed.
Architecture & integration
How it's actually built
The marketing stops here. What follows is the technical substrate every Bromure deployment sits on — the same whether you're protecting a BYOD workforce or segregating classification levels inside a regulated agency.
Hypervisor-enforced isolation
Each profile runs in its own lightweight Linux VM on top of Apple's Virtualization.framework — a separate kernel, filesystem, and network stack from the host. The base image is a signed, reproducible Alpine build cloned via APFS copy-on-write at session launch (near-zero disk cost). The host cannot read VM memory; the VM cannot read the host's clipboard, filesystem, or network adapters unless profile policy explicitly allows it.
Identity: SSO for users, mTLS for devices
Enrollment and session launch are gated by two factors your organization already operates. OIDC / SAML against Google Workspace, Okta, Microsoft Entra, or Authentik identifies the user. A per-device mTLS client certificate, issued from your PKI and bound to the installation, identifies the machine. Revoke either and the next session fails to launch — no agent to tamper with, no local policy to edit around.
Profile-as-code
The work profile — allowed SaaS list, download / clipboard / screenshot posture, VPN configuration, keyboard layout, root CAs, network egress rules — is a signed declarative artifact. Version it in Git. Push it through your MDM or the Bromure config endpoint. Tampered profiles fail signature verification and the session refuses to start. What runs on the user's machine is bit-for-bit what you authored.
Per-profile network plane
Each profile carries its own virtual NIC. Choose NAT through the host, bridge to a physical interface, or tunnel via WireGuard, IKEv2 / IPsec, or Cloudflare WARP — all terminated inside the VM, invisible to the host. Layer on DNS overrides, outbound port whitelists, LAN isolation, and an HTTP proxy. Segmentation is enforced by the hypervisor, not by a sticker on the firewall.
Audit pipeline
Every request — timestamp, verb, URL, status, user, profile, device — is captured outside the VM in a tamper-resistant JSON Lines stream and delivered to the log sink you already feed (SIEM, data lake, retention archive). Optional headers-only or full-body session recording for suspicious traffic. Stable schema, documented fields, no vendor lock-in on the format.
Ephemeral by default, persistent by opt-in
Close the window, the VM is destroyed. Tokens, cookies, cache, downloads, and any malware that landed during the session go with it. Profiles that need state — a bookmarks set, a saved session, a logged-in SaaS — opt into a LUKS-encrypted persistent disk keyed to the macOS Keychain. The key never leaves the user's device.
Common questions
Do engineers have to instrument anything?
+
No. Because the agent runs inside the Bromure VM, token spend is observed at the source. There's no SDK to add, no proxy to configure per repo, and no change to how engineers invoke Claude Code, Codex, or Aider.
How do you attribute spend to a specific file?
+
Bromure correlates the agent's file reads, edits, and tool calls within a session against the tokens that session consumed, then rolls it up per path. You get a per-file view inside each repository, not just a per-repo total.
Is this surveillance of individual engineers?
+
It's built for cost allocation, not performance policing. Rollups default to team and repo; per-engineer data exists for chargeback and is access-controlled. The goal is to find expensive code, not to rank people.
Does it work across Claude Code, Codex, and others?
+
Yes. Attribution happens at the VM and session layer, so it's model- and agent-agnostic — any agent you run inside Bromure is costed the same way, and the per-model breakdown lets you compare them directly.
Stop guessing where the tokens go.
Turn one monthly invoice into a map of your codebase — by repo, by file, by team, by model.