Claude Code’s release notes for May 22 contain a sentence that is the entire story if you read it the right way. Version 2.1.149 makes /usage “show a per-category breakdown of what’s driving your limits usage — skills, subagents, plugins, and per-MCP-server cost.” On the surface, an improvement. The product got better. You can now see what is spending your money. The change is also a concession — Anthropic shipped Claude Code as a single number, and the sub-tool ecosystem outgrew that number, and the per-category breakdown is the receipt the seller hands you when the bundle stops looking like one purchase.
The pitch was always “AI is one bill”
For most of Claude Code’s life, /usage reported a percentage against a single 5-hour limit, and that was the model the tool was sold under. You bought Claude Code, you got a budget, the budget was simple to read because there was only one of it. The mental model on the buyer side matched: one tool, one limit, one number to watch.
That model worked when Claude Code was, in practice, one model behind one CLI. It does not work in May 2026. A single Claude Code session can now fire a skill (one of the dozen .claude/skills/*.md definitions you have wired in), call a subagent through the Agent tool, run inside a plugin, and consult several MCP servers — all of which charge against the same one number. When the rate of consumption inside a session has four independent sources, “where did the budget go” stops being answerable from a single percentage, and the only way to make it answerable is to itemize. So Anthropic itemized. Four lines now, where there used to be one.
What I saw the first time I ran it
The first thing I did after upgrading to 2.1.149 was run /usage on a session that had been chewing through my limit for a week, and the breakdown surprised me. I had been blaming the subagents — I had three of them spawned in parallel, doing things I had told myself were the expensive part — and the report named one of my MCP servers as the cost center. A documentation lookup MCP I had configured months earlier and forgotten about was running on every turn, consulting an internal index, charging me per call. The subagents were noise. The MCP was the bill. I had spent two weeks tuning the wrong thing because the old /usage could not tell me which sub-component was the offender, and the tuning was, in hindsight, an apology for missing data.
This is the part of the change that is straightforwardly good for users. The breakdown makes the cost question answerable for the first time. I now know which MCP server to disable, and I am going to disable it. The product is better than it was a week ago. That is true.
And the same change concedes something
The same change is also Anthropic conceding that the previous model — one number, one bill, one budget — did not survive contact with the sub-tool ecosystem they themselves built. The skills system, the subagent dispatch, the plugin layer, and the MCP-server protocol all came out of Anthropic. They are the reason a single session has four cost centers. The per-category breakdown is the company shipping the accounting that the sub-tool sprawl required, and shipping it now is a tell that the single-number version had stopped working.
There is a precedent in the Flash that got expensive, the prior week’s piece on the cost arc. That argument was about a per-call rate that rose under a name (“Flash”) that implied it dropped. This is the receipt-side counterpart. Once the per-call rate matters, you need to see which sub-call is doing the spending — and the per-category breakdown is the first place inside Claude Code that the sub-call layer is visible at all. Cost transparency at the sub-tool level is exactly the surface you need to make rational choices about which sub-tool to keep. It is also the surface that, in its absence, the prior year of Claude Code marketing was selling against — “Claude Code: one tool, one bill” stops being a pitch the moment the bill has four lines.
A trajectory, not a one-off
A piece I wrote earlier in the month, parallel agents and the per-developer meter, traced the first decomposition: from one bill across an organization to one bill per developer. The 2.1.149 change is the second decomposition: from one bill per developer to one bill per sub-tool inside that developer’s session. The trajectory is consistent — the bundle gets unbundled, one layer at a time, every time the previous layer’s accounting stops being precise enough to act on. I do not expect this to be the last layer. The next one is probably per-skill quotas (the breakdown will multiply into individual skill lines) or per-MCP-server quotas (each server gets its own ceiling). The receipt is going to grow more columns, and each new column will be an admission that the column before it could not hold the truth.
The line that matters
What I take from this week’s change is a small heuristic I am applying to other vendor announcements as a tell. Itemization is a concession. When a vendor adds it, they shipped the original product as a single number because that number was simpler to sell, and the underlying complexity has now outgrown the simplification. Itemization is good for users — it is precisely the thing you need to make rational choices — and an admission that the simpler product the vendor was selling has stopped describing the product as it actually exists. Both are true at once. The bill is itemized when the seller cannot keep selling it as one number. That is also the shape of what /simplify’s replacement by /code-review tells us, taken up in from fix to report.
What I changed about my own use: I price each sub-tool now, not the bundle, and I treat the breakdown’s growth as a forecast. The four columns it ships with today will become eight by year’s end. Plan for the receipt that is coming, not the one that arrived this week. The release that triggered all this is Claude Code’s /usage adds a per-category breakdown; the cluster’s predecessor argument in the same week, on the security side, is in AI found the bugs faster than we can patch them.
