Abstract. Anthropic's own documentation says the quiet part in one sentence: web search results "are counted as input tokens, in search iterations executed during a single turn and in subsequent conversation turns." Source: Claude Platform Docs, "Web search tool." That single line is why one developer's three-search question about recent AI infrastructure funding rounds billed 232,015 input tokens on claude-sonnet-4-6, almost all of it search-result content that got re-sent, and re-billed, on every later turn of the same conversation. Source: Firecrawl, "4 Anthropic Web Search Alternatives for AI Agents in 2026." Web search went from an opt-in RAG step teams built by hand to a tool every major agent framework calls by default in 2026, and the pricing model underneath it rewards exactly the pattern agents are built to do: search once, then keep that context around for the rest of the run. This post works through what web search actually bills you for across the two biggest providers, the fix Anthropic already shipped for it, and where a quality-floor router fits once the expensive part, the search itself, is already paid for. What "web search" actually bills you for. Both Anthropic and OpenAI charge for the tool call itself, separately from the tokens it produces. Anthropic's web search tool costs $10 per 1,000 searches, plus standard token costs for whatever content the search returns. Source: Claude Platform Docs, "Web search tool." OpenAI runs two tiers on the same idea: the standard web search tool is $10 per 1,000 calls plus search-content tokens billed at the model's normal input rate, while the non-reasoning web search preview charges $25 per 1,000 calls but includes those content tokens for free. Source: OpenAI, API pricing documentation, September 2026. Neither number is the actual bill. The actual bill is whatever ends up sitting in the context window after the search runs, and that depends on how many results came back, how long the pages were, and how many turns the conversation runs for afterward. That last part is the mechanism most teams miss. A search result isn't a one-time charge the way the search call itself is. Once Claude or GPT pulls a page's content into context to answer a question, that content is still in context on the next turn, and the one after that, billed again as input tokens each time, unless something actively removes it. Source: Claude Platform Docs, "Web search tool." An agent that runs ten turns after a single search pays for that search's results roughly ten times, not once. One search, 232,015 tokens. The number gets concrete fast. A developer building an agent that answers questions about AI infrastructure funding gave claude-sonnet-4-6 a question that took three searches to resolve. The single turn came back at 232,015 input tokens, almost entirely search-result content that Anthropic's API had loaded into context with no caching applied. Source: Firecrawl, "4 Anthropic Web Search Alternatives for AI Agents in 2026." At current Claude pricing, that's not a rounding error on the invoice. It's the invoice, for what looked to the end user like one ordinary question. The root cause isn't a bug. It's the tool working as documented: three searches ran, each returned full page content, and all of it landed in context because nothing told the model to keep only the part it actually needed. Multiply that by a multi-turn agent loop, the pattern every coding agent, research agent, and support bot is built around in 2026, and one well-intentioned "let me look that up" becomes the most expensive line in the conversation. The double-synthesis tax hiding inside "integrated" search. There's a second cost layered on top of the first, and it shows up specifically in tools marketed as fully managed. When a provider's own model reads the raw search results and writes a synthesized answer before handing anything back, and your application's model then reprocesses that synthesized answer to fold it into its own response, you're paying for two passes over the same information instead of one. Ten search results with snippets routinely run 2,000 to 3,000 tokens before the user's actual question is even in context. Source: AiBrain, "LLM Grounding in 2026: Options, Hidden Costs, and Risks." A separate search API paired with your own retrieval step avoids the double pass, at the cost of more code to own and maintain. An integrated tool call is less code and less control, and the difference in cost between the two approaches is the price of that convenience. | Approach | Search cost | Content tokens | Who controls filtering | |---|---|---|---| | Anthropic web_search (basic) | $10 / 1,000 searches | Billed at standard input rate, every turn it stays in context | Claude, none by default | | OpenAI web_search (standard) | $10 / 1,000 calls | Billed at model input rate | You, via prompt and truncation | | OpenAI web search preview (non-reasoning) | $25 / 1,000 calls | Included, no separate charge | Not exposed | | Separate search API + your own RAG step | Roughly $1 to $5 / 1,000 queries | Whatever you choose to pass in | You, fully | Source: Claude Platform Docs, "Web search tool." Source: OpenAI, API pricing documentation, September 2026. Source: AiBrain, "LLM Grounding in 2026," on typical classic search API rates. Anthropic already shipped a fix. Most teams haven't turned it on. To be fair to Anthropic, the company documented the problem and then addressed it. Tool version web_search_20260209 and later add dynamic filtering: instead of loading every search result straight into the context window, Claude writes and runs code that filters the results first, keeping only what's relevant to the actual question and discarding the rest before any of it is billed as context. Source: Claude Platform Docs, "Web search tool." It's available on Claude 4.6 and later models and on Claude Mythos Preview, and it runs through code execution automatically, with no separate charge for that code execution step beyond standard token costs. A second lever shipped with web_search_20260318: response_inclusion. Set it to "excluded" and the API drops the nested search-result blocks from what gets echoed back to your client once code execution has already consumed them, which cuts output token costs specifically on agentic workflows that never needed to display raw search content to a user in the first place. Source: Claude Platform Docs, "Web search tool." Both are opt-in. The original web search tool, web_search_20250305, still loads everything into context, and plenty of production integrations are still pinned to it because nobody has gone back to bump the tool version since the integration first shipped. Where routing fits once the search is already paid for. The search call and the tokens it drags into context are a fixed cost by the time your model sees them. What's still a choice is which model answers the question once those tokens are sitting in context. Reading three search results and stating what they say is a narrower task than the reasoning that decided a search was needed in the first place, and it's exactly the kind of grounded, closed-context task a smaller model handles at the same quality as a flagship one. import openai client = openai.OpenAI( base_url="https://api.getnadir.com/v1", api_key="ndr_...", ) The web search tool already did the expensive part: N queries, their results now sitting in context as input tokens that get billed again on every later turn. What's left is synthesis over text the model already retrieved, not the reasoning that decided to search, so it's a call the router can send to the cheapest model that clears the quality floor instead of defaulting to whatever model handled the turn that triggered the search. response = client.chat.completions.create( model="auto", messages=[ {"role": "user", "content": prompt_with_search_results_in_context}, ], ) Cost is reported per call, so a 232,000-token search turn shows up as its own line on the very next response instead of surfacing three weeks later on an invoice. model_used = response.model cost = response.model_extra["nadir_metadata"]["cost"]["total_cost_usd"] Nadir doesn't change what the search tool charges. It changes what happens to the tokens the search leaves behind: the synthesis call gets priced and routed against your quality floor like any other request, instead of inheriting whatever model handled the turn that triggered the search. What to check before you turn web search on by default. Bump the tool version. If you're on Claude 4.6 or later, web_search_20260209 gives you dynamic filtering at no extra charge beyond standard tokens. Staying pinned to web_search_20250305 out of habit means paying for every token of every result, filtered or not. Set response_inclusion: "excluded" on web_search_20260318 and later for agent loops that don't display raw search content to an end user. It's an output-token cut with no downside for that use case. Set max_uses deliberately. Simple factual questions typically run one to three searches. Comparative or multi-entity questions can run ten or more, and the difference compounds on every turn those results stay in context. Source: Claude Platform Docs, "Web search tool." Watch turn count, not just search count. A single search's tokens get re-billed on every subsequent turn, so a ten-turn agent loop pays for one search roughly ten times over, not once. Don't route the answer to your most expensive model by default. Deciding to search is a judgment call. Answering from what the search returned is closer to reading comprehension, and it's a call a cheaper model can usually clear. Web search stopped being a special-case tool the moment every major agent framework wired it in as a default capability. The pricing model underneath it hasn't caught up to that shift, and until it does, the gap between "the search cost ten cents" and "the conversation that used that search cost four dollars" is exactly the gap a filtered, deliberately-scoped search call and a quality-floor router are built to close. Related reading Your RAG pipeline fetches 20 chunks per query. The model reads 3. The other 17 are billed in full. Deep research agents run a 5-to-100x price spread for the same feature, gated by a manual mode switch nobody automated. A browser agent reads a page as a six-figure-token accessibility tree before it clicks anything. Context engineering is not prompt engineering. The overcaching tax: what "don't break the cache" costs when nobody reads the cached tokens again. Sources: Claude Platform Docs, "Web search tool." OpenAI, API pricing documentation, September 2026. Firecrawl, "4 Anthropic Web Search Alternatives for AI Agents in 2026." AiBrain, "LLM Grounding in 2026: Options, Hidden Costs, and Risks." Nadir has not independently verified the 232,015-token figure or the third-party search-API rate estimates cited above beyond the primary vendor documentation linked.