The grant brief that needs a dated answer
A museum administrator is preparing an application and needs to confirm whether a public grant still accepts organizations with a fiscal sponsor. A search assistant can locate program pages, but the answer must be grounded in the current eligibility language rather than an attractive summary. The OpenAI Responses API offers the built-in web_search tool with a search_context_size setting. This controls how much retrieved web content the model receives for its response. It does not determine whether the grant page is authoritative, current, or complete. This guide uses a fictional grant review and instructional drawings; it reports no live API evaluation or verified funding decision.
Understand low, medium, and high
The official web-search guide documents low, medium, and high values for search_context_size. Low is sensible for a narrowly worded fact check, medium is a balanced default, and high can be useful when an answer may need more detail from retrieved pages. This is a high-level context budget, not an instruction to read exactly three sites or provide a fixed citation count. A high setting cannot repair a vague question, and a low setting does not automatically mean low quality. Start with the question and evidence burden; do not choose a setting simply because a larger value sounds more rigorous.
Frame one verifiable eligibility question
Write down the program name, issuing agency, application cycle, jurisdiction, and the exact condition to verify. Ask for the official eligibility passage and its update date, rather than asking whether a hypothetical museum is definitely eligible. Separate the fiscal-sponsor rule from award amounts, submission deadlines, and required attachments. Those may reside on different pages with different revision dates. For a grant where disqualification would be costly, use a second official source such as the application instructions, when available. If the search tool provides only a third-party article, the correct response is to label the answer provisional, not to infer that the primary policy must agree.
Set the option on the search tool
In a Responses request, configure the web_search tool with search_context_size set to low, medium, or high. The setting belongs to the tool definition, not to the top-level input prompt and not to a separate web browser. The API documentation shows this structure for supported clients. Keep the model, question, and other search controls constant when comparing the usefulness of the settings in your own environment. If your workflow requires a web search, review tool_choice behavior independently; when the model may decline a search under auto, a missing result does not establish that no source exists. Avoid claiming any particular response time or token bill without measuring it.
Decide when richer context is justified
Consider high context if eligibility depends on a definition, exception, footnote, and application-year appendix that must be read together. Medium may suffice when there is a clearly titled requirements page and a simple cross-check. Low can fit a tightly scoped lookup of a single official date, provided the assistant still exposes a source you can open. The decision should consider the cost of a wrong answer as well as the ambiguity of the source language. Additional retrieved paragraphs can introduce irrelevant old program cycles, so more context can also create extra work for an editor. Record the setting selected for the review, not an assumed quality grade.
Separate citations from evidence
A citation is a route to a page; it is not proof that the cited paragraph supports every word in a model-written answer. Open the source and confirm the precise clause, year, applicant type, and effective date. Record the issuing organization and any limitations such as an invitation-only round. If a summary blends the requirements of two funding programs, reject that blend even when both pages are official. Keep a human-readable evidence note with a short paraphrase and the URL. Do not publish private applicant files as prompts or use a search snippet as evidence of rights, consent, or final program approval.
Compare settings without inventing a benchmark
A conceptual comparison could show low context exposing the key eligibility page, high context adding an appendix and an unrelated FAQ, and a human reviewer ultimately accepting one dated eligibility clause. Those are illustrative states, not measured output from three API calls. A real evaluation would use the same query set, timestamp, model, tool options, and rubric across settings, then check source relevance, citation accuracy, response completeness, and usage. Record missing evidence as a miss rather than automatically upgrading a longer answer. Model responses and public web pages change; a local result should never be turned into a universal performance claim.
Plan cost and privacy controls independently
The context-size option does not promise a precise number of tokens, source pages, or a guaranteed price tier. Review the latest vendor usage and pricing documentation, and measure actual API usage if budgeting a production workflow. Keep nonpublic grant narratives, donor lists, and contact details outside general web-search queries whenever possible. Redact identifying information and use approved internal retrieval for confidential attachments. If a reviewer needs an accurate public program rule, the search input can usually be written without disclosing an applicant name. Preserve the evidence register in the organization’s approved storage rather than assuming the model output is your retention system.
Publish the review conclusion, not the setting
Before an editor signs off, ask whether the source is official, the date matches the active application cycle, and the cited language actually resolves the question. Mark unresolved exceptions for direct confirmation with the program office. A report should state the source, what was verified, what remains unknown, and who is responsible for the final eligibility decision. Record search_context_size in internal methodology so another reviewer can reproduce the setup, but do not present it as an evidence badge. The illustrations here explain the workflow conceptually and do not reproduce actual search results or grant-provider screens.
How We Research
We reviewed OpenAI web search guide and OpenAI Responses create API and OpenAI API pricing, focusing on the exact API parameter, its documented scope, required configuration, and limitations. We drafted a hypothetical museum workflow from those references and illustrated it with original conceptual diagrams. We did not query a live customer environment, conduct API benchmarks, perform security tests, inspect visitor data, or verify any real grant, rights clearance, or release approval. Any numerical or before-and-after states in diagrams are explanatory, not measured outcomes. Availability, API versions, permissions, and costs may change; check the current provider documentation and your own organization’s policies before deployment.
Frequently Asked Questions
No. It controls the amount of web context made available to the model, not an exact page count, citation count, or factual accuracy.
Inside the web_search tool configuration in a supported Responses API request; it is not the top-level output token limit.
No. A narrow factual lookup may work well with low; evaluate completeness against the question and the primary source.
Not by itself. Confirm the current official policy and the applicant-specific conditions with an authorized reviewer.
Not precisely. Review current pricing and usage data; the setting does not fix the number of tokens or pages processed.