What does it cost an AI agent to read your Salesforce Org?

Uber blew through its entire 2026 AI coding budget by April and capped its engineers at $1,500 a month per person, per agentic coding tool. At two tools per engineer, that is roughly $36,000 a year each, about 11% of median Uber engineering compensation.

But the overspend is not the interesting part. What should that work have cost? Nobody could say. None of the leading coding subscriptions publishes an allowance you could price the work against. That is why a cap was the only lever anyone reached for. But here is the challenge – how can you project what you will spend your tokens on, and how do you ensure you have enough for you and your team to deliver what needs to be done?

In this post, we will price one specific job on one real customer’s Salesforce Org, show why the bill is that shape, and make the case that the fix is a context orchestration layer, not a cheaper token. Your agents are reading the library. Almost none of them ask the catalogue first.

The price for AI is going up

Lots of coding agents, like Claude, are available on subscription plans (e.g. Claude Max plan). But these are heavily subsidised by the model providers to encourage adoption and increase their market share. Independent analysis has shown that on your $ 200-a-month Claude subscription, a heavy user is actually using an equivalent of $3000 dollars or more worth of tokens. And AI providers are increasingly moving to stop subsidising that usage.

GitHub said it plainly on 27 April 2026, announcing the move to usage-based billing: “GitHub has absorbed much of the escalating inference cost behind that usage, but the current premium request model is no longer sustainable.” Every plan moved to usage credits on 1 June, 2026.

It is difficult to foresee how the token pricing will change over time. On the one hand, Claude per-token prices were cut hard and have stayed cut: Claude Sonnet 5 lists at $2/$10 per million tokens against $3/$15 for the generation it replaced, and Opus has held at $5/$25 since Opus 4.5. Anthropic’s CEO Dario Amodei says inference is already profitable at the model level: “if you consider each model to be a company, the model that was trained in 2023 was profitable.” But published prices do not only fall either. Google’s own pricing page today carries a doubling of Gemini 3.7 Flash from 1 January 2027: input from $0.75 to $1.50, output from $3.75 to $7.50.

We have seen the pattern before: subsidised adoption, then repricing, with reported Uber fare rises of roughly 45% to 92% between 2018 and 2022, depending on the study. It is a pattern, not a prophecy – and the AI repricing happened in June, with more likely to come.

Which begs the question – how do you plan for and protect your organization against uncontrolled, unpredictable AI spend going forward?

How much does it cost AI to read your Org?

Let’s take one real customer production Org, anonymised: 851 Apex classes, 1,002 Flows and 79 Apex triggers, excluding managed packages. And let’s not even count reports, list views, validation rules, objects, fields, and all other metadata. That is 1,932 automation components. In terms of token size, that automation scope is about 6.9 million tokens.

6.9 million tokens is not a frightening number. Here is the frightening one. A perfectly disciplined agentic read of that corpus with perfect batching, a 100% cache hit rate, no retries, bills about 158 million tokens. That is 27 times the size of the thing being read, and roughly 95% of it is cache reads of context the model has already seen, because every turn re-sends the conversation so far.

At Anthropic’s published rates of 28 August 2026, just reading that Org’s automation scope costs $790 on Claude Opus 5, or $316 on Claude Sonnet 5. Will you have to read all Apex and flows on every conversation or change request? No. But calculate number of admins or developers on your Salesforce team by number of change requests and assessments needed to be done on a daily or weekly basis (e.g. “let’s audit how we process quotes” or “can we review if we have any unused apex” etc.), and it is not unfathomable that just like at Uber, your Salesforce team could blow through their allocated AI budget for a year fairly quickly.

In the Orgs I look at, nobody has ever costed “read the whole Org” as a line item. It arrives inside a sprint, inside a subscription, inside somebody’s terminal. And that is per attempt. Per agent. Per session that ends without leaving anything behind – while the Org changes underneath it.

The waste is structural, not behavioural

Why is the bill 27 times the corpus? Input tokens dominate agentic coding, and every turn re-pays for the context before it. Anthropic’s own cost documentation is blunt: Claude Code “sends your full conversation with every request”, so a one-line question in a day-old session still draws usage for the whole conversation.

Retries re-pay. Course correction re-pays. A run that goes wrong pays twice for the same reading.

Visual Studio Magazine documented one Copilot session that produced a $180 projected monthly bill on a plan carrying $10–$39 of included credits. Its own root cause: “Multi-turn editing/QA loops resend growing conversation context each turn.”

You cannot budget what you cannot project

None of it arrives as a manageable unit. J.R. Storment, executive director of the FinOps Foundation, told TechCrunch: “In April and May, I started hearing from companies: ‘Oh my god, we are 3x over our entire 2026 token budget, and it’s only April.’“

In the same piece, Faros AI CEO Vitaly Gordon quoted a CTO: “One of my engineers spent $40,000 on tokens last month, and I genuinely don’t know whether I should stop him or should I go and tell everyone else to be like him.“

That is not a spending problem. It is a measurement problem.

Volume is growing faster than unit prices fall: per-developer token consumption rose about 18.6x in nine months, per Nicholas Arcolano, Head of Research at Jellyfish, to TechCrunch. Salesforce’s own VP of Product Management, Sumeet Agrawal, told Fortune that enterprises waste “5–10x more tokens than necessary”.

The cheapest token is the one you never send

Context engineering is the discipline of deciding what an agent sees before it starts work: what enters the context window, what is summarised away, and what is fetched only on demand. In a cost frame, it reduces to one rule. Every token you send is a token you buy; on every turn it stays in the window. We have covered what that means for runtime agents already.

You do not make an unbounded read cheaper. You replace it with a bounded question.

That is the difference between deterministic retrieval and generative search. A lookup returns the dependency answer. An agent grepping your codebase infers it – much more expensively and less reliably.

Anthropic’s own guidance tells agents to use code-intelligence tooling so that “a single ‘go to definition‘ call replaces what might otherwise be a grep followed by reading multiple candidate files”. Fair. But that affordance does not exist for Flows, validation rules, page layouts, or permission sets. Salesforce metadata has no language server, so something else must do that job.

Ask the catalogue, don’t read the library

So how much should it cost to find out where one Salesforce field is used? Three answers, same Org, same published Opus 5 rates.

Answering “what breaks if I delete this field?”	Tokens	Cost
Agent reads the whole Org’s automation corpus to be certain	~158 million	~$790
Grep-first agent: search, then read the candidates	~9.8 million	~$49
Deterministic graph lookup, 25 dependents	7,214	~$0.05

The middle row is the fair comparison. A good agent does not read your whole Org. Against a competent grep-first agent, the graph lookup is roughly 980x cheaper in money- about five cents against forty-nine dollars. Against an agent told to be very thorough (which you might want to do on an old, undocumented Enterprise Org), it is closer to 16,000x.

Parsers, not prompts

Elements builds and curates its own deterministic parsers for Salesforce metadata. They are code, not models: they consume no tokens and return the same answer every time. They run at sync across the whole corpus of Salesforce metadata, not just the Apex. 

By the time your agent is tasked with a question, whether it is scoping the impact of a field to be deleted, or planning something massive like a merger of two Orgs, the reading is done. A single field gets checked, down to what, how, when, and where it is used against flows, validation rules, page layouts, reports, list views, approval processes, Apex classes, and many, many more, adding up to over a hundred different Salesforce dependencies.

That turns “how is this field used across all our automation?” from a reading job into a query. The summary form is about 7000 tokens: which types reference the field, and how many of each. The full listing scales with the number of places the field is used, not with the corpus you would have had to read.

It also reports its own negative space. Checked on two synced Orgs on 28 August 2026, one field lookup inspected 28 metadata types and named 3 more as outside the analysis. A grep cannot tell you what it failed to look at.

Elements’ dependency graph tells you where and how a metadata is referenced in your Org, not what will break: consequence still needs judgement and analysis. But that is now resolved through the Elements MCP server, currently in early access for customers who have been enabled for it. Underneath it sit the Metadata Dictionary and the dependency graph those parsers build across 90+ metadata types, so an agent calls get_dependencies once instead of ingesting your entire Org.

Cap the spend, or change the question

You cannot cap your way out of this. A cap stops the work earlier in the month; it does not make the work cost less. What bends the curve is a cheaper question: fewer tokens sent, fewer turns repaid, fewer answers inferred when they could have been looked up. That is the difference between an agent that reads the library every time it wonders, and one that asks the catalogue first – then reads the three books that matter.

The Elements MCP server, with a growing number of context-grabbing tools, skills and plugins, is in early access.