On August 26, 2026, Google and Microsoft each published a post about the same problem: agent costs are difficult to predict and even harder to control.
They led with different halves of the answer.
Google's post, Flexible Billing and Cost Controls for Agents on Google Cloud, is mainly about governing and purchasing agent capacity. Microsoft's The Economics of Agent Optimization: Four Ways to Lower the Cost focuses on reducing the cost of the work itself.
Both companies offer tools for both problems. What each chose to emphasize is what makes the comparison useful.
Why Agent Bills Are Hard to Predict
Microsoft's post opens with the clearest explanation in either article:
"An agent is a loop around a model. It plans, calls a tool, reads the result, and reasons again, so a single completed outcome can take a dozen model requests."
That is the problem in two sentences.
A single request is a poor unit of cost for an agent. One user outcome can require many model calls, several tools, and multiple retries when something goes wrong.
Older software systems retry and spread work across services too. An agent adds another source of uncertainty because it can decide how much work to perform at runtime, based on what it discovers.
You cannot always count that work in advance. The cost of two apparently similar requests may be very different.
That makes traditional budgeting difficult. A forecast based on users or requests may miss the number of model calls, tool invocations, retries, and tokens generated inside each agent run.
Google Leads With Commercial Control
Google leads with the financial controls around agent activity.
Customers can commit to a monthly Gemini Enterprise spend level and receive a 10% discount for one year or 20% for three years. They can set monthly spending limits for projects. When a project reaches its limit, agent API calls pause without stopping unrelated production infrastructure.
Automated alerts arrive at 50%, 80%, and 100% of the budget. When spending changes unexpectedly, Google's billing tools identify the top three SKUs driving the increase.
Google also offers a FinOps Explainability agent that helps investigate AI cost drivers. It can compare spending across models, API keys, projects, and input or output tokens.
Notice the intended reader. This is written mainly for the person who owns the budget, not the person who writes the agent loop.
The inclusion of hard spending limits reflects a recognition that agent workloads can be difficult to predict and occasionally exceed customer expectations.
Microsoft Leads With Runtime Economics
Microsoft leads with the engineering choices inside the workload.
Its four main levers are model selection, caching, prompt and agent optimization, and observability.
Suppose only one step in ten needs a frontier model. Routing the other nine to smaller models could reduce the bill without changing the final result, provided evaluation confirms that quality holds.
Model routing can reduce runtime spending, but the routing decision has costs and quality trade-offs of its own, as I discussed in The Hidden Cost of Choosing an AI Model.
Microsoft also recommends caching the stable parts of a prompt, including system instructions and tool descriptions. Cache reads are billed at a discount rather than automatically being free.
The prompt itself is another cost lever. Shorter instructions, fewer irrelevant tools, summarized conversation history, and better control of retrieved context can reduce tokens on every turn.
The final lever is measurement. Teams need to know which model answered, how many tokens it used, whether the cache worked, how long the request took, and whether the result met the required quality level.
Microsoft's post is not purely about engineering. It tells teams to connect traces and evaluations with Azure budgets, alerts, and cost tags so that a regression appears as a notification rather than a surprise at the end of the month.
That is governance inside the engineering article.
The Better Unit Is a Finished Outcome
The strongest idea in either post is simply a better way to count.
Stop asking what one request costs. Ask what one successful outcome costs.
That measure includes every turn, tool call, failed attempt, and retry required to finish the job.
An optimization that lowers the cost of one request but increases the number of requests may not save anything. Cost per successful outcome exposes that mistake.
It is the number that matters most, and it is still the number many organizations do not track.
Both Companies Have Both Halves
The contrast between the two posts should not be pushed too far.
Google has engineering levers comparable to the ones Microsoft describes. Vertex AI has offered context caching since 2024. For supported Gemini models, cached tokens can cost 10% of the standard input-token rate, although explicit caching may also carry storage charges.
Google also offers prompt optimization, batch processing, multiple model sizes, and different pricing options for work that does not require an immediate response.
None of that is central to its August 26 article.
The companies have similar categories of tools but make different editorial choices about which ones to emphasize.
Both articles naturally reflect their providers' commercial positions. Microsoft's article highlights runtime capabilities available through Foundry. Google's emphasizes governance and purchasing mechanisms available through Gemini Enterprise.
The advice may still be useful, but it is not neutral.
The Batch Discount Is Becoming a Market Convention
Both posts price patience at roughly half.
Microsoft says Batch deployments can provide up to 50% lower costs for work that does not require an immediate response.
Google says its coming deferred execution option will run eligible work during off-peak capacity windows for up to half the normal inference cost.
The same pattern appears elsewhere.
Anthropic charges 50% of standard API prices for batch requests. OpenAI advertises a 50% discount through its Batch API. Amazon Bedrock offers selected foundation models at 50% of on-demand inference pricing. Google's Gemini API also lists lower batch prices for supported models.
When this many providers converge on roughly the same discount, 50% starts to look less like a temporary sale and more like a market convention for delay-tolerant AI work.
Google also explains part of the economics directly: eligible deferred jobs can run during off-peak capacity windows. Providers would rather sell unused capacity at a discount than leave it idle.
The fine print still matters.
Microsoft and Google both say "up to." Bedrock applies the discount only to supported models. Completion windows and usage limits vary by provider. Batch processing is asynchronous, not merely a slower interactive response.
The practical lesson is simple. Move work that can genuinely wait: bulk classification, document enrichment, evaluation runs, scheduled reports, and offline analysis.
Do not assume an entire agent workflow can be placed into one batch simply because nobody is waiting for the final answer. Steps that depend on earlier results still need to run in the correct order. Provider support for tools, state, and multi-turn work also differs.
The Attribution Gap Remains
Neither post tells readers what a real agent workflow costs in dollars.
Microsoft identifies cost per successful outcome as the correct metric but does not provide a complete financial example. Google provides discounts and controls without showing the cost of one finished agent task.
Neither post demonstrates how to allocate the complete cost of a multi-turn agent trace to a customer, product feature, or team.
Both platforms provide parts of the answer. Azure offers traces and cost tagging. Google can break spending down by project, API key, model, and token type.
The invoice records infrastructure consumption. The harder task is connecting that consumption to the customer outcome that created it and deciding whether the outcome produced enough value.
Without that connection, teams can optimize tokens while losing sight of the work those tokens were supposed to complete.
How I Would Run Both Tracks
This is not a strict sequence. Usage optimization and rate optimization should run together. But they do not carry the same risk.
1. Instrument and Fence the Work
Start with traces, cost allocation, budgets, alerts, and limits on turns, tool calls, and retries.
This makes the workload visible and prevents one failed loop from becoming an unlimited bill.
Do not wait for perfect measurement before taking action. Begin with enough visibility to identify large cost drivers and improve the data over time.
2. Measure the Right Unit
Track cost per successful outcome, not only cost per request.
Measure how much it costs to resolve a support case, review a document, produce a report, or complete another business task at the required quality level.
Watch the spread as well as the average. The most expensive 5% of agent runs may contain the loops, retries, and tool failures that create most of the avoidable cost.
3. Remove Runtime Waste
Trim unnecessary context. Cache stable content. Limit the tools available to each step. Route routine work to smaller models when evaluation shows that quality holds.
Set retry limits and investigate why the agent needed to retry. A retry is not only another request. It may be evidence that the workflow, prompt, tool, or model choice is wrong.
4. Batch Work That Can Truly Wait
Move delay-tolerant work to lower-cost batch or deferred execution options.
Start with workloads that are naturally independent: classification, enrichment, evaluation, summarization, and scheduled reporting.
Do not force an interactive or tightly connected workflow into a batch system merely to reach a lower token price.
5. Commit to a Conservative Floor
The FinOps Foundation warns against waiting for usage to become fully optimized before examining rates. That delay often means paying full price throughout the optimization period.
Usage and rate optimization should proceed together.
The discipline lies in the size of the commitment.
Suppose an organization signs a three-year agreement for a 20% discount based on today's usage. If optimization later reduces real demand by 40%, part of that commitment may be paying for work the organization no longer performs.
The waste was not removed. It was converted into a contract.
Committing to a conservative demand floor reduces that risk, but it cannot eliminate it. Even baseline demand can fall because products, prices, providers, or architectures change.
Cover the stable floor with commitments. Leave uncertain growth and experimental workloads on flexible pricing until their demand becomes clearer.
Where This Lands
Agent cost has two layers: how much work the system performs and what the organization pays for each unit of that work.
Google's post emphasizes the second. Microsoft's emphasizes the first.
A serious FinOps program needs both operating together.
Place a meter and a guardrail around every agent workflow. Reduce the cost of a successful outcome. Batch the work that can wait. Buy commitments only for demand that is likely to remain after optimization.
Before doing any of that, determine what one successful agent outcome costs today. Until you can answer that question, every optimization, discount, commitment, and spending cap is operating without a baseline.
References
- Google Cloud — Flexible Billing and Cost Controls for Agents on Google Cloud, August 26, 2026
- Microsoft Azure — The Economics of Agent Optimization: Four Ways to Lower the Cost, August 26, 2026
- Google Cloud — Introducing Spend Caps and AI Cost Visibility
- Google Cloud — Vertex AI Context Caching
- Anthropic — Message Batches
- OpenAI — Batch API
- Amazon Web Services — Amazon Bedrock Batch Inference
- Google AI — Gemini API Pricing
- FinOps Foundation — Rate Optimization