Anthropic AI Spend Reports: Measure Enterprise ROI
Anthropic's new reports show what Claude usage costs, produces and where workflows stall—helping businesses manage AI spend without mistaking activity for ROI.
Anthropic's New AI Reports Put Enterprise Spending Under the Microscope
AI budgets are growing faster than many companies can explain what they're actually buying. A team can point to evidence like developers using Claude Code or token usage rising - but that doesn't automatically tell you whether the work is faster, better, or cheaper overall. That mismatch between usage and business value is starting to land in management's lap, not just engineering's.
Anthropic's new reporting tools are meant to make that gap easier to see. They're built to give managers visibility into team activity, costs, work produced, and where workflows get stuck - along with suggestions for improving outcomes. Anthropic is also adding pooled budgets to help teams manage token spending. The push comes as enterprise buyers ask for clearer proof that AI tools justify their expanding costs.
This article looks at what the reports provide, why usage metrics don't equal ROI, and how companies can evaluate AI spending without confusing adoption with impact. It also covers why real-world workflows can make switching tools harder than model comparisons suggest.
What do Anthropic's AI spending reports show?
Anthropic's reporting suite is designed to help enterprise managers understand how teams use its models over a defined date range. Instead of stopping at a bill or a token count, the reports combine internal analytics with employee surveys. The goal is to show what a team did, what it produced, what it cost, and where workflows hit friction.
That distinction matters. A usage dashboard can tell a finance team that a department used more tokens this month. It can't, on its own, explain whether that spend helped ship a feature, reduced time on routine coding, or created extra review work. Anthropic's reports try to connect the dots by pairing workstreams and task outcomes with common points of difficulty.
The tools also include recommendations for improving results. Anthropic frames this as a way to help customers get more value from what they're already doing, not just drive higher usage. The company says the reporting data won't be used for model training by default. That's important for organizations thinking about how employee activity and business data are handled - but each company should still review the product's terms and its own data policies before rolling anything out.
Anthropic is also introducing pooled group budgets. The idea is to let teams manage token spending collectively instead of treating every employee or project as an isolated cost center. Pooled budgets can make administration simpler, but they don't automatically make spending more efficient. Someone still has to own the limit, monitor usage, and define how exceptions work.
A step from usage analytics toward workflow analysis
The core product idea is to report on the work around model usage - not just the usage itself. For a software team, that might mean looking at what kinds of tasks people attempt, what results they produce, and where they have to intervene or redo work. The aim is to make workflow quality visible enough to improve it.
There's a real limit, though: a report can help you inspect activity, but it can't prove that the AI caused a specific business outcome. If a team ships faster during a period of high AI usage, other factors could be in play - like fewer interruptions, a smaller release, or more experienced staff. Managers still need to validate the story using evidence from the work itself.
Why is AI spending hard to connect to business value?
The basic accounting is simple: models consume tokens, and tokens cost money. The harder part is the business case. A token is an input, not an outcome. Higher usage might mean the tool is helping with more work - but it could also mean people are experimenting, repeating prompts, or spending time fixing weak outputs.
That's why AI adoption metrics can mislead. Active users, requests, or token counts can tell you a product is being used. They don't tell you whether it improves delivery speed, reduces operating costs, raises quality, or frees up time for higher-value work. To get there, you have to connect usage to specific tasks and compare results against a credible baseline.
Spending trends also make the measurement problem more urgent. Jellyfish, a software development analytics company, reported that agentic coding tools were behind nearly a third of proposed code changes submitted for review among 276,000 customers in its analysis. It also found spending on these tools grew tenfold since the beginning of the year and reached about 2% of total engineering costs. Those numbers describe an expense that's growing quickly - not proof that the tools are generating a matching return.
As Jellyfish chief scientist Nicholas Arcolano told TechCrunch, even a 2% cost share can matter when it's grown tenfold and wasn't planned for by finance teams. The takeaway for CFOs is pretty practical: a small line item can become material if its growth isn't controlled, the benefits aren't clear, or it spreads across many teams.
Why the Fortune 500 picture can differ from startup usage
Venture-backed companies often tolerate high experimentation costs so they can move quickly or iterate around new tools. Large enterprises tend to have tighter constraints: procurement, security reviews, existing systems, compliance requirements, and budgets that need predictable justification. The same tool can look promising in one context and much harder to scale in another.
It's also easy for broad claims about "AI productivity" to hide differences between tasks. Writing a first draft of code isn't the same as delivering a reliable feature. A useful evaluation includes review, testing, rework, maintenance, and the cost of human oversight. If AI reduces time to generate a draft but increases time required to verify it, measuring generation alone can give you a distorted picture.
Anthropic's reports target a real need by making costs and workflow friction easier to inspect. But they should be treated as a starting point for analysis, not a ready-made ROI formula. The vendor has an obvious incentive to make the product work well; customers still have to test whether any gains hold up in their own environment.
How should companies measure AI ROI in practice?
Start with the work, not the model. Pick a repeatable task where the current process and cost are already understood. Define what a "good" result means before you roll out an AI-assisted workflow. In software development, that might include time from task assignment to reviewed code, defect rates, rework, and how much developer time goes into implementation and review.
Then compare an AI-assisted workflow against the existing approach. You don't need a massive research program, but you do need to account for the full task. If the AI drafts code in minutes, you still have to include time spent prompting, checking, correcting, testing, and integrating it. Otherwise, you're only measuring the fastest step and ignoring the rest.
A practical scorecard can include:
- Direct cost: model usage, subscriptions, and any additional infrastructure or support.
- Labour time: time saved or added across the full task, including review and rework.
- Quality: defects, accuracy, customer impact, or other outcomes relevant to the task.
- Throughput: completed work that meets the team's acceptance criteria, not raw output volume.
- Adoption and friction: where employees use the tool, where they avoid it, and where they have to change workflows.
- Operational risk: data handling, access controls, and the consequences of incorrect output.
Use a baseline that reflects normal work. A pilot focused on unusually simple tasks can make results look better than they will at scale. And comparing a highly motivated pilot team against a busy team using the old process may tell you more about the teams than the tool. When possible, compare similar work under similar conditions - and document why results differ.
A decision rule for pilots and budgets
A pilot should come with a decision attached to it. Before you start, specify what result justifies expansion, what outcome triggers changes, and what result ends the test. This helps avoid the common trap of extending a pilot because people like the tool, even if the business case still isn't clear.
Pooled budgets can help keep spend from running away during this process. Name a budget owner, define which teams can draw from it, and review usage against work outcomes on a regular schedule. Avoid setting the budget so tight that it blocks legitimate experimentation - but don't pretend an uncapped pool removes the need for accountability. The right level depends on the cost of experimenting and the value of learning.
Finally, keep the ROI math honest. ROI isn't just "hours saved" multiplied by an hourly rate, especially if those hours don't translate into capacity, lower costs, or better output. If a team saves time but can't put it to productive use, that may still improve employee experience - but it's a different benefit and should be described that way.
Key takeaways for AI spending reviews:
- Measure completed work and quality, not token volume alone.
- Include review, testing, and rework in the cost of an AI-assisted task.
- Set pilot success and stop criteria before the test begins.
- Treat vendor-generated recommendations as hypotheses to validate.
- Expand only when the workflow works reliably beyond the pilot team.
Why can enterprise customers be difficult to win away?
Model quality matters, but it's only one part of an enterprise tool decision. Once a company has standardized a workflow, trained employees, and integrated a product into daily work, replacing it usually means more than swapping an API or comparing two model benchmarks. Teams build operational knowledge about how a tool behaves and how to get reliable results from it.
Jellyfish's AI product lead, Nikolas Albarran, described a slow rise in the visibility of OpenAI's Codex inside the company's data, even as competition discussions heated up after OpenAI's Astra model. He argued that Anthropic benefited from strong enterprise execution and the fact that its tools worked well for customers. In his view, organizations had already put effort into standardizing workflows - so a competitor needed a real reason to justify switching.
That doesn't mean model competition has stopped. It's more a reminder that benchmark performance and online discussion don't capture the full cost of changing a production workflow. Different tools come with different behaviors and configuration requirements. A "small" difference can turn into a big operational burden when it affects many developers, teams, or projects.
Reporting as a lighter form of customer support
AI labs have invested in forward-deployed engineering teams - specialists who work directly with customer organizations to help them implement products. Anthropic's reporting tools can be seen as a lighter, more scalable version of that support. They give customers analysis and recommendations without requiring the same level of hands-on assistance for every team.
That can help customers identify where a workflow is failing and get more out of a tool they've already adopted. It can also reinforce the relationship. When a vendor helps a team establish habits, budgets, and internal evidence for a tool, it becomes part of how the company operates - not just something selected during a procurement exercise.
There's a trade-off, though. Better support can be genuinely valuable, but it can also increase dependence on a vendor. If a company's processes, measurement, and training are tightly tied to one provider, switching costs rise. That's not automatically a reason to avoid the product - it's a reason to make the dependency visible and to keep a credible exit plan.
For buyers, the practical response is to document workflows, keep evaluation criteria portable, and understand what data and configurations would need to move if the provider changed. Reassess alternatives based on operational fit, not only model quality. A competitor has to be good enough to cover migration, retraining, and disruption - not just look strong in a demo.
Conclusion
Anthropic's new reports address a real enterprise AI problem: companies can see usage and bills, but they often can't explain what the spending produced or where workflows are breaking down. By connecting costs to workstreams, outcomes, and friction, the tools could help teams make better decisions about how they use Claude.
These reports aren't a substitute for a company's own evaluation. Usage isn't the same thing as value, and recommendations aren't proof. Measure the full workflow, set explicit pilot criteria, and expand only when the results hold up in real operating conditions. The goal isn't simply to spend less on AI. It's to know which spending earns its place.