- AWS CloudWatch now ingests OpenTelemetry metrics from coding agents (Claude Code, Codex, Copilot), effectively treating agent usage like metered infrastructure with budgets, alerts, and chargebacks.
- This shift from seat licensing to usage-based governance makes sense because token-burning agents behave like ongoing workloads that need quotas and cost controls.
- The default metric set (tokens, cost, sessions, lines of code, commits, edit acceptance) measures output volume and acceptance, not whether the resulting work is correct, maintainable, or valuable.
- These metrics were inherited from the IDE autocomplete era, so measures like acceptance rate and lines of code become misleading when the unit of work is an agent-driven multi-file session.
- Correlating agent adoption with commit/PR velocity will almost always look positive, risking a feedback loop where inflated throughput becomes a mandate and review quality quietly degrades.
On July 20 Amazon CloudWatch shipped Coding Agent Insights, which ingests OpenTelemetry metrics straight out of Claude Code, Codex, and GitHub Copilot and puts them next to your load balancers and your Lambda invocations. The coding agent just moved from the tools budget to the infrastructure budget.
That move is correct. An agent burning tokens continuously across an engineering org is a metered workload, and metered workloads get budgets, alerts, quotas, and per-department chargeback. Treating it like a seat license was always going to break.
The metric set is where it goes wrong. For Claude Code the measurable dimensions are tokens, cost, sessions, lines of code, commits, and edit acceptance. Every one of those describes how much the agent produced and how often you said yes. None of them describe whether the work was any good.
What actually shipped
The mechanics are unglamorous and that is the point. Coding agents already emit OpenTelemetry metrics. CloudWatch now has a purpose-built view that ingests them and correlates them with the operational data you already store.
There are two ways in. An individual or a small team can point the agent at CloudWatch's native OTLP endpoint with a bearer token, no collector, no sidecar, no change to how the agent runs. Organizations that want identity federation and centralized control route through the Claude apps gateway for AWS, which collects telemetry without any additional instrumentation on the developer's machine.
It is live in every commercial region except UAE, Bahrain, and Tel Aviv, and it bills at standard CloudWatch OpenTelemetry ingestion rates. There is no new SKU, which tells you how AWS thinks about this. It is not a product category, it is another metric stream.
AWS is explicit about the questions it expects you to answer with it: which teams would benefit from expanded access, where agents are accelerating delivery, and how to right-size token budgets across departments. You can set proactive token billing alerts, and you can correlate agent adoption with commit throughput and pull request velocity.
The schema nobody chose
AWS did not invent this metric list, which is the more interesting problem. Lines of code and edit acceptance are what the agents themselves already instrument, because that instrumentation was written when these tools were autocomplete in an editor. Acceptance rate was a genuinely useful number when the unit of work was a suggested line you either took or rejected.
The unit of work is now a session where an agent reads twelve files, writes four, runs the tests, and reverts its own change twice before landing. Acceptance rate on that is close to meaningless. Lines of code is worse than meaningless, because the agent's cheapest move is always to write more of them.
The schema got inherited rather than designed, and now it is about to become the org-wide standard. Not because anyone evaluated it, but because a default dashboard exists and defaults win. The team that would have argued about which metrics matter will instead open the console, see six charts, and start reporting them upward.
The correlation that becomes the mandate
The specific thing to watch is the suggested correlation between agent adoption and commit throughput and PR velocity.
That correlation will come back positive. It will come back positive in almost any org, almost regardless of whether the code is good, because agents mechanically raise commit counts and shrink the time between opening a PR and merging it. You are measuring a quantity the tool directly inflates and calling the result ROI.
Then the ROI slide gets built, and the slide becomes a mandate, and the mandate becomes a target. Once commit throughput is the target, the fastest way to hit it is to review agent output less carefully. The metric improves. The thing the metric was standing in for gets worse. There is nothing in the dashboard that would show you the difference.
The two jobs a human still has on an agent-built change are setting the bar, which happens before, and holding the bar, which happens after. The agent took the middle. Tokens, sessions, lines, commits, and acceptance all measure the middle. They measure the part you stopped doing.
What to put on the pipe instead
The pipe is good. Keep it. Change what rides on it, using the same OTel stream joined against git and CI data you already have.
Rework rate. What fraction of agent-authored lines get rewritten or reverted within fourteen days. This is a git blame and a date filter. It is the single best proxy for whether the output was actually right, and it moves in the opposite direction from lines of code, which is exactly why it is useful.
Cost per merged change, not cost per token. Tokens are an input. A session that burns two million tokens and lands a correct database migration is cheaper than four cheap sessions that got abandoned. I run long agent sessions daily and the spread in token cost between them is enormous and tells you almost nothing on its own. Divide spend by merged, surviving changes and the number starts meaning something.
Review depth on agent-authored diffs versus human-authored ones. Time to approve, and comments per hundred lines changed, split by authorship. If agent PRs are approved three times faster with a third of the comments, your bar dropped and you now have a number that says so. This is the leading indicator for the incident you have not had yet.
Escaped defects by authorship. Tag incidents with whether the originating change was agent-written. Most teams cannot answer this today and it is the only real accuracy signal you will get.
Abandon rate per session. How often a session ends with nothing merged. High abandon plus high token spend means the specification is bad, not the model.
The attribution decision you should make before the dashboard makes it for you
Identity and organizational attributes get supplied through environment variables, so per-developer attribution is available by default. Someone in your org will build a chart of tokens by engineer within a week of turning this on.
Decide deliberately whether you aggregate at team level or individual level, and write it down before the first chart ships. Per-developer token counts next to per-developer line counts is the exact combination that teaches people to game the tool, and the gaming is invisible in the metrics because the metrics are what is being gamed.
Where this leaves you
Turn it on. The visibility is real, the token budget alerts alone justify it, and running agents across an engineering org with no telemetry is not a defensible position in the second half of 2026.
Then treat the default dashboard as a starting schema rather than an answer. Add rework rate and review depth on agent diffs in the first month, because those are the two that will actually change a decision, and neither ships in the box.
The pattern is familiar by now. The kill switch moved into the runtime, the sandbox moved into the operating system, spend authority moved into the wallet. Measurement is moving into the runtime too, on the same OpenTelemetry pipe as everything else. The plumbing keeps arriving correct and the defaults keep arriving from the previous era.
Use CloudWatch’s new visibility to put real guardrails around spend—budgets, alerts, and chargeback—but don’t let the default dashboard become your definition of success. Treat lines of code, acceptance rate, and raw throughput as cost and activity signals, then pair them with quality checks you trust (test pass rates, incident/regression trends, review depth, rollback frequency) before you declare ROI. Most importantly, watch for incentives drifting toward “more commits faster” and counterbalance them with metrics and processes that reward correctness and maintainability.