OpenAI added ChatGPT Enterprise usage analytics, Cost API access, workspace limits, group controls, and user overrides for AI spend governance.
Why spend governance matters for enterprise AI
As AI usage moves from small pilots to organization-wide deployment, the cost of running large language models stops being a rounding error and starts showing up as a real line item. Without visibility into who is using what, finance and platform teams are left guessing, and engineering teams have no reliable way to tie consumption back to a team, project, or budget. The new usage analytics and spend controls for ChatGPT Enterprise are aimed at closing that gap, giving administrators the data and the levers they need to manage AI as a governed resource rather than an open tap.
Usage analytics and the Cost API
The usage analytics surface how a workspace is actually consuming AI: which groups are active, how usage trends over time, and where the heaviest demand sits. That reporting is the foundation for any cost conversation, because you can only manage what you can measure. Rather than pulling numbers by hand, teams can see consumption in one place and reason about it directly.
For organizations that want this data in their own systems, Cost API access exposes the same underlying information programmatically. That lets platform teams pull spend and usage into existing dashboards, data warehouses, or FinOps tooling, join it with other cost sources, and build the internal chargeback or showback reports their finance partners expect. Automating the pull also means alerts and anomaly detection can run continuously instead of depending on someone remembering to check a console.
Controls: workspace limits, groups, and overrides
Visibility alone does not prevent overspending. The control layer adds enforcement on top of the reporting. Administrators can set limits at the workspace level to cap overall consumption, define group controls so different teams operate within their own boundaries, and apply user overrides when a specific person needs more headroom than their group's default allows.
Together these give a tiered model that mirrors how most organizations already think about budgets and permissions:
- Workspace limits set the outer boundary for the whole organization, acting as a backstop against runaway aggregate spend.
- Group controls let you allocate capacity by team or function, so a heavy-usage engineering group and a lighter-usage support group can be governed on different terms.
- User overrides handle the exceptions, granting or restricting individuals without forcing you to reshape an entire group's policy.
Putting it to work
A practical way to adopt these tools is to start in a reporting-only posture. Turn on the analytics, pull a few weeks of data through the Cost API, and establish a baseline of normal usage before you enforce anything. That baseline tells you where real limits should sit and prevents you from setting caps so tight that they block legitimate work.
Once you understand the patterns, layer the controls in from the outside in: set a workspace ceiling first, then distribute allowances to groups, and reserve user overrides for genuine exceptions rather than routine adjustments. Revisit the limits on a regular cadence, because usage grows as teams find new applications, and a cap that made sense at launch will quietly turn into a bottleneck. Treated this way, spend governance becomes a steady operational discipline instead of a scramble triggered by a surprising invoice.