In my previous article about SaaS, I wrote that I pay for tools whose interfaces I rarely open. An agent uses them for me. The service still delivers value; the way I access it has changed.
Then another question came up: what happens to that service’s economics when I start using it very differently for the same price? And if I’m building a new product that agents will operate, how should I price it?
I think this is an important go-to-market question. Pricing tells customers what work they are buying, how easily they can budget for it, and whether it pays off for me when they actually start using the product.
One person, the same subscription, different usage
Take my second brain in Notion. I can occasionally add notes myself. Or I can ask an agent to save important findings, look up connections, and update existing records. I’m still one customer. But a single sentence from me can trigger several searches, reads, and writes.
Here, I’m looking at an external agent working inside an ordinary SaaS product. I pay the model provider for the model. Notion still has to handle requests, save changes, and make updated data available. The same principle applies to a CRM, project management tool, or document store.
Consider a simple illustrative calculation. An automation runs every five minutes, around the clock, and makes six API calls each time:
288 runs a day × 30 days × 6 calls = 51,840 calls a month.
That averages just 1.2 calls a minute. Yet it adds up to more than fifty thousand operations a month. This is an illustration, not a measurement of my usage or a typical Notion customer. One MCP tool call also does not necessarily equal one API request.
Notion already has safeguards: an average of three API requests per second per connection, plus a shared workspace limit that varies by plan. A low average alone does not guarantee that bursts and other integrations will fit within those limits. It does show the difference between the rate of usage and its long-term volume. Notion documentation
Humans have never been the only source of SaaS traffic. Integrations and automations have existed for years. But agents may make intensive automation accessible to many more customers. The number of subscriptions may then become a weaker indicator of how much work an application performs for a company.
The agent does not have to use the API
An agent can open a browser, search, edit records, and trigger exports through the same interface a person uses. The agent operator pays for the browser and model. The SaaS product still handles searches, saves changes, and prepares results. The public API is only one way to access that work.
This does not mean browser use automatically bypasses quotas. GitHub, for example, explicitly includes both its web interface and REST and GraphQL APIs in certain secondary content-creation limits. Other services may draw the boundaries differently. GitHub: secondary limits
If a provider raises prices only for its public API while including equivalent work through the UI, it may encourage customers to use a browser agent. Whether customers save money is uncertain: they also need to account for the speed, reliability, and cost of browser operation. For providers, this is a reason to measure work across access channels. Clicks or requests alone still do not establish its cost.
Sometimes the agent does not operate the application at all
Scheduled delivery of outputs may be even more interesting. A person sets up report delivery once, and an agent processes the email attachments from then on. The application does not need MCP or even need to know that a machine reads its output.
Imagine a person who used to review one summary a week. An agent can compare twenty report variants every day, find deviations, and pass on only what matters. Over four weeks, that is 4 summaries versus 560 reports: 140 times as many outputs. This is an illustrative scenario of increased demand for reports, not a measurement of traffic or cost growth.
These distribution channels already exist. Power BI supports scheduled email subscriptions to reports and dashboards with a snapshot, link, or attachment. Its documentation allows up to 24 subscriptions per report or dashboard; available options depend on permissions, licensing, and capacity. This establishes that the channel exists, not that agents are driving its growth. Power BI: email subscriptions
I can similarly imagine more scheduled CSV exports to a shared folder, more granular notifications, or more monitored entities. Human attention may stop being the limit on how many outputs are worth requesting. The application could then do more work even as the customer logs in less often and the agent sends it no direct requests.
There is an important condition: if the agent simply reads the same emails the person already received, it may create no additional work for the source SaaS at all. The change happens when our new processing ability leads us to request broader coverage, more frequent outputs, or additional variants.
Even then, email count is not the right cost unit for everything. Generating twenty distinct reports can involve different work from distributing one completed file twenty times. I need to distinguish computation, rendering, transfer, and retention. More copies may accumulate in email, storage, and the agent’s index; some costs arise in downstream services.
Well-designed delivery can also reduce consumption. A change notification can replace repeated polling, and a shared export can replace generating the same result repeatedly. For a new product, I would therefore consider structured outputs, change-only delivery, and an identifier with a creation timestamp so the agent can recognize duplicates or stale reports. The aim is to deliver useful information with a reasonable amount of work.
Google has announced paid overage
The most direct evidence I found comes from Google. On May 1, 2026, it opened the Workspace MCP developer preview and announced a new usage tier model for APIs and agent tools. It explicitly linked the change to large-scale agent activity and the risks of high-volume data access. Google Workspace announcement
The available documentation says that later in 2026, following 90 days’ notice, usage above standard daily thresholds will generate charges on the Google Cloud bill. As of September 8, I found neither unit prices nor confirmation of a general billing rollout in these sources. This is an announced change, which should not be described as a fee already charged to every Workspace user. Quota model and planned billing
Google also estimates that fewer than 1% of active Workspace developers will need to go beyond the standard tier. That is the vendor’s estimate, and its denominator is developers, not end users or traffic. It matters: personal automation does not automatically imply a large new bill. Google’s announcement
What Google measures is interesting too. The Drive API uses weighted units:
| Drive API operation | Quota units |
|---|---|
Read an item, such as files.get |
5 |
Edit an item, such as files.update |
50 |
List items, such as files.list |
100 |
Download, such as files.download |
200 |
A download therefore consumes 40 times as many units as the simple read listed above. That does not establish that it costs Google forty times as much. It shows that counting requests alone may be insufficient for managing consumption. The documentation also includes transition rules for existing projects. Drive API limits
Planned billing runs through the integration’s Cloud project. For a product builder, that raises a practical question: who operates that project, and who will eventually pay for those costs? The agent subscription may not be the only bill in the workflow.
SaaS providers are not starting from scratch
Salesforce was describing the purchase of additional API capacity back in November 2024. Its documentation covers shared organization limits and offers, among other options, an additional 10,000 API calls per day. Monetizing automation predates the current wave of agents. Salesforce: API limits and monitoring
Linear shows another option. For workspace OAuth apps using Actor Authorization, it dynamically increases limits based on the number of paid users. People can remain the commercial unit while also determining the capacity available to their automations. Linear measures GraphQL query complexity as well. Linear rate limits
These examples do not point to one universal future pricing model. A provider can sell more capacity, change included limits, or accept higher usage as a cost of making the product more valuable. More operations alone do not establish lower margins or a need to raise prices. Without internal data, we do not know what the extra work costs or what it brings the company.
When an agent will use your new product
For a founder, this second question may matter even more. If I’m building document processing, search, or monitoring with machine usage in mind, headcount may be a poor basis for pricing.
I would start here: what understandable unit of work is the customer buying from me? For documents, it could be a processed page; for search, a query; for monitoring, an entity checked at a specified frequency. Each has a weakness I need to address when designing the offer.
| Product type | Unit I would test | What the offer needs to explain |
|---|---|---|
| Document processing | Page or document | The difference between a one-page invoice and a hundred-page scan |
| Search | Query with a defined scope | The number of results and depth of processing included |
| Monitoring | Entity × check frequency | What happens when intervals change or checks are repeated |
| Reports and exports | Generated output with a defined scope | The difference between a new calculation, another download, and distributing a copy |
| Browser automation | Runtime minute or completed task | Timeouts, concurrency, and failed attempts |
| Customer support | Defined conversation outcome | When a case is resolved and when a charge is reversed |
This is my proposed decision process, not a universal standard. A good unit must make sense to the customer, be measurable on an invoice, and keep costs reasonably aligned with revenue. It does not need to mirror the internal infrastructure exactly. For equivalent work, I would also check whether pricing unnecessarily favors clicking over the API, or email over a download. Different prices can be justified, but they should not push customers toward a less efficient route just because of the pricing structure.
Firecrawl, for example, lists one credit per page for a basic scrape, two credits per ten search results, and two credits per minute of browser interaction. It sells different types of work through shared credits. Customers still need to translate those credits into their own use case. Firecrawl pricing
Internally, I would measure the cost of each operation type, including retries and downstream services. Externally, I would offer a unit customers can plan around. Credits are packaging; the conversion rules determine whether they make sense.
Volume and speed are different things
One hundred thousand operations spread across a month average roughly 2.3 operations a minute. The same volume in fifteen minutes averages about 6,667 operations a minute. That is 2,880 times the average rate. This is an illustrative calculation for a thirty-day month, not a comparison of actual infrastructure costs.
I would therefore separate how much work a customer buys from how quickly they can consume it. Alongside included volume, a plan might specify concurrent tasks, processing speed, or reserved capacity.
Browserbase shows this directly: its $20-a-month Developer plan includes 100 browser hours, with additional hours at $0.12, and 25 concurrent browsers. The $99 Startup plan includes 500 hours, additional hours at $0.10, and 100 concurrent browsers. This is only part of an offering that includes other metered services. Browserbase pricing
Choosing a plan also expresses the required operating pattern. A company can have modest monthly volume and still need to handle a large burst quickly.
“Pay for the outcome” needs a precise definition
I like that outcome pricing lets customers buy something close to their actual goal. But the word “outcome” has to survive real usage and a billing dispute.
Fin’s documentation lists $0.99 per billable outcome; the base plan described for use with an existing helpdesk costs $49 a month and includes 50 resolutions. Billable outcomes include resolutions and configured procedure handoffs to a human. A resolution may be confirmed by the customer or assumed when they do not request further help after the answer. If they return to the same conversation for more help, the documentation describes deducting that resolution. Fin: outcome definitions and billing
That detail matters more to me than the 99 cents. Outcome pricing needs rules for success, disputes, and attribution. “We processed this document to an agreed specification” can be defined fairly precisely. “We made your company more productive” is much harder to separate from everything else happening in the business.
For a new product, I would also decide in advance who pays for failed attempts. If a system error causes one job to run three times, the customer needs to know whether they bought an attempt, compute time, or a finished output. Repeated delivery of the same request should not silently create additional billable work.
Pricing belongs in the first product experience
For many services like these, my starting hypothesis would be a subscription with included usage and clearly capped overage. The subscription can cover ongoing platform value and basic customer service. Included usage helps the customer estimate a normal month. Overage connects growing usage to revenue.
It is not the automatic choice for every product. Pure pay-as-you-go may suit occasional API usage. A prepaid commitment may fit large, stable demand. Per-user pricing can still make sense where human collaboration creates value. A hybrid model has its own drawback: the customer pays a minimum even in a month with little usage.
And crucially, a predictable minimum bill is not a predictable final bill. Without a cap, overage can surprise subscription customers too.
Firecrawl lets customers set a monthly limit on automatic credit purchases in five-dollar increments, or disable them. Manually purchased credits do not count toward that limit. This is a useful example of why the scope of a limit needs to be clear. Firecrawl pay-as-you-go rules
At launch, I would want to show customers three things: what their normal scenario costs, what ten times the usage would do, and exactly what happens at the budget ceiling. Does work stop, wait in a queue, or require approval for more spending? The API should expose the same information so an agent can respect it.
This is where pricing meets onboarding. If a customer is afraid to successfully launch an automation because they do not know what it will cost, I have both a product problem and a sales problem.
What I would verify before setting a price
I would not wait for perfect pricing. But before launch, I would trace one concrete customer task from the initial request to the invoice:
- Define the work being purchased. What exactly counts as a document, search, or finished outcome, and when does another unit begin?
- Measure actual costs. Cover APIs, browser use, and scheduled output delivery. Include large inputs, failures, retries, and third-party services alongside normal cases. An average can hide a small group of very expensive jobs.
- Calculate three scenarios. A normal month, successful growth, and a faulty loop. For each, work out revenue, costs, and the point where processing stops.
- Show the offer to a customer. Can they estimate their own bill and say whether this is a unit they want to pay for? A cost calculation alone does not establish willingness to pay.
- Verify billing in practice. Connect the same task to usage reporting and the invoice, including reversed charges and repeated requests.
My bet is that agents will weaken the relationship between headcount and consumed work, both by operating applications directly and through the volume of outputs they can process. For some services, significantly; for others, barely at all. That gives founders a practical task: design pricing so that more intensive, useful usage is good news for both the customer and the business.
I would start with one question: if my best customer connected an agent tomorrow and used the product ten times more, would I want to congratulate them or cut off their access?
Sources and pricing checked on September 8, 2026. This article combines the author’s experience, public product documentation, and explicitly labeled illustrative calculations. The documentation establishes service rules; it does not measure the effect of external agents on provider margins. Pricing recommendations are the author’s interpretation.