2026-09-15, Fundamentals · GEO

What in-house AI visibility tracking costs to run

The cost of collecting AI answers in-house is rarely the API bill you avoid. It is the engineering time to reach production quality on each engine, plus the maintenance that follows for as long as you run it. Building is the right call when the collection layer is itself your product or you need data no provider returns; the build vs buy comparison covers that decision, and the framework below fills in the numbers behind it.

Definitions

• Collection layer: everything between “we have a prompt” and “we have a structured record of what the engine answered”: execution, parsing, retries and storage.
• Analysis layer: what you build on top: share of voice, citation tracking, competitor reports, alerts. This is where customers compare products.
• Run: one prompt, on one engine, in one market, collected once.

What building involves

Consumer AI products such as ChatGPT, Perplexity, Gemini, Copilot, Grok and Google AI Mode show answers that include web search, citations, product cards and local results. Those surfaces live in the consumer applications, not in the model providers’ developer APIs. Each of the components below exists once per engine.

1. Collection runs

You run automated collection against each product and keep throughput inside what each product allows. That is infrastructure to provision, scale, patch and monitor, sized for your peak run.

2. Parsing that keeps up with interface changes

Each engine renders answers differently: inline citations, grouped sources, shopping cards, maps, follow-up queries. Each needs its own parser, a fixture set, and tests. When an interface changes, the failure can be silent: the run succeeds and a field such as sources comes back empty. Catching that takes data-quality monitoring per field, per engine.

3. Market coverage

Answers differ by country, and for local intent by region. Reporting per market requires collecting from each market and validating that the stored answers reflect it.

4. Queueing, retries and storage

At volume, partial failure is the normal case. You need a queue with priorities, retries that cannot create duplicates, per-run deadlines, result storage and a way to push results to downstream systems. That is a distributed-systems project in its own right.

5. Terms, compliance and review

Each consumer product has its own terms of service. Collecting from them at volume is a decision for your legal and compliance review, per engine, before engineering starts, and again when terms change.

6. On-call

Interfaces change without notice and on no schedule. Somebody owns the pager for each engine.

A cost framework you can fill in

Team cost, engine count and quality bar vary too much for universal numbers. Fill in this table with your own.

Then:

• Build, cost over T months = E × B × C + E × M × C × T + I × T + R
• Buy, cost over T months = the monthly cost of your request volume (below) × T

Adjust for three effects the formulas miss:

1. Build is paid before value. E × B months pass before the first reliable dataset; for a product that competes on time to market, that delay has its own cost.
2. Maintenance scales with engines, not volume. A fifth engine adds a fifth parser and a fifth pager rotation, even if you run few prompts on it.
3. Opportunity cost. Every engineer-month in the collection layer is one not spent on the analysis layer.

Computing the buy side

Buying is priced per request, charged from a prepaid USD balance. The base price per request at the Starter tier is:

Some options add to the price (ChatGPT’s include flags and extra Google News pages are free): on Google Search, +$0.00071 per extra page and +$0.00071 once for the AI Overview. The maximum is reserved and the actual cost charged on success; failed requests are charged nothing, and queued tasks you clear are never charged. Larger tiers, reached by 30-day spend, cost less per request. The details are in the pricing docs.

Worked example 1: a large program

20,000 prompts on ChatGPT and Gemini in the US, plus 2,000 Google News queries in 10 markets:

• Runs per sweep: 20,000 × 2 + 2,000 × 10 = 60,000.
• Cost of the assistants: 20,000 × ($0.0006 + $0.0006) = $24.00.
• Cost of Google News: 2,000 × 10 × $0.0002 = $4.00.
• Cost per full sweep, no add-ons: $24.00 + $4.00 = $28.00.

A weekly sweep (4 a month) is $112 a month at Starter prices, a 30-day spend that reaches the Growth tier. A daily sweep is $840 a month at Starter prices and reaches the Business tier. Once a tier is reached its lower prices apply, so the real bill is lower. Every tier’s prices are on the pricing page.

Worked example 2: a focused program

200 prompts on ChatGPT and Gemini in the US, plus 50 Google News queries in 3 markets, weekly (4 runs a month):

• Cost per prompt: $0.0006 + $0.0006 = $0.0012.
• Per sweep: 200 × $0.0012 + 50 × 3 × $0.0002 = $0.24 + $0.03 = $0.27.
• Per month: $0.27 × 4 = $1.08.

Tiers follow your last 30 days of spend, so estimate from your steady cadence, not your peak. The cost planning guide covers sampling and cadence choices that change these numbers, and sampling vs census covers when you can run fewer prompts without losing the signal.

What the buy side returns

Compare the output as well as the price. Each engine returns structured JSON under result, with fields that differ by engine:

• All AI engines: text, sources[], and markdown with include.markdown.
• ChatGPT: citationPills[], entities[], map[], and with include.shopping inlineProducts[]: the products from its shopping search, with price, link and merchant offers. The searchQueries[] (free with include.searchQueries), shoppingCards[] and ads[] (with include.ads) fields exist but come back empty on the answers served today.
• Gemini: citationPills[], places[].
• Perplexity: citationPills[], related_queries[].
• Copilot: citationPills[].
• Grok: searchQueries[], its web and X searches.

For volume, tasks go through POST /v1/async/task/batch (up to 500 per request) with idempotency keys and webhooks. Retries, deadlines and queueing are part of the API contract rather than code you maintain; see async tasks.

What you still build when you buy

Buying the collection layer moves engineering to the parts that differ between products:

• Prompt set and schedule. Which prompts, engines and markets, and how often. Prompt set design and monitoring cadence cover the choices.
• Submission and retries. Batching, idempotency keys derived from each task’s meaning, and a retry policy that never duplicates work; see idempotency keys.
• A webhook receiver. Signature verification over the raw body, deduplication by task.id, and storage; see verifying webhook signatures.
• Normalization. Field names differ by engine (inlineProducts[].product.title on ChatGPT, inlineProducts[].title on AI Mode; citation ids 0-based on ChatGPT and 1-based elsewhere), so map them into your own schema once.
• The analysis layer. Mentions, citations, share of voice and reports, which is what customers pay for.

SDKs and workflow integrations are listed under integrations; for AI agents, the MCP server exposes each engine as a tool.

Decision criteria

A hybrid also works: buy the engines and markets a provider covers, and build narrowly where you need something specific.

How to evaluate in a week

1. Pick your ten hardest prompts: the ones with shopping, local or citation-heavy answers that break parsers.
2. Run them on every engine you need. A new account’s 100 free requests (once, no card) work on every live engine, so you can evaluate the assistants before paying: 10 prompts on ChatGPT and Gemini are 20 requests. Paid, they would cost 10 × $0.0012 = $0.012.
3. Compare field by field against what your pipeline or manual checks show: citations present, ordering, product cards, places.
4. Check the failure path: send a malformed request and a burst of requests, and confirm your code handles 422, 429 and batch item errors as described in the errors post.
5. Price your volume with the per-request math above and your cadence.
6. Fill in the build table with your own team’s estimates and compare.

Pitfalls in the comparison

• Comparing one engine built to several engines bought. Price the scope you need.
• Ignoring maintenance. First-version cost is the smaller term over any horizon longer than a few months.
• Treating developer model APIs as equivalent. A completion from a model API does not include the consumer app’s web search, citations or product cards; see provider APIs.
• Pricing at peak cadence. Tiers follow 30-day spend; estimate the steady state.
• Skipping the terms review. It belongs at the start of a build plan, not after launch.

The table version of this comparison is at build vs buy; to run your first prompts, start with the quickstart.

Keep reading