When coding-agent usage drops after the meter, read it as a cost signal, not an adoption failure

A CTO I was talking with this week pulled up her coding-agent dashboard and went quiet for a second. The line that had climbed all spring, the one she had put in three board decks, had bent downward in the two weeks since June 1. Same team. Same repositories. Fewer agent sessions per engineer.

Her first instinct was the one most of us would have: the tool regressed, or the team got bored, or the rollout was losing steam. So she did the thing that felt responsible. She drafted a note reminding everyone that the harness was approved, encouraged, and waiting for them.

Here is what I told her before she sent it. June 1 was not a normal week in the coding-agent world. It was the week the meter turned on. And a usage line that bends right after the meter turns on is almost never the story the dashboard implies.

What the spring coding-agent rollout actually measured

Most of the harness rollouts I have watched over the past year ran the same play. Pick a tool. Make it easy to get. Put a leaderboard somewhere visible. Watch adoption climb. By spring, the climb was real and the numbers looked great in a review.

The latest engineering-management survey backs up how good those numbers felt. Jellyfish published a piece on June 11 on engineering leaders moving from AI adoption to AI accountability, and it reports that 64 percent of engineering professionals believe they are getting at least a 25 percent jump in developer velocity. High-adoption organizations, in the same data, merge roughly twice as many pull requests as low-adoption ones while holding code quality. Productivity is a top management priority for 84 percent of them. The enthusiasm is not imaginary.

But here is the quiet problem with the spring scoreboard. Adoption percentage measures how many engineers have the tool open. It is a license-utilization number wearing a productivity costume. It counts the badge readers at the door clicking. It says nothing about whether the work behind the door got better, and nothing at all about what each click now costs.

For a year, that gap did not matter much, because the tool was effectively free at the point of use. Flat seats meant an engineer could let an agent churn for an hour and nobody felt it. Wide adoption was free optionality. So we measured the easy thing and moved on.

Then the easy thing stopped being free.

When the meter went live, the usage behavior changed

The pricing reset that landed on June 1 was not a tweak. A pricing breakdown from Digital Applied on June 12 put it plainly: AI coding tool pricing changed more in June 2026 than in the prior year combined, with Cursor, GitHub Copilot, and the rebranded Devin Desktop all restructuring within days of each other.

The mechanics are what changed behavior. GitHub Copilot Pro now carries a 1,500-credit monthly cap, 1,000 base plus 500 flex credits that run out in September. A single heavy session on a frontier model can burn around 800 of those credits. That is roughly 80 percent of the monthly base from one task. Cursor split its seats into usage pools. Power users, by Digital Applied’s read, are reporting 10x to 100x spikes on the heaviest workflows.

Sit with what that does to an engineer’s head. We spent a year telling people the agent was free, then handed them a taxi meter and acted a little surprised when they started watching the fare. When every run shows a number, and that number eats a visible slice of a monthly allowance, the rational move for a careful engineer is to ration. Save the agent for the sure thing. Skip the exploratory run that might not pan out. The behavior that drops first is the speculative, iterative use, which is precisely the use that produced the gains in the first place.

This is not a brand-new human reaction. Back in The Pragmatic Engineer’s April survey of more than 900 engineers and leaders, around 30 percent already said they hit monthly usage limits on paid AI coding tools, before most of these meters went live. The meter did not invent rationing. It just made it the default posture for a much larger group, overnight.

The coding-agent cost number the adoption dashboard cannot see

Here is the part that should reframe the whole conversation. The thing dragging on adoption right now is not trust, not quality, not training. It is the bill.

Cost is the single most-cited obstacle now, ahead of security, ahead of code quality, ahead of getting people to learn the tool. And the same survey found that only 46 percent of organizations actively track AI-specific metrics like adoption rates, acceptance rates, and model usage. Read those two findings together and the trap becomes obvious. The expense everyone is worried about is rising on a system that more than half of orgs cannot actually see inside.

The cost side, when teams do look, can be startling. Faros put out a piece on token spend on June 10 with one detail that stuck with me: a CTO reviewing his data found that one of his most productive engineers was generating 47,000 dollars a month in token costs. Not the team. One engineer. At the enterprise level, Faros notes that 10 billion tokens a month already translates to tens of thousands of dollars, and 100 billion can run from 500,000 dollars to a million.

So picture the CTO from the start of this piece, looking at a usage line that dipped. Her dashboard counts sessions. It does not count dollars, it does not count which runs were exploratory, and it cannot distinguish an engineer who quietly walked away from the tool from an engineer who is using it just as much in their head but holding back to avoid looking expensive on a meter their own manager cannot read. Same downward line. Opposite root causes. Opposite fixes.

Adoption was never the value, and now the cost is loud

Faros included a line that pairs badly with all that spring optimism, and I think it is the most honest sentence in the whole stretch of reporting: 75 percent of engineers use AI tools, yet most organizations see no measurable performance gains. The gain is claimed, the cost is felt, and the measurement in between is mostly missing.

There is a real tension to hold here, and it is worth being precise about. At the level of the whole org, total spend is still climbing, because more agents, more background runs, and more CI usage pile up even as individual humans get cautious. Faros leans on the Jevons-paradox point that cheaper tokens drive more total spending, not less. Both things are true at once. The aggregate bill goes up while individual engineers throttle their own premium runs. Watch only the aggregate and the rationing disappears. Watch only per-engineer sessions and the runaway loops disappear. Both lenses have to point at the same week.

The meter did not break adoption. It exposed that we were measuring the click instead of the work, and it taxed the exploratory runs that the gains came from first.

The reframe is straightforward to say and a little harder to instrument. Stop reporting percentage of engineers with access as if it were value. Start reporting verified, merged output per active engineer over the token dollars it cost to produce. That is the number that survives a meter, survives a board question, and survives the September cliff when those flex credits expire and the easy buffer disappears.

Three small moves before the credit cliff

If a usage line bent down in your org after June 1, do not send the reminder email yet. It will land as pressure, and pressure on a cost-anxious engineer just teaches them to look busy on the dashboard while rationing where it does not show.

Do three things instead, and they are all small. First, pull the cost data next to the usage data, even if it is rough, so you are reading dollars and sessions on the same chart. Second, set a clear per-engineer monthly ceiling and say it out loud, because an engineer who knows the budget stops self-policing in the dark and starts using the tool with confidence up to the line. Third, protect the exploratory runs on purpose, because those are the ones a blind meter kills first and they are the ones that paid for the whole thing.

None of this requires a new platform or a heroic measurement project. It requires looking at one more column before September, and trusting that a dip in a number you were never quite sure of is information, not an emergency. The teams moving from adoption to accountability right now are not the ones with the most agents. They are the ones who finally measured the thing that was worth measuring, and got calmer once they could see it.