The AI Pricing Footnotes That Decide Your Bill Next Year

Which line on an AI pricing page actually decides your bill?

Rarely the headline number. The lines that decide your bill are the ones set in small type underneath: cached input rates, scheduled price changes with dates attached, per query charges for grounding, and regional uplifts. Those footnotes move costs by multiples, not percentages.

I read these pages properly because I run automations that call models thousands of times, and because clients ask me to forecast a number. Forecasting from a headline price produces a figure that is confidently wrong.

Here is what is actually written on the three vendor pricing pages I check most often, and what each footnote means for a marketing team planning next year.

What is a pricing footnote and why does it matter?

A pricing footnote is any condition attached to the headline rate. It sets when the price applies, what counts as a billable unit, and what happens at scale. Headline prices compare models. Footnotes compare bills. Only one of those two things arrives in your inbox at the end of the month.

The reason footnotes matter more in AI than in most software is volume. A subscription mistake costs you the difference between two plans. A per token mistake multiplies across every run of every automation, every day, for as long as the thing is switched on.

So I read pricing pages the way I read a contract. The interesting parts are the dates, the multipliers, and the definitions of a unit.

Which footnotes are live right now across the big three?

Three stand out today. Google publishes time limited pricing with future dates attached. OpenAI charges a regional uplift on data residency endpoints. Anthropic publishes a cache multiplier that differs between model families. Each of these changes a forecast more than a headline rate does.

Google's Gemini API pricing page lists Gemini 3.8 Flash at 0.75 dollars per million input tokens through December 31, 2026, and 1.50 dollars starting January 1, 2027. Output, including thinking tokens, is listed at 3.75 dollars through the end of 2026 and 7.50 dollars after that. If you plan a pipeline on today's rate, your plan expires on New Year's Day.

OpenAI's pricing page states that regional processing endpoints for data residency are charged a ten percent uplift for models released on or after March 5, 2026 that are eligible for data residency. For a European or Indian customer with residency requirements, that is not a footnote, it is a line item.

Anthropic's pricing documentation notes that cache hits and refreshes on most models use a multiplier of one tenth of the base input price. That is the footnote that decides whether prompt caching is worth engineering around, and it usually is.

Why does cached input pricing change how you build?

Because a cached token can cost a fraction of a fresh one, which rewards a completely different prompt structure. Put the stable material first and the variable material last, and the stable part can be served from cache on later calls. The saving is structural, not clever.

The published numbers make the point. OpenAI lists gpt-6-astra at ten dollars per million input tokens and one dollar per million cached input tokens on standard short context pricing. Anthropic lists Claude Opus 5 at five dollars per million input tokens, with cache hits and refreshes at fifty cents. Google lists context caching for Gemini 3.8 Flash at 0.075 dollars per million tokens through December 31, 2026.

In each case the cached rate is roughly a tenth of the fresh rate. That is a big enough gap to change design decisions. A long, stable system prompt stops being expensive and starts being nearly free on repeat calls, which means you can afford far more context than intuition suggests.

I went deeper on the mechanics in my piece on prompt caching and content costs. The summary is that most teams write prompts in the order they thought of them rather than the order that caches well.

What does a scheduled price increase do to a content pipeline?

It sets an expiry date on your business case. A pipeline that is comfortably profitable at one rate can be marginal at double. The danger is not the increase itself, which is published in advance. The danger is that nobody revisits the assumption, because the automation keeps working perfectly while the maths quietly stops.

Prices move in both directions, and it is worth noticing when they move your way. Anthropic's pricing documentation records that the two dollar and ten dollar per million input and output token pricing for Claude Sonnet 5, announced at launch as introductory pricing through August 31, 2026, is now the standard price, and that a previously scheduled increase to three dollars and fifteen dollars will not occur.

My habit is to put every dated price into a calendar reminder two weeks before the date. It takes seconds and it turns a surprise into a decision. Without it, the first signal is an invoice.

Do grounding and search calls get billed separately?

Yes, and this is the footnote people miss most often. Google's Gemini API pricing page lists grounding with Google Search at fourteen dollars per one thousand search queries beyond the free allowance, and notes that a single customer request to Gemini may result in one or more queries to Google Search, with each individual query charged.

Read that carefully, because it separates two things people treat as one. A request is what your application sends. A query is what the system performs. If an average request triggers three searches, your effective cost per request is three times what a quick reading suggests.

The same page lists grounding with Google Maps as five thousand prompts per month free, shared across Gemini 3, then billed at the same rate. Shared allowances are their own trap, because they run out faster than per model allowances when you use several models.

This is the general lesson. Whenever a vendor bills per something, find out who decides how many somethings happen. If the answer is the system rather than you, model the upper bound rather than the average.

How should you compare two models fairly?

Compare on your own workload, not on a price table. Take a real task, run it on each candidate, and count the tokens in and out that the task actually consumes. A model with a higher headline price that finishes in fewer output tokens can be cheaper per completed job.

Output pricing deserves particular attention because it is usually several times input pricing. Anthropic lists Claude Haiku 4.5 at one dollar per million input tokens and five dollars per million output tokens. OpenAI lists gpt-5.6-luna at twenty cents input and one dollar twenty output. In both cases the output side dominates for generation work, so verbosity is a cost decision, not a style decision.

Then account for the failures. A cheaper model that needs a second pass, a validation step, or human correction is not cheaper. I build the retry rate into every estimate I give a client, because a per job cost that assumes everything works first time is a marketing number rather than a budget.

If you want the decision framed by task rather than by price, I wrote about matching models to marketing jobs separately.

What would I actually do with this today?

Build a one page cost model for each automation with four inputs: runs per month, tokens in, tokens out, and retry rate. Attach the current rate and the date you read it. Then note any scheduled change. That page takes twenty minutes and survives every vendor announcement.

Where a workload is large and repetitive, route it. Expensive models for judgment, cheap models for extraction and classification, cache for anything stable. I described that pattern in building a model router for content costs, and it consistently saves more than switching vendors does.

Above all, write down the assumption. An automation whose cost basis is undocumented will be audited eventually, usually by a finance team asking a question you cannot answer quickly.

What should you do next?

Open the pricing pages for the models you actually use, read only the small type, and write down every date, multiplier and per query charge you find. Put the dates in a calendar. Then check your largest automation against those numbers and see whether your business case still holds.

Vendors are not hiding any of this. It is published, dated, and specific. The gap is simply that almost nobody reads past the table, and the table is the part designed to be comparable rather than accurate.

If you want help turning that into a forecast you can defend, send me the shape of your workload and I will tell you what I would budget for it.