How to see OpenAI and Gemini search queries

Run the selected provider's native web-search API and inspect only the returned search-action fields. A query is observed only when OpenAI or Gemini exposes that query string in the response.

Read this before relying on browser tricks, screenshots or generated guesses about what ChatGPT or Gemini searched.

Use a documented web-search API route

OpenAI documents web-search calls in Responses API output. Depending on model and action type, the response can expose one query or a list of queries alongside source annotations.

ai-fanout.com sends one bounded server request with web search enabled and storage disabled. The key stays server-side, and the parser accepts only recognizable query fields.

Enter one short topic, choose OpenAI, set language and country only when relevant, complete the CAPTCHA and run the request. The result records model, locale, time, search-action count and any exposed query strings.

Open sources separately. A returned URL documents visibility in that run, not a Google ranking, OpenAI endorsement or permanent link to the query.

A consumer chat interface is not a stable data contract. Internal requests can change, include unrelated identifiers or omit a reusable search-query field.

Even if developer tools show a search-like string once, that does not prove permanent access to ChatGPT internals. A documented API response is narrower, but reproducible.

The honest result is that the API exposed no query string. Search may have been skipped, the field may be absent, or the response may have ended before expected output became available.

Do not ask another model to invent what OpenAI probably searched and present it as observed. Use the separate Search Ideas mode if modelled brainstorming is useful.

It proves that one named API response exposed those fields at a recorded time under this protocol. It does not prove that chatgpt.com used the same queries, that the query has human demand, or that another run will reproduce the list.

  • Keep the input short
  • Record model, locale and time
  • Accept zero visible queries
  • Export only exposed fields

The run has four visible stages

The application sends topic and optional locale context. OpenAI decides whether to search and which searches to run within the tool limit. Search returns web context, and the model processes it while producing the response.

The response may contain search actions, query arguments, URL annotations and usage fields. ai-fanout.com extracts those fields and discards the prose answer because the tool is about fanout.

A provider action can bundle several query strings. One action with four queries is not contradictory: the action is the tool call; the strings are arguments inside it.

If several queries and sources arrive together, assigning every URL to one query would add a relationship the provider did not send.

For web-search runs, input usage can include search context supplied to the model. A three-word keyword may therefore lead to thousands of input tokens.

The site already requests low search context and limits output. A much smaller count would require less search context or a different, no longer provider-native architecture.

Search calls, output, duration, daily use and monthly spend are capped. This keeps the free tool controlled, but also makes every result a bounded sample rather than an exhaustive map.

A query records what the action looked for. A source records a URL surfaced in the response. Usage records provider-reported tokens and actions. The displayed cost is a dated estimate; provider billing is authoritative.

  • Input and locale
  • Web-search action
  • Web context and sources
  • Response usage

Queries and citations answer different questions

A query shows what the provider searched for. A citation shows a page surfaced in returned evidence. Their presence in one response does not create a one-to-one relationship.

The tool links a source to one query only when both arrive in the same single-query action. Multi-query sources stay attached to the action; Gemini sources remain at run level.

URL, provider, model, locale and time support the narrow claim that the page was visible in that run. They do not reveal selection reasons, how much was read, factual correctness or later recurrence.

Open the page and check the exact claim, publisher, date, scope and commercial interest. Prefer primary documentation for product behavior, specifications and policies.

The response contains no traditional rank, search volume or click potential. Study citation visibility here; use Search Console, analytics and suitable search data for demand and performance.

Reviewed OpenAI observations may be normalized for public examples. Google applies additional restrictions to Grounded Results and Search Suggestions, so Gemini grounded source data is removed before local saving and not published as a corpus.

  • Does it support the claim?
  • Is it current?
  • Is it the closest source?
  • What can it not prove?

Gemini uses Google Search as a grounding tool

The Gemini API can call Google Search while answering. Its interaction response can contain search-call arguments including query strings, plus grounding and citation data. This does not prove gemini.google.com uses the same searches.

The result records topic, model, locale, time, action count and exposed query strings. Sources appear only at the scope Gemini supplies. If no query is exposed, the result remains zero.

The server requests a non-stored interaction, but Google documents unavoidable provider retention when Search grounding is used. ai-fanout.com creates no raw server archive; optional local history starts only after Save.

Google's terms limit caching, analysis and syndication of Grounded Results and Search Suggestions. The site strips those fields before local storage and does not turn them into a public dataset.

Keep topic and locale fixed when switching providers. Compare wording and user jobs, note different source granularity and describe the result as dated API observations, not a general model ranking.

Sources used

These sources support the functions and limits described here. They do not prove claims beyond that scope.

  1. OpenAI Responses API reference

    Supports one stateless Responses API call, store false, max output tokens and strict JSON Schema output.

    Open source
  2. OpenAI web search tool guide

    Documents web_search_call output and search actions that can include the query or queries searched. It does not expose chain of thought or guarantee that every route returns query strings.

    Open source
  3. GPT-5.6 Luna model pricing

    Lists USD 0.20 per million input tokens and USD 1.20 per million output tokens used by the dated per-run estimate.

    Open source
  4. OpenAI web-search pricing

    Lists the standard web_search tool at USD 10 per 1,000 calls plus search-content tokens at model rates.

    Open source
  5. Gemini grounding with Google Search

    Documents Gemini 3.7 Flash Google Search, google_search_call arguments.queries, cited URL annotations and per-query billing.

    Open source
  6. Gemini Developer API zero data retention

    Documents Interactions API store false and the unavoidable 30-day provider retention for prompts, context and output when Grounding with Google Search is used.

    Open source
  7. Gemini API Additional Terms

    Restricts caching, syndication, analysis and reuse of Google Grounded Results and Search Suggestions; drives the Gemini local-save redaction and public-example boundary.

    Open source
  8. Direct OpenAI and Gemini native-fanout implementation

    One direct provider request, strict provider allowlist, provider-exposed query/source parsing, honest zero-query output, CAPTCHA-first shared atomic quota and budget accounting, no raw server archive and separate public flag. Bounded live production fixtures passed for OpenAI and Gemini on 2026-08-26.

    Owner record