GPT-4o Search Preview

Search Quality Was the Main Reason to Pay More

At launch, OpenAI reported 90% SimpleQA accuracy for GPT-4o Search Preview and 88% for GPT-4o Mini Search Preview. SimpleQA measures short factual question answering, so the difference did not prove that the full model would win every production search task, but it illustrated the intended positioning.

This made the full model relevant when incorrect synthesis, missed context, or weak interpretation of search results had a higher business cost than the model bill. A research assistant for analysts, for example, may tolerate higher inference cost if it improves the reliability of web-grounded answers.

The Mini version was the better economic fit when query volume dominated the decision and its answer quality met the application's threshold. The full version was the candidate to test when the same queries exposed quality gaps.

For historical evaluations, this distinction is useful: compare accepted-answer rate and citation quality, not only token prices.

Search Quality Includes Source Quality

A fluent answer can still be a poor search result if the underlying sources are weak, irrelevant, or difficult for the user to inspect.

OpenAI's web-search responses include inline citations and URL citation annotations. Those annotations provide source metadata such as page URLs and titles, allowing the client interface to render clear links next to the claims they support.

OpenAI's current web-search guidance requires citations to be visible and clickable when search-derived information is shown to end users. That requirement should survive a migration from the retired preview model.

For evaluation, score citations separately from prose quality. A useful test can ask whether each important current claim is supported, whether the cited page is relevant, and whether the user can actually open the source.

Retrieved Web Evidence Uses Context Too

In a search workflow, the context budget includes more than user messages and conversation history. Retrieved web evidence also has to be passed to the model so it can synthesize a grounded answer.

The legacy search interface exposed search_context_size, which controlled how much search-result context was made available before answer generation. Increasing the search context could expose more evidence, while decreasing it could reduce latency and token usage.

This means search quality and context efficiency were linked. A difficult query might benefit from richer evidence, while a narrow factual query could be answered with less retrieved material.

Modern Responses API web search keeps search context as a separate design concern and adds newer controls unavailable to the legacy Chat Completions preview models.

• Context window: 128,000 tokens.
• Maximum output: 16,384 tokens.
• Retrieved web evidence consumes part of the effective working context.
• Search context size influenced quality, latency, and cost.

Move From a Dedicated Search Model to a Search Tool

OpenAI recommends migrating gpt-4o-search-preview to the Responses API web_search tool. If an application must stay on Chat Completions, OpenAI points to gpt-5-search-api.

The Responses approach is more flexible because search is a hosted tool rather than the identity of the model itself. It supports newer controls such as domain filters, external web-access settings, and returned-token budgets. Search can also be combined with broader tool-oriented workflows.

Migration testing should preserve the behavior users actually depend on: current-information accuracy, citation visibility, source relevance, response latency, search frequency, structured-output validity, and total cost.

Do not validate migration with a handful of generic prompts. Use the real search queries and difficult cases that justified the full GPT-4o search model in the first place.