The way to control AI costs is not to impose the same limits on everyone. It is to budget by task, required quality, and business value. The shift toward usage controls at Goldman Sachs, Cisco, and JPMorgan does not necessarily signal a retreat from adoption. It marks a necessary management shift: from enthusiasm about usage to accountability for results.
Enterprises should avoid two opposite reactions: handing out unlimited access without measurement, and making across-the-board cuts that block the people and processes creating value. In both cases, the problem is not the model. It is the absence of clear operating economics around it.
What is actually changing at large companies?
Goldman Sachs is expanding the range of AI tools available to employees while distinguishing between tasks that justify frontier models and those that other models can handle well. Cisco is moving from an experimental period of unlimited tokens to manager-controlled budgets. At JPMorgan, a monthly cap has reportedly been introduced for some engineers using Claude Code, alongside assessments of productivity, quality, and risk reduction.
These are different measures, but they share a common premise: AI access is moving from an experimental resource to an expense that needs to be managed.
- $2,000: the monthly cap for some JPMorgan engineers.
- 40%: Rippling's projected token spending as a share of its R&D personnel budget before adjustments.
- 10%–15%: Rippling's revised projection after adjustments.
These figures illustrate budgeting decisions, not benchmarks every enterprise should copy. Rippling's figures concern projected spending relative to its R&D personnel budget, not savings already realized. According to the company, limits and more efficient routing between models reduced that projection while token consumption remained close to its peak. That is the difference between using less and using more efficiently.
Tokens are not a productivity metric
An organization that rewards employees for consuming tokens is measuring activity, not success. An organization celebrating lower consumption may be making the opposite mistake: employees might simply have returned to doing work manually that the system previously handled for them.
The useful management metric is cost per outcome that meets quality requirements. Examples include the cost of properly resolving a support request, checking an invoice, or delivering a software change that passes testing and reaches production.
That cost includes more than the vendor bill:
- Licensing and model usage, without counting the same expense twice.
- Integration, maintenance, monitoring, and support.
- Employee time spent preparing inputs, reviewing outputs, and handling exceptions.
- Corrections and rework caused by incorrect outputs.
- Control and security costs, assessed separately from risk exposure.
Time savings do not automatically translate into financial savings. If an employee gains time but does not redirect it toward other useful work, the organization has gained potential capacity, not necessarily a better bottom line. Conversely, shortening a service queue or avoiding the need to expand a team can create value without eliminating an existing position.
The question is not how much AI an employee consumes, but how much work meeting requirements the organization gets for its total investment.
Budget by process, not just by employee
An individual cap is easy to implement, but it is an incomplete management tool. An employee developing a critical component may justify much higher spending than someone using a model to draft messages. Even within the same role, task complexity varies.
A better approach combines process-level budgets, role-based access, and a defined route for approving exceptions.
- Uniform employee cap: simple to administer and control, but risks blocking valuable work; suitable as an initial spending brake.
- Role-based allocation: aligns spending with team needs, but misses variation within a role; suitable for individual productivity tools.
- Process-level budget: connects spending to business outcomes, but requires performance measurement; suitable for agents and recurring workflows.
- Separate experimentation budget: supports learning, but risks funding experiments without a decision point; suitable for testing new use cases.
Separating experimentation from production is particularly important. During the learning phase, it is legitimate to spend money on attempts that go nowhere. Once a process is in routine operation, the organization needs to know what it costs, who owns it, and under what conditions it should scale.
Not every task needs the most capable model
Model routing does not mean automatically choosing the cheapest model. It means matching task complexity, information sensitivity, response time, and required quality to the right model.
An economical model might handle routine document classification, with complex cases passed to a more advanced model. But that decision should rest on tests using representative examples from the organization, not impressions from a demonstration. A cheap model that creates substantial rework can be the more expensive option.
Agents also need execution controls: limits on retries, mechanisms to stop loops, removal of unnecessary context, and prevention of duplicate tool calls. Sometimes the bill grows because the workflow is poorly designed, not because the model is expensive.
Watch out for false savings: A cheaper model call is not a saving if it increases review and correction time. Compare alternatives by cost per acceptable outcome, under the same quality and security requirements.
The comparison must cover the complete process. A system that classifies a support request cheaply but sends it to the wrong department may extend handling time and damage service. The price of the model call alone will not reveal that.
Keep humans in the loop without making them the bottleneck
AI can perform tasks involving interpretation and judgment, but its outputs are not guaranteed. Human oversight is therefore a critical design component. The question is where to place it.
If an employee must read and approve every output, the organization may have shifted effort from execution to review without materially changing throughput. The goal should be to oversee a larger volume of work through exception handling, sampling, and risk-adjusted controls.
Actions with financial or legal consequences, or involving sensitive permissions, may require human approval in advance. Routine, low-risk processes may support broader automation, provided there are mechanisms to stop execution and maintain records. A model's stated confidence is no substitute for testing actual performance.
How to start without stifling adoption
There is no need to wait for a perfect measurement system. Choose a process whose economics can be understood, assign accountability, and learn from the results.
- Map spending and ownership: Identify tools, accounts, workflows, and the person accountable for the business outcome.
- Define success: Set cost, quality, and handling-time metrics against the current baseline.
- Test alternatives: Compare models and execution paths on representative cases under identical security requirements.
- Introduce graduated controls: Establish budgets, alerts, stop mechanisms, and an approval route for justified exceptions.
- Scale based on results: Expand usage where value is demonstrated, and change or stop processes that miss their targets.
Responsibility is shared among finance, IT, and the business process owner. Finance assesses spending and value. IT owns infrastructure, permissions, and observability. The business unit defines what counts as a usable output. Without that connection, each department can improve its own metric while undermining the overall result.
Build capability, not just access
Enterprises need to advance on two tracks at once: employee AI literacy and internal capability to develop and manage agents. Good training improves task definition, context selection, and output review. Agent infrastructure embeds capabilities into existing workflows, sometimes requiring less behavioral change than a new individual productivity tool.
That infrastructure, however, requires management of permissions, versions, costs, tests, and incidents. IT must manage not just software, but also the operating boundaries and performance of enterprise agents.
This is a multidisciplinary professional field. Relevant education, research knowledge, and business and implementation experience are needed to distinguish an impressive automation from a stable operational process. Small and midsize businesses in particular should assess consultants on their ability to demonstrate measurement, controls, and experience running systems in production, not just successful demos.
The lesson from Goldman Sachs and Cisco is not that enterprises should use less AI. They should stop treating usage itself as an achievement. A good budget makes it possible to expand useful processes, fix wasteful ones, and stop what does not work. That is not a brake on adoption. It is what makes adoption a sustainable business investment.