Almost every pre-AI B2B product we use has now told us they’re raising prices for agent access.
Salesforce and HubSpot are the two latest, and they’re doing it differently. HubSpot’s increases are mainly for their own agents: Breeze credits, per-resolution pricing, custom agents metering since July. Their MCP server is still free for the agents you bring. Salesforce is going the other way and metering third-party agents. Every successful call an agent makes through MCP or the API becomes a Flex Credit charge, agents have to be registered, and existing customers migrate to the new billing at renewal.
It isn’t just those two.
A niche CRM we’ve used for five-plus years just told us we have to pay extra for agent use of their API. Another product we use deprecated the API 10K, our AI VP of Marketing, was running on. No replacement, no notice worth the name.
The pattern is consistent enough to say out loud: the apps that aren’t doing this are the ones that started agentic. If your pricing was built for agents, you don’t need to bolt a meter onto a seat model. If your pricing was built for humans clicking around in a UI, and the humans are logging in less, the meter has to move somewhere. It’s moving to the API call.
{“model_id”: “unified-v1/prod/20260818-030536”}
What actually happens when we get the email
Here’s the part I don’t think the vendors have thought through.
When a vendor tells us they’re charging for agent API access, the immediate reaction of our agents is: how can we work around this?
Not cheat. Nothing shady. Literally move the data off the platform so there’s no API tax for the agents to pay. Sync the records to our own database, read from there, write back to the vendor only when something actually changes. Agents read far more than they write. Most of the calls a vendor would meter are lookups against data we already have a copy of.
That’s a weekend project now. Moving a database used to be very hard. Now it’s just annoying.
And the humans react the same way, one step later. Nobody wants their agents running on apps that charge steeply for the privilege. When we pick a new tool, “how does this price agent access” is now a real question in the evaluation, and a bad answer is disqualifying.
The death spiral
So here’s what I worry these vendors are inadvertently building.
They meter agent access. Usage drops, because we route around the meter. New agents get built against other systems from day one, or against our own copy of the data. Less data flows through the platform. Less of our work happens there.
And then the thing that made them sticky goes away. The moat for a system of record was never the software. It was that everything lived there and everything touched it. Price the touching, and less of it touches.
Less usage. Less stickiness. Less of a moat. Then a renewal conversation where the vendor has a smaller footprint and we have more options than we did last year.
What would actually work
The meter isn’t the problem. Agent traffic is real load and somebody pays for it. I don’t expect any of this for free, and agent identity, with scoped credentials per agent, is something I want regardless.
The problem is the additive version: keep the seat, keep the storage premium, keep the API tiers, and add a per-call meter on top. Three bills for one piece of work.
The vendors who get this right will do one of three things. Publish the rate and cap it, so we can budget. Let a registered agent replace a seat instead of stacking on top of one. Or price the outcome rather than the call, the way some of these same vendors already price their own agents.
The ones who leave it vague and uncapped will get exactly what they’re asking for: our agents reading from a copy, and writing back as little as possible.
The honest truth: these API calls cost almost nothing
A record read from a database that’s already running is close to free. The rest of the infrastructure world prices it that way:
Look at the two Salesforce rows together. Salesforce already sells extra API capacity today, for integration traffic, at about $83 per million calls. The proposed agent meter lands somewhere between $5,000 and $100,000 per million. Same endpoint, same record, same write, 60x to 1,200x, decided by whether a human’s integration or an agent made the call.
Charging per call isn’t the problem. Firebase has charged $0.06 per 100,000 document reads for years and nobody calls it a tax. The question is the multiple, and what the same vendor charges for the identical call when a human’s integration makes it.
Atlassian is doing a version of this too, and arguably doing it better. Rovo credit usage explicitly includes calls made through the Teamwork Graph CLI and the Atlassian Rovo MCP server, and overage billing starts December 3, 2026, at $0.01 per credit. A basic action is 10 credits, so $0.10, the same rate as an Agentforce action. Two things make it land differently: every paid plan includes an allowance (25 credits per user per month on Standard, 70 on Premium, 150 on Enterprise, pooled org-wide), and reads don’t draw credits today. The allowance is thin, and extra usage is on by default unless an admin caps it. But Atlassian published the rate, published the date, and gave admins a switch. That’s the difference between a meter you can plan around and one you can’t.
Storage tells the same story. Salesforce extra data storage runs about $125/month per 500MB, roughly $3,000 per GB per year. Neon charges about $0.35 per GB-month, roughly $4.20 per GB-year. Several hundred times, for the same bytes on the same kind of hardware.
None of this means don’t charge. Vendors can price on value, and an API call that returns a record worth something to us is worth more than a raw S3 read. Salesforce isn’t selling disk, it’s selling the data model, the permissions, and the ten years of history around that record.
What it does mean is that the gap between cost and price is so wide that our agents will see it immediately and work around it. When one lookup costs thousands of times more through the vendor than through a copy of the same data, the agent isn’t making a hard call. It’s making an obvious one.
We’ll Keep (Most of) Our Current Stack. But No New Apps That Aren’t Agent-Friendly
We’ll stick with our current stack. Ten years of context lives in it, and that context is why our agents are any good.
But we won’t pick another vendor that charges a significant tax on our agents. 10K alone does 30,000+ API calls a day. He won’t put up with it.
