Claude Code shows what agent work costs

The most useful signal in today's Claude sweep is not the newest version number. Claude Code 2.1.150 landed overnight, but Anthropic says it has no user-facing changes. The part teams can use is 2.1.149: /usage now shows what is driving limit usage, split by skills, subagents, plugins, and per-MCP-server cost. For a team starting to connect Claude to real systems, that is a useful reality check.

Source: Claude Code v2.1.150 release.
Source: Claude Code v2.1.149 release.

What changed in Claude Code: /usage shows what consumes limits

Claude Code is Anthropic's terminal tool for letting Claude read, edit, and run work in a codebase. In v2.1.149, the /usage command gets a more useful breakdown: skills, subagents, plugins, and per-MCP-server cost.

A skill is a reusable workflow or instruction in Claude Code. A subagent is a delegated agent that can handle a slice of work. A plugin is a package that can include skills, agents, hooks, or MCP servers. MCP, Model Context Protocol, is an open standard that lets AI apps like Claude connect to external tools, databases, and workflows.

That sounds small. In practice, it changes troubleshooting. If Claude Code suddenly hits limits, you do not have to guess whether the model, the codebase, or one long thread caused it. You can start asking: was it the plugin, the subagent, or that MCP connection to the ticketing system?

Source: Claude Code v2.1.149 release.
Source: What is the Model Context Protocol?.

Why this matters for practical teams

Picture a small consultancy or an internal product team using Claude Code with GitHub, Notion, and a monitoring tool through MCP. The agent can read issue text, look at error reports, and suggest a change. That is useful. But once several connectors and subagents are mixed together, the question changes fast: what does this workflow cost, and which part should we simplify?

The new /usage view gives teams a better starting point. Run one real, bounded job. Check usage before and after. If one MCP server or plugin drives much of the limit usage, you can shorten the instruction, restrict which tools the agent may use, or split the job into two smaller steps.

This is a good fit for Tool Forge: map which Claude connectors may be used, which tokens they need, what should be redacted from logs, and when a human must approve the next step.

MCP connectors need both access and a budget

Anthropic also added the enterprise setting allowAllClaudeAiMcps, which can load Claude.ai cloud MCP connectors alongside managed-mcp.json. That is an admin signal, not an everyday button for everyone. Still, it points in the same direction: Claude work is moving from a lone chat into a set of approved tools.

When you connect Claude to real systems, make the integration useful without making it loose. Put secrets in environment variables or a secret manager, use scoped tokens, grant least privilege, redact customer data from logs, and add approval gates before the agent writes, sends, or changes anything outside a test environment.

Source: Connect Claude Code to tools via MCP.
Source: Claude Code monitoring docs.

Try this prompt this week

Use this prompt in Claude Code when you have a real but bounded workflow, for example "read three issues and suggest a prioritized action list" or "review a small bug fix." Do not paste production secrets into chat. Let Claude propose the plan first, then run /usage before and after the job.

You are my Claude Code lead for usage and tool cost.

Workflow to test: [describe the job]
Allowed tools and connectors: [for example GitHub, Notion, Sentry, local repo]
Boundaries: [what Claude may not write, send, change, or read]
Human approver: [name/role]

Before doing the work:
1. Describe which skills, subagents, plugins, and MCP servers you expect to need.
2. Say which connectors should use environment variables, a secret manager, or scoped tokens.
3. Propose a minimal way to log metadata without logging customer text, prompts, secrets, or file contents.
4. Ask me to run /usage and paste only the relevant summary.

After the work:
1. Ask me to run /usage again.
2. Compare before/after and write a short usage ledger: what drove limit usage, what was worth it, what should be reduced next time?
3. List which steps require human review before anything is merged, sent, or published.
4. Suggest a simpler version of the workflow if usage was higher than expected.

Good looks like this:

• You know which part of the workflow drove usage.
• Nobody has to paste passwords, API keys, or customer data into chat.
• Logs contain metadata and decisions, not raw prompts or sensitive content.
• A human can approve or stop the work before it affects a customer, codebase, or budget.

What I would watch next

I would watch less for "which model is smartest?" and more for "which Claude workflows can we measure?" As usage, MCP connectors, plugins, and approval points become more visible, Claude gets easier to bring into a real workweek. Not as magic. As a tool with a budget, permissions, and accountability.