Salesforce Will Charge Flex Credits for Agentic MCP and API Calls: How to Cut the Bill

Salesforce has confirmed a new billing model for AI agents that work with its platform. Once it switches on, every successful call a registered agent makes to Salesforce, whether over Model Context Protocol (MCP) or directly through an API, will be metered as a Headless Platform Interaction and paid for in Flex Credits.

If your team has started pointing Claude, ChatGPT, Cursor or another agent at an org, this changes the cost of that habit. You already pay the AI provider for the reasoning. Soon you may pay Salesforce for every question the agent asks your org as well.

This post covers what Salesforce has announced, what it has not, and the most practical way to keep the metered number small: stop sending the agent to Salesforce for answers you already have.

What Salesforce announced

The detail comes from Salesforce's own knowledge article, Understand AIforce Impact (published 17 September 2026), and was reported by Salesforce Ben on 22 September. In short:

• Agents must be registered. A new Agentic Identity feature gives each agent its own identity and a narrower permission set, instead of letting it act under the login of the person it assists.
• Registration is what makes usage billable. Once registered, an agent's activity is tracked in Digital Wallet under a new usage type in the Customer 360 Platform category of the Flex Credits rate card.
• Every successful call counts. Each call over MCP or direct API is one Headless Platform Interaction (HPI).
• The price is not set yet. The multiplier is listed as "TBA" and agentic usage is not being metered today. Salesforce says it will give 30 days' notice before metering begins.
• Production only. HPIs are metered only in active production orgs. Sandboxes, scratch orgs and Developer Edition orgs are excluded.
• Traditional integrations are unchanged. Salesforce says their pricing and security stay as they are; the model is aimed at agentic traffic.

The timeline matters as much as the rate. Salesforce is targeting November for the release. New customers who buy on or after the article's publication date must register every agent that uses Salesforce APIs within three months of being told Agentic Identity is available. Existing customers must register agents and move their connections to the new model at renewal. Using any Salesforce MCP server requires registration within three months of notice, for all customers.

Why this adds up quickly

A human asks a question once. An agent works by making many calls, each one small, to build up its picture of the org.

Take a simple request: "Why is the discount on this quote wrong?" A well-behaved agent will list the objects, describe Quote and Opportunity, look for automation on both, open the flows and triggers it finds, read two or three Apex classes, and then run a query or two to check real records. That can easily be twenty or thirty calls before it writes a single sentence of its answer. Do that across a team, every working day, and the call count gets large fast.

The key point is that most of those calls are not about data. They are about metadata: the shape of the org, its fields, its code and its automation. That metadata changes on a release cycle, not minute by minute. Paying for the same describe of Opportunity a few hundred times a week is paying for the same answer again and again.

Salesforce has not published the multiplier, so nobody can yet turn that call count into a dollar figure. You can, however, work out now which of your agent's calls actually need to hit Salesforce, and move the rest elsewhere before the meter starts.

The fix: answer metadata questions from a local copy

The simplest way to cut Headless Platform Interactions is to make fewer of them. If the agent can answer "what fields are on Opportunity?" without asking Salesforce, the interaction never happens and nothing is metered for it.

That is how orgadmin.ai already works, because it was built to save API limits long before Flex Credits applied to agents.

Pull once, read many times

When you connect an org, orgadmin.ai pulls its metadata and stores it: objects and fields, Apex classes and triggers, LWC bundles, flows, debug log lists, company information and any extra metadata types you opt into. From then on, reads are served from that stored copy until someone clicks Refresh. A weekly automatic refresh keeps it current, and you can re-pull a single Apex class or an entire dataset whenever you know something has changed.

One pull replaces hundreds of repeated reads. Browsing the explorer, searching the org or opening a class does not go back to Salesforce.

Point your agent at the stored copy

The orgadmin.ai MCP server exposes that stored copy to the AI client you already use: Claude Code, Codex CLI, Cursor or Claude Desktop. The metadata tools read from the same store the web app uses:

• list_objects and describe_object answer from the stored schema
• list_apex_classes, get_apex_class, list_apex_triggers and the LWC tools return stored source
• list_flows and list_metadata work from the stored inventory
• search_metadata runs across everything already pulled and never contacts Salesforce at all

If something has not been pulled yet, the first read fetches it and stores it, and every read after that comes from the store. The agent gets the same grounded answers, and the repeat questions stop going to Salesforce.

Keep live calls for live data

Some questions do need Salesforce. Record data changes constantly, so run_soql queries the org live, and so do the tools that read a component's full definition on demand or write records. That is the right split: pay for calls that need fresh data, and serve structural questions from a copy.

In practice, an agent investigating a bug through orgadmin.ai might make one or two live SOQL calls rather than thirty mixed metadata and data calls.

Build in a sandbox

Salesforce does not meter HPIs in sandboxes, scratch orgs or Developer Edition orgs. orgadmin.ai connects to sandboxes in the same way as production, so development, testing and security reviews can run against a sandbox, with production kept for questions that genuinely need production data.

The reasoning stays on your own subscription

When an agent drives orgadmin.ai over MCP, the thinking happens in your client and is billed by your AI provider, not by orgadmin.ai's AI allowance. A security review or tech debt scan run from Claude Code reads the org through the stored copy and writes its findings back into orgadmin.ai for your team to triage.

What is still unknown

We would rather be clear than oversell this, because several important details are not public yet:

• The rate. Until Salesforce publishes the HPI multiplier, nobody can price an agent session precisely.
• How intermediaries are classified. Salesforce's article defines billable traffic as calls made by a registered agent, and says traditional integrations keep their current terms. It does not yet say how it will treat a tool that sits between an agent and the platform. orgadmin.ai connects through your org's own OAuth connection. Whatever classification Salesforce settles on, the number of calls that reach Salesforce is still far smaller when metadata is served from a stored copy, and that is the number any meter would count.
• Contract terms. Existing customers move to the new model at renewal, so the timing for your org depends on your contract. Your account executive is the source for that.

What to do before metering starts

1. List your agents. Include everything that talks to Salesforce over MCP or the API on someone's behalf: coding assistants, chat clients, internal bots.
2. Estimate their call volume. Check how often each one reads metadata compared with live data. For most agents, metadata reads dominate.
3. Move metadata reads to a stored copy. Whether you use orgadmin.ai or something else, stop paying Salesforce again and again for answers that change once a release.
4. Do development work in sandboxes. It is free under the new model, and it is safer anyway.
5. Plan registration. Agentic Identity is also a real security improvement. Giving each agent its own narrow identity is better than letting it borrow an administrator's.

The billing change is Salesforce's decision. How many billable calls your agents make is still yours to control.