Skip to content
BlogCost & ops11 min read

The search line is 3% of the answer line

AI Search is GA with published rates and billing from 1 November 2026. Indexing a document is $0.00146 and a semantic query $0.00075 — the line that changes a decision is the one nobody is looking at.

Cloudflare's AI Search went generally available today, and the interesting part is not the feature list. It is that the post publishes the rates and a start date for the meter: billing begins 1 November 2026, with an email reminder before it is switched on.

Pricing was announced in August 2026. The rates are:

LineRateFree monthly allotment
Base ingestion$0.75 / 1M tokens5M tokens
Image processing (OCR add-on)+$0.50 / 1M tokensshares the 5M pool
Stored data$2.00 / GB-month10 GB
Semantic — hybrid and vector search$0.75 / 1k queries1,000 queries
Full-text$0.10 / 1k queries1,000 queries
Embedding and rerankingincluded with select Workers AI models—

There are "no instance hours, capacity units, or monthly minimums to size up front", and parsing, chunking, embedding, keyword indexing and reranking are all inside those rates. Which means the whole thing reduces to three lines — what you ingest, what you store, what you query — and all three can be computed before you index a single file.

So I computed them.

For a live product the headline number is small enough to ignore, and the line that actually changes a decision is not the one the announcement is about. Indexing a document costs $0.00146. Re-indexing is a purchase order.

What a document costs to index

Take a corpus of 100,000 documents at 2,000 tokens each — four pages of ordinary text. That is 200M tokens, against a free pool of 5M:

ingest     200M − 5M free = 195M billable
           195 × $0.75          = $146.25 once
per doc    $146.25 ÷ 100,000    = $0.00146

$0.00146 per document, one time. Put that next to the number I would quote for extracting a document with a model — $0.01634 all-in, including retries, review and reprocessing — and indexing is just under 9% of extracting once. Eleven times cheaper, for a corpus-wide operation.

That comparison is the honest one, and it cuts against the instinct to treat a new per-unit price as a threat. If search is 9% of what extraction costs and 3% of what the answer costs — both below — then the decision to buy it or build it should not be made on this price at all. It should be made on the operational load you are not carrying.

The place it stops being small is when the corpus is not indexed once.

A re-index is now a purchase order

Two facts from the post, read together:

Switching from a text-only embedding model to a multimodal one doesn't change what you pay to ingest

and ingestion is billed per token, at one rate, regardless of model.

Together those say: the model you choose is free, and changing it is not. Embedding-model choice has been a free parameter in every pipeline I have written about — the cost of a migration was compute time and a dual-write window. Now it is $146.25 per full pass over this corpus, and a dual-write migration is two passes live at once:

first ingest          $146.25
full re-index         $150.00   (the 5M free pool went on pass one)
dual-write migration  $292.50   both indexes, same month

Note the second line. The free monthly allotment is a pool that the first pass consumes entirely, so it never helps again — it is shaped for a steady drip, not for a bulk load. A corpus that ingests once and re-ingests occasionally gets $3.75 of relief in the month it ingests and nothing in the months it does not.

That inverts the advice I gave about tree indexes that cost money to rebuild: there, the rebuild was the expensive thing and the query was cheap. Here the same shape appears in a managed product — build cost is real and recurring-if-you-change-your-mind, query cost is a rounding error — and the practical consequence is identical. Choose the thing that is expensive to reverse as if it were expensive to reverse, because now it is.

The OCR add-on is the one real per-document change

GA adds OCR for scanned PDFs with no extractable text, and bills it as image processing ingestion tokens: +$0.50 per 1M on top of the base $0.75. That is 1.67× the ingest rate, and it lands on exactly the documents that were previously unindexable — the ones where the text layer lies.

Applied to the whole corpus that is $243.75 instead of $146.25. Applied only to the partition that needs it, at a stated 30%:

70% × 195M = 136.5M × $0.75/1M = $102.38
30% × 195M =  58.5M × $1.25/1M = $ 73.13
                                 -------
                                 $175.50

Scoped OCR costs $29.25 more than indexing everything as text and getting a third of the corpus wrong, and $68.25 less than turning it on globally. I would take that trade every time, and the reason to scope it is not thrift — it is that the add-on is billed per token, so paying it on documents that never needed it is paying it forever, on every re-index.

There is a ceiling worth knowing too. The file limit moves from 4 MiB to 10 MiB. At a rough four bytes per token, 10 MiB is about 2.6M tokens, which bounds the largest single-file ingest charge at $1.97, or $3.28 on the OCR path — up from $0.79 at the old limit. That is the worst case for one file, and it is the number to multiply if you are looking at a nightly job.

The query line is 3% of the answer line

Semantic search is $0.75 per 1,000 queries. That is $0.00075 each. Full-text is $0.10 per 1,000 — 7.5× cheaper — and the table prices hybrid search at the semantic rate, so adding the keyword leg to a vector search does not double what you pay per query. The thing I keep recommending over bigger embeddings costs nothing extra at the query layer.

Now price the query against the call that follows it. At the shape I used for vector RAG at k=10 — 9,500 input tokens, 400 output, Claude Sonnet 5 at $2/$10 per MTok:

generation   9,500 × $2/MTok  = $0.0190
               400 × $10/MTok = $0.0040
                                -------
                                $0.0230 per query
search                        = $0.00075
search ÷ generation           =   3.3%
Queries / monthSearch billGeneration bill
1,000$0.00$23.00
10,000$6.75$230.00
100,000$74.25$2,300.00
1,000,000$749.25$23,000.00

Retrieval is one thirty-first of the answer. I have written two posts arguing about retrieval cost — reranking latency and when reranking pays — and this table says the money argument in both was always the smaller half.

Reranking is bundled, so gate it on time only

The rate card lists embedding and reranking as included with select Workers AI models. In when reranking pays I priced a hosted reranker at roughly $1–2 per 1,000 queries and concluded the dominant cost was latency, not money. This goes further: the rerank stage can now cost literally nothing extra, inside a query that is already 3% of the answer.

That removes the last cost argument for the confidence gate I proposed there. Skipping the reranker on the 30–50% of queries whose top hit already dominates still saves latency — keep it for the type-ahead case, where the budget is 100ms and nothing fits — but it no longer saves a line item, because there is no separate line item to save.

Storage is the last line to bite, and I cannot verify the unit

$2.00 per GB-month sounds like the scary one, because it recurs. At the free 10 GB it is also the hardest to predict, because the post does not say what counts toward "stored data" — chunk text, vectors, keyword structures, or all three.

So here is the sensitivity instead of a number:

Index size / document100,000 docsFree tier lasts until
20 KB2.0 GB → $0.00500,000 docs
50 KB5.0 GB → $0.00200,000 docs
100 KB10.0 GB → $0.00100,000 docs

At 20 KB a document, the free allotment covers half a million documents and storage is the last line to bite. At 100 KB — larger dimensions, longer chunks, image vectors — it ends at a hundred thousand, and everything past that is $2 per GB per month forever, whether or not anyone searches. Measure the bytes on your own index once, by dividing a known index size by a known document count, and you replace this table with a fact.

What I would do before 1 November

  1. Log ingestion tokens per run, and alert on the delta. The failure mode here is not a query spike; queries are too cheap to hurt you. It is a loop that re-ingests. A nightly full pass over this corpus is $146.25 the first time and $150.00 every time after — $4,496.25 in the first month against a $146.25 intent. Nothing in the post describes a spending cap, and the trigger is your code, not your users.
  2. Budget the retry on the ingest side. Ingestion retries are billed in full: a 20% retry rate over 195M tokens is $29.25 re-billed, against $1.50 for retrying 2% of a month's 100,000 queries. The retry budget that matters is nineteen times larger on the write path than the read path, which is the opposite of where a search product usually looks.
  3. Make the embedding model a versioned decision. It is price-neutral to run and expensive to change, so treat the choice as a schema decision with a before and after, and keep the reprocess budget for it rather than discovering it.
  4. Scope OCR to a partition. Turn it on where the text layer fails and leave the rest alone.

None of this is an argument against the product. A pipeline with no instance hours and no capacity planning is a real amount of work removed, and my own arithmetic says the query side is a rounding error. It is an argument for reading the rate card as a description of which decisions are now expensive — and the answer is not queries. It is anything that makes you rebuild the index.


The rate card, the 1 November 2026 billing start, the free allotments, the 4 MiB → 10 MiB file limit, the OCR add-on's billing treatment, the model-independence of the ingest rate, the inclusion of parsing, chunking, embedding, keyword indexing and reranking, the "no instance hours, capacity units, or monthly minimums" line, the new 1,000-semantic-plus-1,000-full-text split against the previous shared pool of 2,000, the hybrid-and-vector pricing row, and the statement that switching embedding models does not change what you pay to ingest are all quoted from Cloudflare's GA announcement, published 1 October 2026 and read the same day.

The per-document token count, the 100,000-document corpus, the 30% scanned partition, the 20% ingest retry rate, the bytes-per-document rows and the k=10 query shape are a stated scenario, not measurements — I have no production corpus behind these numbers. The per-query generation figure reuses published Claude Sonnet 5 rates ($2/MTok input, $10/MTok output); the extraction figure of $0.01634 is my own arithmetic at Anthropic's published Haiku 4.5 rates. What is checkable is the rate card; what is mine is everything derived from it.

This is the same review I would run on any retrieval system that has to be evaluated rather than vibe-checked, and the spend-ceiling question is the one an AI reliability audit asks about a pipeline that is already running. More on the arithmetic in token cost per document, what a re-index costs, and the model bill that triples quietly.

Something here

the audit is the cheapest way to find out for certain.