SaaStr puts Salesforce's agent API meter at 60 to 1,200 times its integration rate

Priced per call, SaaStr's range means an agent pays between half a cent and ten cents for each successful Salesforce call. An integration making the same call pays less than a hundredth of a cent ^[1]. Firebase sells document reads at $0.06 per 100,000 ^[12], or $0.60 per million ^[2]. Against that price, Salesforce's integration capacity already runs about 138 times higher, and the bottom of the agent range about 8,300 times higher ^[3]. "Same endpoint, same record, same write, 60x to 1,200x, decided by whether a human's integration or an agent made the call," SaaStr wrote ^[15].

The range is SaaStr's estimate, and its top is 20 times its bottom ^[4]. SaaStr's first request of vendors is to publish the rate and cap it. Its other two are to let a registered agent replace a seat, or to charge for the outcome of the work ^[14]. It accepts a meter in principle. Agent traffic is real load and somebody pays for it, SaaStr wrote, and it wants scoped credentials for each agent anyway ^[17]. So registration, the part of Salesforce's terms that looks most like friction ^[3], is the part SaaStr would ask for regardless. Its objection is to vendors that keep the seat, the storage premium and the API tiers and then add a per-call charge on top ^[13]. "Three bills for one piece of work," it wrote ^[20].

Customers can accept the credits when they renew ^[3], in which case Salesforce's revenue per account rises. Heavy agent users can copy the data out instead, and then the meter bills only what still gets written back. Or Salesforce can rewrite the terms along the lines SaaStr lists ^[14].

I think the second outcome is the likeliest for AI-heavy teams, because SaaStr describes it as cheap. Its agents would sync records to their own database, read from there and write back only when something changes ^[7]. Agents read far more than they write, so most of the calls a vendor would meter are lookups against data the customer already holds ^[7]. "That's a weekend project now. Moving a database used to be very hard. Now it's just annoying," SaaStr wrote ^[8]. On that path the team's software bill barely moves. The work moves instead: new agents get built against other systems, or against the customer's own copy, from day one ^[18]. SaaStr argues that this traffic was what kept customers on Salesforce in the first place. "The moat for a system of record was never the software. It was that everything lived there and everything touched it," it wrote ^[16].

A move to agent-native vendors would come more slowly, when customers buy new tools. SaaStr says the apps that are not raising agent prices are the ones that started agentic ^[6]. It also says a bad answer on agent pricing now disqualifies a new tool in its evaluations ^[9]. That test reaches Salesforce only when a customer shops for a replacement. A sync job can be written sooner.

The view fails if agents' metered calls turn out to be mostly writes, or if the reads cannot be served from a copy. In that case the credits land on the customer, and Salesforce gets the first outcome.