You’re looking at an AI spend report, and one team or product accounts for most of the usage. Should you cap it, copy it across the company, or give it a larger budget? The distribution alone cannot answer that question.
The decision becomes clearer when you separate activity from value. You need to know what work consumed the AI, whether its output was accepted, what the full workflow cost, and whether more compute improved revenue, risk, quality, cycle time, or the customer experience.
Read concentration as a diagnostic, not a target
Enterprise AI use is developing a steep curve. In June, the top 10% of enterprise customers ranked by output tokens per active user generated 8.3 times as many output tokens per active user as customers in the middle decile. That ratio had been 2.6 in January. Token use grew 319% in the top group and 32% in the middle group over the period.
The companies were ranked again each month using the same token measure. This was not a fixed cohort pulling away in a clean longitudinal comparison. The direction of the gap is therefore more useful than treating 8.3 as a permanent benchmark for your company.
High concentration can come from three very different mechanisms:
- A small group is assigning agents valuable, ambitious work and checking the results well.
- Production workloads are serving customers at a scale that employee chat tools never will.
- Poorly designed agents are consuming tokens through stale context, weak task decomposition, repeated retries, or missing stop conditions.
These mechanisms can coexist. A blanket usage cap can damage a successful product workload. A company-wide adoption target can reproduce an expensive failure. Label the workload before you intervene.
The unit of work is also changing. Codex generated 64% of the combined enterprise output tokens from ChatGPT and Codex in June. In a separate small sample, the share of Codex users attempting tasks estimated to require a skilled person at least eight hours rose from 2.1% in December to 25.6% in May. Neither figure proves productivity. They show why agentic work can create far more output than a person could generate through ordinary back-and-forth chat.
Key takeaways
- Concentrated usage is a signal to investigate, not a KPI to maximize or flatten.
- Separate employee assistance, internal automation, customer-facing inference, and experimentation before calculating return.
- Pair every usage measure with an accepted outcome, quality result, human review, rework, cycle time, cost, and latency.
- Increase budgets and access only after a workflow has demonstrated value under explicit tests and stop rules.
Fix cost attribution before debating AI ROI
Spending is even more concentrated than activity. In July, the median company in the top 1% AI-spend-per-employee tier paid $7,400.50 per employee, an $88,806 annualized run rate. That was 11.4 times the median in the top 10% tier and 619 times the median AI-paying company.
It would be a mistake to read that as an unusually large employee-software bill. API use, GPU cloud, model serving, and inference represented 72.88% of measured July AI spending, while chat and coding-agent subscriptions represented 10.22%. Much of the largest spend may therefore support customer products or automated operations rather than employee seats.
Cost per employee is useful for employee enablement. It is a poor denominator for a customer-facing product whose demand is driven by transactions, conversations, generated assets, or active customers. Build a management ledger that assigns spend to its actual economic unit:
| Cost pool | Useful denominator | Outcome to inspect |
|---|---|---|
| Employee assistance | Active enabled employee or completed task | Accepted work, quality, and cycle-time change |
| Internal automated workflow | Completed workflow or processed item | Accepted result, exception rate, and full cost |
| Customer-facing AI | AI-enabled transaction, interaction, or customer | Product outcome, reliability, margin, and latency |
| Experimentation and shared enablement | Evaluated workflow or decision reached | Evidence produced and whether the idea advanced, changed, or stopped |
Attach every subscription, API project, cloud account, model-gateway call, and shared platform allocation to a cost pool, workload, environment, and accountable owner. Allocate shared inference by measured workload when possible. Do not distribute a production bill by headcount merely because headcount is easy to obtain.
This changes the executive conversation. Instead of asking why the AI bill is high, you can ask which workflow is expensive, what unit creates that expense, and whether the unit economics improve as the workflow scales.
Measure cost per accepted outcome, not tokens per user
Tokens measure computational activity. They help you explain capacity and cost, but they do not tell you whether the work was useful. A successful long-running agent and a failing agent trapped in a retry loop can consume similar volumes.
Define the accepted outcome before a workflow receives a larger budget. For a coding agent, that might be a change that passes the required tests and review. For support, it might be a policy-compliant resolution accepted without correction. For document processing, it might be a validated output that the downstream system accepts.
Record the following fields for each workflow:
- The unit of work and the exact condition that makes it accepted.
- The quality check, evaluation, or test result.
- The human review required before the result can be used.
- The correction, rerun, or downstream rework caused by the output.
- The full cycle time from request to usable result.
- The end-to-end cost, including model use, infrastructure, review, and rework.
- The latency experienced at the point where speed could affect the outcome.
Then derive operating measures that decision-makers can interpret:
- Acceptance rate: accepted outputs divided by all attempted outputs. Include failed and abandoned runs so retries cannot disappear from the denominator.
- Cost per accepted outcome: the full workflow cost divided by accepted outputs, not the model invoice divided by raw generations.
- Cycle-time change: the comparable baseline time minus the AI-assisted end-to-end time.
- Rework burden: correction and rerun effort attached to each accepted result.
- Latency performance: whether the workflow meets the speed requirement that was defined for its use case.
Usage rising while cost per accepted outcome falls can be healthy. Usage rising alongside falling acceptance, growing rework, or repeated failures is a reason to redesign or stop. This is why token consumption belongs in the diagnostic layer of the scorecard, not at the top of it.
Create an outcome contract before scaling
Give every material AI workflow a short operating contract: the accepted outcome, quality floor, review owner, cost boundary, latency target, permitted tools and data, and escalation condition. If the same failure repeats, require a different plan or a human decision before allowing more compute. A monthly budget alone will tell you that money was spent; a per-workflow boundary can prevent an individual run from consuming it without progress.
Turn power users into a repeatable operating system
Your highest-usage employees are useful places to investigate, but they are not automatically your best practitioners. Segment usage by accepted value before deciding whom to emulate:
- High usage and high accepted value: study the workflow and test whether it can be standardized.
- High usage and weak accepted value: inspect failed plans, retries, context quality, and review burden before granting more budget.
- Lower usage and high accepted value: look for access, tooling, or workflow friction that prevents safe expansion.
- Low usage and weak value: do not force adoption. Reassess whether the role has a suitable task, enough context, and a checkable outcome.
For the strongest workflows, reconstruct both successful and failed runs. Capture the task-selection logic, current company context, connected tools, decomposition of the work, acceptance checks, human review, retry behavior, and stop condition. The transferable asset is not the power user’s prompt. It is the whole system around the prompt.
A generic prompt class will not teach that system. People need end-to-end examples tied to their role and practice on work they can verify. When the workflow depends on live company context, tool integrations, evaluations, and permission boundaries, AI engineers or forward-deployed engineers may be needed to build and maintain the operating layer.
Use a controlled sequence for expansion:
- Prove the workflow on bounded, checkable work with a comparable baseline.
- Package the required context, tools, permissions, evaluations, and stop conditions.
- Observe acceptance, rework, failure behavior, cycle time, and full cost under normal use.
- Increase access and budget only when the evidence shows that additional consumption produces additional accepted value.
This approach allows useful concentration. A small number of proven workflows can consume a large share of the budget without becoming an organizational problem. The problem is concentration without attribution, controls, or evidence.
Route each workload by quality, cost, and latency
A static model standard will age quickly. One measured task comparison placed Grok 4.6 High at a score of 61 and $0.84 per task, level in score with GPT-5.6 Sol Max at $1.23. Fable 5 measured $3.14 and Opus 5 measured $2.34 in the same comparison. Grok did not lead every agent benchmark, so these figures are screening evidence rather than proof that it is best for your workload.
Speed creates another decision axis. GPT-5.6 Sol Ultrafast was previewed at up to 750 output tokens per second, or 14 times Standard processing, while running the same model. Access was limited and a price had not been published, so its business case could not be established from speed alone.
Build a routing policy around the workload rather than the vendor hierarchy. Each route should specify:
- The acceptance test and minimum quality the result must clear.
- The data, tools, regions, and permission boundaries the route is allowed to use.
- The maximum end-to-end cost per accepted result.
- The latency class: batch, interactive, or genuinely time-critical.
- The fallback model, retry policy, and condition that hands the work to a person.
Route work to the least expensive model and service tier that clears all of those constraints. A delay of several seconds may have no economic effect on batch analysis. It may change the result in trading, live support, incident response, or voice. Pay a latency premium only when you can connect that speed to revenue, risk, reliability, or user experience.
Before changing a production route, evaluate candidate models privately against your own tasks, context, tools, and acceptance tests. Keep the rollout reversible and measure it with the same outcome definition. Leaderboards can narrow the candidate set; they cannot replace workload evidence.
At your next AI investment review, bring a workload-level cost ledger and an outcome scorecard. Approve larger budgets where more consumption produces accepted value at known quality and cost. Route the rest more cheaply, redesign the workflow, or stop it. The goal is not equal adoption. It is deliberate concentration where the business result justifies it.
References
