OpenAI tool-cost detail
This page answers the OpenAI file search pricing query directly. It keeps the current storage rate, tool-call rate, token exposure, and practical workload patterns in one source-linked view.
Cost anatomy
The pricing page gives you the base rates, but file search only becomes predictable once storage footprint, call volume, and token exposure are separated.
Workload examples
These examples use OpenAI's current rates and simple arithmetic so you can see where file search gets unexpectedly cheap, unexpectedly expensive, or just mis-estimated. They exclude model-token charges because those depend on the chosen model and retrieved context size.
| Scenario | Workload | Storage meter | Tool-call meter | Model token exposure | Decision read | Sources |
|---|---|---|---|---|---|---|
| Small internal knowledge helper | 0.8 GB active vector store for 30 days and 20K file-search calls during the month. | Storage stays inside the free 1 GB threshold: $0 | 20 x $2.50 = $50 | Model token spend still varies with prompt size and retrieved context, but the call meter is already the main line item. | For small knowledge bases, file search is usually a call-volume question before it becomes a storage question. | |
| Busy support copilot | 6 GB active vector stores for 30 days and 200K file-search calls during the month. | (6 GB - 1 GB free) x $0.10 x 30 days = $15 | 200 x $2.50 = $500 | Result count and response shape can still add token pressure on top of the call line. | When file search fires often, tool calls can dominate the bill long before storage becomes the biggest cost surface. | |
| Stale archive left online | 50 GB vector-store footprint kept active for 30 days, but only 2K file-search calls during the month. | (50 GB - 1 GB free) x $0.10 x 30 days = $147 | 2 x $2.50 = $5 | Token spend is low because calls are low, but storage keeps billing every day until the store expires or is deleted. | Quiet archives become storage-driven. If the data should cool off, expiration policy matters more than query optimization. |
Control levers
These are the controls OpenAI exposes today that materially change storage or token pressure without requiring a new architecture.
The retrieval guide says expired vector stores stop charging, and the vector-store API lets you anchor `expires_after` to `last_active_at`. This is the cleanest control for archives, temporary projects, and bursty analysis jobs.
OpenAI exposes `usage_bytes` directly on the vector-store object. That matters because billing is based on stored bytes, while the retrieval guide separately shows that files are chunked and indexed before search.
The file search guide explicitly says limiting results can reduce token usage and latency. This does not reduce tool-call count, but it can narrow the model-token line and reduce response bloat.
OpenAI documents default chunking at 800 tokens with 400-token overlap and allows chunking changes when files are added. That means indexing behavior is tunable, but the right check after tuning is still the resulting `usage_bytes` rather than an assumption.
Decision signals
Use these signals when deciding whether to keep file search in the path, add stronger controls, or price an alternative retrieval design.
If the application hits file search on most user turns, the $2.50 per 1K call line often grows faster than storage. Start by estimating invocation frequency before debating storage optimization.
Sources
When retrieval volume is low but vector stores stay online, the daily storage meter keeps running. Expiration policy and deletion hygiene matter more than prompt tuning in that case.
File search does not replace model pricing. OpenAI bills built-in tool tokens at the chosen model's per-token rates, so the same retrieval pattern can land very differently on a high-end versus low-cost model row.
Sources
Storage, tool calls, and model tokens move independently. If any estimate leaves one of them out, it is probably still a document skim rather than a real operating cost read.
Official sources
This page keeps the source set narrow so the cost brief can stay auditable instead of drifting into guesswork.
Source of record for the file search storage price, the Responses API tool-call price, the first free gigabyte, and the statement that built-in tool tokens are billed at model rates.
Shows that file search is a hosted tool in the Responses API, requires vector stores, and can reduce token usage by limiting the number of results.
Documents expiration policies that stop charges and the default chunking behavior used when files are indexed into vector stores.
Documents `usage_bytes`, `last_active_at`, and `expires_after`, which are the fields you need to inspect and control storage cost directly.
Continue the site
Use the groups below to move laterally through the decision, not back out into another doc hunt.
Related pages
Stay in the same decision neighborhood instead of backing out to search.
Model pricing, hosted-tool costs, and fit constraints that materially change the operating estimate.
Open pageTool-cost brief for web search pricing across standard and preview search paths.
Open pageTool-cost brief for code interpreter container runtime and how it stacks with model spend.
Open pageCompare pages
Open the pages that turn this topic into a side-by-side decision.
Replacement pages
Use the likely substitutes, migration targets, or fallback choices as the next click.
Source category pages
Trace the source families behind this page instead of opening random docs in isolation.