Telemetry, a 5x Price Rise, and the Trust Problem With Your Coding Agent

A major model release in mid-2026 was supposed to be a capability story. Instead the discussion that followed was about two things nobody at the launch had planned to discuss: allegations about telemetry that was difficult to turn off, and a price increase that landed without much announcement. The technical claims were contested, partly walked back, and argued over at length. The reaction was not really about the claims. It was about what developers had quietly agreed to over the previous two years and had not thought through.

Why This Category Provokes a Reaction Others Do Not

Developers install analytics-laden software constantly without complaint. Editors phone home. Package managers report usage. Build tools collect crash data. The reaction to coding agents is categorically different, and the reason is not inconsistency. It is access.

A coding agent, by design and necessity, reads your entire repository, including the files with the credentials someone committed in 2019 that nobody has rotated. It sees your environment variables. It runs shell commands with your privileges. It reads your git history, your internal documentation, and whatever the previous engineer wrote in a comment about the acquisition. No other developer tool has that surface area, and the trust required is closer to what you extend to an employee than to a text editor.

Layer on top of that the fact that most of these tools arrived free or heavily subsidised during a growth phase, embedded themselves in daily workflow, and then began adjusting terms. That sequence is entirely normal in software and entirely predictable in hindsight. It still produces a specific kind of anger, because the switching cost was accumulated during the period when the terms were generous.

The Pricing Half Is the Structural Half

Telemetry generates louder discussion; pricing does more damage, and the mechanics are worth understanding because they are not arbitrary. Agentic coding consumes tokens at a rate that bears no resemblance to chat. A single autonomous task reading dozens of files, running tests, and iterating can consume more tokens than a month of conversational use. When a tool is priced as a subscription and used as an agent, the vendor's margin is a function of how effectively each customer uses the product.

That is a business model with a built-in contradiction: the better a customer gets at the tool, the more expensive that customer becomes. It is why we saw the dynamics described in token pricing breaking enterprise AI budgets, where one large employer pulled an internal deployment specifically because engineers used it too well, and another exhausted an annual AI budget in four months. Price rises in this category are not opportunism so much as arithmetic catching up.

Neither model is dishonest. What produced the reaction was the transition happening without warning, on a product that had become load-bearing. The lesson for buyers is not to avoid one model or the other. It is that any pricing structure whose sustainability depends on you not using the product much is a structure that will change.

The Open-Source Hedge, Assessed Honestly

The visible response has been a surge of interest in open-source coding agents, a shift we looked at in the open-source coding agent takeover. The appeal is direct: you can read the source, you can see what it sends, you can point it at whichever model you want, and nobody can change the terms underneath you.

The honest assessment is that this buys real optionality and costs real capability, and the size of both is often misrepresented by whoever is arguing. Open agents have closed most of the gap on the core loop. Where they remain behind is the accumulated refinement: how gracefully the tool recovers from a failed edit, how well it manages context on a large repository, how good the defaults are on a codebase it has never seen. That refinement comes from a lot of user feedback and a lot of paid engineering, and it is not evenly distributed.

The other cost is real too. Running an open agent well means choosing models, managing keys, tuning context strategy, and owning the outcome when it misbehaves. That is a genuine operational load a vendor was previously carrying. For a team with a platform function, it is a reasonable trade. For a small team, "we saved money by self-managing our coding agent" often translates to an engineer spending a day a week on it.

The Security Review Most Teams Skipped

Here is the part that should be uncomfortable. Most organisations that would run a full security review before installing a monitoring agent on a build server have coding agents on every engineer's laptop that arrived through a personal signup and a shell one-liner. The tool with the deepest access got the least scrutiny, precisely because it came in as a productivity tool rather than as infrastructure.

That is the shadow AI pattern from banned tools employees use anyway, with a sharper edge, because a chat window sees what someone pastes into it and an agent sees everything. The right response is not a ban, which reliably produces worse outcomes. It is to run the review you skipped, on the tool people are already using, and to make the reviewed configuration the easiest one to adopt.

Four questions cover most of it. What leaves the machine, and can you observe it from the network side rather than trusting the documentation. What credentials are reachable from the agent's working directory and environment. What can it execute without confirmation, and is that list what you would have chosen. And where does configuration live, so you know what you would lose in a migration.

None of those questions require a vendor to be adversarial to be worth answering. A tool behaving exactly as documented can still have a default that does not suit a regulated environment, and the time to find that out is not during an incident review.

Four Properties Worth Requiring

Rather than picking a side, it is more useful to name what makes a tool defensible to depend on. Four properties, applicable to open and commercial tools alike.

Inspectable telemetry

Not merely documented. Verifiable. A tool that lets you point its telemetry at your own collector, or that runs cleanly with network egress restricted to the model endpoint, has answered the question in a way a policy page cannot. This is a reasonable thing to ask a vendor and their answer tells you a great deal about their posture regardless of what it is.

Portable configuration

The instructions, project conventions, and custom workflows your team builds around an agent become genuinely valuable over months. If they live in a proprietary format inside one vendor's product, that value is a lock-in mechanism. If they live in plain files in your repository, they are an asset you keep. Prefer tools whose configuration is text you own, and treat that text with the same care as source code.

Model independence

A tool locked to one provider's models inherits every risk of that provider: price changes, deprecations, capacity problems, and quality regressions. Tools that accept an arbitrary endpoint let you route, compare, and fall back, which is the same argument made in the multi-model stack. Provider diversity is worth some inconvenience.

A priced path that does not rely on goodwill

If a tool is free at your usage level and you cannot articulate how the vendor makes money from you eventually, you are on a subsidy with an expiry date. That is fine as long as you know it and have not built anything irreplaceable on top. The tools worth depending on are the ones where you can see the business model and it survives you using the product heavily.

A Workable Policy for a Team of Twenty

Most guidance in this area is written for organisations with a security team and a procurement function. Here is the version for a team that has neither, which is most teams. Five decisions, each of which takes an afternoon.

Pick one or two tools deliberately and say so. The worst outcome is not choosing the wrong tool; it is nine engineers on nine tools with nine sets of terms, which is unreviewable by construction. Name the ones you support, and be explicit that people can trial others on non-production work.

Keep agent instructions in the repository. Project conventions, architectural notes, and standing instructions go in version-controlled files alongside the code. This is portable, reviewable, improves with contribution, and survives switching tools. Teams that do this end up with a genuinely valuable asset within a few months, almost by accident.

Separate credentials from the working directory. The agent should not be able to read your production secrets because they happen to be in a .env file two directories up. Scoped, short-lived credentials and a clean working tree remove most of the realistic exposure without any policy enforcement.

Decide what runs without confirmation. Reading files and running tests, yes. Installing packages, pushing branches, and touching infrastructure, no. This is the same reversibility sizing that applies to every agent decision, and it is a configuration change rather than a policy document.

Write down the exit plan on one page. Which tool, what it would take to move, what you would lose, and roughly how long. Revisit it when pricing changes. The page is almost never needed and takes twenty minutes, and its real value is that writing it reveals dependencies you did not know you had.

What Vendors Could Take From This

It is easy to write this from the buyer's side and worth spending a paragraph on the other. The vendors in this category are running an unusually hard business: costs that scale with customer skill, a capability frontier that moves quarterly, and a user base that is professionally trained to be sceptical and unusually good at reading network traffic.

The pattern that generates goodwill in this audience is not generosity, it is predictability. Announce pricing changes before they land, with a stated reason and a transition period. Document telemetry in a form that can be verified rather than only asserted, and ship an offline or restricted-egress mode even if few people use it, because its existence is the proof. Keep configuration in the customer's repository. Support arbitrary model endpoints even where it costs some margin.

Every one of those reduces switching cost, which reads as against the vendor's interest and is not, in a market where the buyers are engineers who will eventually find out either way. Lock-in achieved by making departure difficult produces a customer base that leaves at the first opportunity. Lock-in achieved by being the best option, with the door visibly unlocked, is the version that survived in every previous developer tools cycle.

The Cost of Overreacting

It is worth naming the failure mode on the other side, because it is the more common one in security-conscious organisations. A team reads a story like this, concludes that coding agents are an unacceptable exposure, and blocks them. The measurable outcome is not reduced risk. It is engineers using personal accounts on personal machines, which removes every control the organisation had and eliminates the audit trail as well.

The productivity difference is also real, and treating it as optional has a compounding cost that is invisible on any dashboard. A team that ships meaningfully slower than its competitors for eighteen months on a principled objection to telemetry has made a trade, whether or not anyone framed it as one. The defensible position is not abstinence. It is choosing a tool deliberately, configuring it tightly, and knowing what you would do if the terms changed.

What the Argument Was Really About

Strip away the specific allegations and the pricing numbers and what remains is a discipline noticing that it has taken on a dependency of unusual depth in an unusually short time. Two years ago these tools were novelties. Now a meaningful share of developers report being unwilling to work without them, a shift we covered in developers refusing to code without AI, and that dependency was accumulated during a period when the terms were unusually favourable and the vendors were unusually accommodating.

The reaction is a healthy one, arriving slightly late. It is the same conversation the industry had about cloud lock-in around 2015 and about proprietary build systems before that, and it tends to resolve the same way: not with a mass migration to open alternatives, but with buyers becoming more literate about what they are agreeing to and vendors becoming more careful about changing terms on load-bearing tools.

The practical position for a team in 2026 is unromantic. Use the tools that make your engineers effective, because the productivity difference is real and refusing it on principle is an expensive gesture. Keep your configuration portable, your model choice open, and your exit path written down. Treat any free tier as temporary and any load-bearing dependency as something that will eventually cost what it costs. That posture works whether the tool you chose is open or commercial, and it is the only one that survives the next pricing announcement without a crisis.