Cloudflare’s October 1, 2026 general-availability announcement schedules AI Search usage-based billing to begin November 1. For teams reviewing an ingestion estimate, a useful detail is where the token count is measured: after content has been parsed and divided into the chunks that will be indexed.
Cloudflare’s announcement and November 1 billing date
Count the indexed chunks, not only the source
Cloudflare’s pricing documentation, updated October 30, says each final indexed chunk is tokenized with cl100k_base. Text repeated through chunk overlap is counted in each chunk where it appears. Included monthly usage and the applicable rates still matter; an ingestion token count alone is not a complete invoice.
Cloudflare’s current ingestion-counting and pricing documentation
A fictional example makes the difference visible
Imagine a text whose original sequence contains 1,000 tokens. For this deliberately simplified exercise, assume two indexed chunks contain 600 tokens each, with 200 tokens appearing in both. Adding the chunks gives 1,200 token occurrences. Counting unique positions in the original sequence gives 1,000. Those totals answer different questions.
The extra 200 occurrences are 20% of the original 1,000. They do not represent 200 new facts or a larger source file; they represent repeated context in this example. These numbers are invented for arithmetic practice, not outputs from Cloudflare or a real tokenizer. Actual chunk boundaries and tokenization must be measured.
It would also be wrong to assume that every document incurs a 20% increase. A different document, chunk arrangement or overlap can produce a different result. The example explains why a source-only estimate can differ from the indexed total; it does not supply a universal multiplier.
Prepare a small ingestion worksheet
For an authorized trial, record the source sample, parsing choices, chunk configuration and measurement method. Keep separate columns for the original-text estimate, the sum across final chunks and the reported ingestion usage. Preserve the sample and configuration so another reviewer can reproduce the comparison.
Start with content you are permitted to process. Use an ordinary text sample for the first comparison, then review other formats separately. If the figures differ, identify which stage changed the content before applying a rate. Avoid changing several parsing and chunking choices at once, because that makes the difference harder to explain.
Keep retrieval quality in the decision
A smaller ingestion count is only one outcome. In a later comparison, keep the same set of representative reader questions and inspect whether the retrieved passages still contain enough context to answer them. Record omissions and irrelevant results alongside usage. Do not remove context solely to make a token estimate smaller.
When projecting a budget, use the current allowance and rate rules for the relevant usage, then account for the other services your application uses. Keep the calculation’s assumptions visible. This article explains a documented counting rule; no customer account, ingestion job, search-quality test or invoice was inspected.
Count the fictional chunks
