If you need a vehicle for weekly grocery shopping would you buy a Ferrari or buy a Toyota truck for this purpose?
There's a good piece on ioplus.nl describing a trend it calls "tokenmaxing": measuring engineer productivity by raw AI token consumption. Jensen Huang's version of the pitch was that a $500k engineer should spend at least half that on tokens. Uber burned through its entire 2026 AI budget by April and had to cap spend per tool at $1,500/month. One Anthropic user racked up a $150,000 bill in a single month. The counter-trend, "frugal AI," routes simple work to small models and saves the expensive ones for problems that actually need them and providers like Mistral are proving you can get a correct answer in 1,600 characters where a comparable model needs nearly 6,000.
Read from a developer's chair, that's a culture observation. Read from an architect's chair, it's a constraint you've already designed around before, just wearing a new name.
Most teams are burning their AI budget on work that never needed the expensive model in the first place.
Salesforce orgs run inside governor limits: 100 SOQL queries per transaction, a heap size cap, a CPU time budget. Those limits don't exist to punish you, they exist because the platform is shared and unmetered usage by one bad transaction degrades it for everyone else. Good Apex developers internalize this early. You don't query inside a loop not because someone's watching, but because the limit will eventually find the lazy code path for you.
A token budget is the same mechanism with a invoice attached instead of a LimitException. Tokenmaxing is what happens when a team treats that budget as a productivity score instead of a cost constraint exactly like writing more SOQL queries because "more queries" looked like more work.
Frugal AI is just governor-limit thinking applied to context windows.
A few patterns I keep seeing show up specifically in Salesforce dev work, because the platform has unusually large, unusually verbose metadata to begin with.
1. Schema dumps instead of scoped queries. The laziest way to give an agent context on an object is to paste the full describe() output every field, every picklist value, every validation rule, when the task only touches three fields. That's the Apex equivalent of SELECT * on a 200-column object to read one column. Pull the specific fields through the Tooling API or a targeted sf sobject describe filter, and feed the model only what the task needs.
2. One mega-agent instead of narrow ones. I wrote about designing multi-agent Salesforce workflows a few weeks ago, the same architecture that makes a lead-qualification flow maintainable also makes it cheap. A single agent juggling lead research, scoring, CPQ setup, and Slack notifications needs every tool definition and every business rule loaded into context on every single call, whether or not that call touches CPQ at all. Four scoped agents each carry only their own slice. Splitting by topic isn't just cleaner architecture, it's a direct token-spend reduction, the same way splitting a god-class into single-responsibility classes cuts the amount of irrelevant code a reviewer has to load into their head.
3. Model selection per task, not per project. Think of this as a boilerplate work ,scaffolding an LWC component, writing an obvious test class, generating a getter/setter wrapper doesn't need your most expensive model. Save that for the calls that actually require reasoning: sharing model design, picking between a trigger framework and a flow, debugging a flaky governor-limit failure that only reproduces under load. If you're already storing agent config in Custom Metadata Types, the model field is exactly where this routing decision belongs, set per topic, changeable by an admin without a deployment, not hardcoded to whatever model felt safest when the project started.
4. Pasting raw debug logs. A 20KB Apex debug log dropped wholesale into a chat to chase one NullPointerException is the same instinct as a System.debug() left in a hot loop. It works, but it's burning a resource to avoid five minutes of triage. Trim the log to the transaction boundary that actually failed before it goes into context.
5. Re-explaining context every turn instead of automating it. This is one Claude Code hooks already solve well. If you're manually typing "now deploy this and run the tests" after every edit, you're spending tokens restating an instruction that should be deterministic. A PostToolUse hook that deploys on save and a Stop hook that runs sf apex run test do the same job for free, because they're shell commands, not prompts the model has to read and reason about.
The fix isn't "use AI less." It's treating token spend the way you'd already treat API call consumption against Salesforce's daily limits: something you plan for and log, not something you discover from a billing alert. If you're logging agent runs to a custom Agent_Run__c object for audit purposes, the token count per run is already sitting right next to the data you need. Token cost per workflow stage becomes a number you can actually look at, the same way you'd look at SOQL query counts in a debug log when a transaction is running slow.
Uber's response to its budget blowout was a blunt top-down cap, $1,500 per tool, decided after the fact. The cheaper version of that fix is architectural: scope your context, route your models, and let narrow agents carry only what they need, so the budget constraint shows up in your design instead of in a Slack message from finance.
None of this is really about being cheap. It's the same discipline that makes a well-designed Apex class easier to maintain than a 2,000-line trigger handler. Scope tightly, reuse what's already loaded, and reach for the expensive tool only when the problem actually calls for it. Tokenmaxing rewarded teams for looking busy. Frugal AI, like every governor limit before it, rewards the ones who designed for the constraint instead of hitting it by accident.
Hooks let you enforce behavior in Claude Code instead of hoping the model does the right thing. The mental model, three Salesforce-specific hooks, and why this matters more in Salesforce than in most stacks.
If your architecture only lives inside the Salesforce landscape, your role is shrinking. Here is why modern architects must master enterprise patterns outside the CRM sandbox.
Building a single AI agent is straightforward. Orchestrating a team of specialized agents to automate complex, end-to-end Salesforce processes is where the real value lies.