Web Search API and Web Fetch API: How They Work and What $0.01 Buys

Every major server-side web search tool now charges the same fee, $0.01 per search, and that number is the least interesting thing on the bill. The searches we metered attached 1,500 to 3,100 tokens of results to each request, those tokens bill at whatever model you route to, and what happens on the follow-up turn depends on a protocol design difference most teams never look at: whether the endpoint carries the search evidence forward, or quietly drops it and leaves the model to search again on your dime. We measured Synthorai’s synthorai:web_search and synthorai:web_fetch across four model families, then put the results against Anthropic’s and OpenAI’s published pricing for their own hosted search.

TL;DR

• The per-search fee is $0.01 across Synthorai, Anthropic, and OpenAI; billing records itemize it at $0.0100.
• One search injects 1,500-3,100 result tokens at the model’s input rate: on cheap models the fee dominates, on premium ones tokens take up to half.
• max_uses is a cap, not a quota: allowed 10, the model stopped at 3; fees scale with searches run.
• Turn two splits by endpoint: /v1/messages replays results (≈3,900 tokens, no new fee); /v1/chat/completions drops them, so a follow-up needing evidence buys a fresh search.

Why do models need web search and web fetch at all?

Because a model’s knowledge stops at its training cutoff, and most production questions do not. Prices, release notes, exchange rates, sports scores, the contents of the URL a user just pasted: none of it is in the weights, and confidently answering anyway is how hallucinated “current” facts ship to users. Web search closes the gap for discovery (the model does not know where the answer lives), web fetch closes it for reading (the model knows the exact page and needs its contents). You can build both yourself with a search API, a scraper, and a tool-calling loop, and teams do; the server-side versions exist because that loop is undifferentiated plumbing, and running it inside the provider removes the round-trips, the parsing code, and the operational surface, for a fee that turns out to be the same everywhere.

How does server-side web search actually work?

The loop runs inside one API request, and that is the whole trick. With client-side tools, the model asks your code to search, your code round-trips results back, and every hop re-sends the conversation. A server tool cuts your code out: you declare {"type": "synthorai:web_search"} in tools, the model emits a query, the gateway dispatches it to a dedicated search provider, injects the returned results into the model’s context, and the model reads them and answers (or searches again, up to max_uses). One request in, one response out, citations and the bill included.

Using it is one line in an ordinary request; no loop code, no callbacks:

curl https://synthorai.io/v1/chat/completions \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash-0731",
    "messages": [{"role": "user", "content": "What is one AI news headline from this week? Name the source."}],
    "tools": [{"type": "synthorai:web_search", "max_uses": 1}]
  }'

Web fetch is the same declaration with a different type; put the URL in the message and the gateway retrieves the page:

"messages": [{"role": "user", "content": "Fetch https://example.com/pricing and summarize the tiers."}],
"tools": [{"type": "synthorai:web_fetch", "max_uses": 1}]

The diagram traces the search request above exactly as we measured it on deepseek-v4-flash-0731. The meter read 2,059 input tokens (a 30-token question plus roughly 2,000 tokens of injected results), 169 output tokens, and $0.0104 total: $0.01 of search fee and about $0.0004 of tokens. Two billing events, and only two: the fee when the search runs, and the result tokens at the model’s ordinary input rate. A fetch bills identically, with the fetched page taking the place of the snippets.

The declaration itself costs nothing (a request that declares the tool but never searches bills zero fee), and the tool works on any model in the catalog, which is the structural difference from the first-party alternatives: Anthropic’s hosted search serves Claude models, OpenAI’s serves OpenAI models, and a gateway-level tool serves whatever you route to.

What does one search really cost?

$0.01 of fee plus a token bill that flips who dominates as the model gets pricier. We ran the same one-search news question three times each across four families, solved each model’s exact token rates from tool-free baselines, and read the fee as the residual:

On the cheapest model the search fee is 97% of the call; on premium models the injected tokens claim half the bill. The fee itself is not an inference: our billing records itemize the tool charge as its own line at exactly $0.0100 per call, alongside a separate count of tool-injected tokens (3,454 of the 3,836 input tokens on one fetch call, to pick a real row). Measured all-in, a single search landed between $0.010 and $0.012 depending on the model carrying it; budget the top of that band and you will not be surprised. The practical read: pairing server-side search with a cheap model makes the search itself the product, and the model almost free.

Which three dials set your token bill?

Search count, result length, and page weight; everything else is rounding. Each dial is directly measurable and two of the three are directly yours to set.

Dial one: how many searches run. max_uses is a ceiling, not a target. On a five-vendor pricing question, allowing 1, 2, and 3 searches billed $0.0106, $0.0216, and $0.0319, fees stacking linearly at $0.01 per search actually run; allowing 5 and even 10 changed nothing, because the model stopped at three searches on its own. Unused headroom is free, exactly like the thinking budgets we measured on reasoning models. The default is 3 with a hard cap of 10, so the unconfigured worst case on a search-happy question is three fees plus three result loads; pin max_uses: 1 on single-fact routes.

Dial two: how long the results run. Injection size follows the breadth of the question, not chance. Across twelve single-search runs on deepseek-v4-flash-0731:

Narrow questions pull compact result sets; comparative questions pull wide ones, about 45% heavier than a single fact. For budgeting, 2,000 tokens per search with a 20% band covers everything we saw, which at typical model rates prices the token side of one search between a twentieth and half of the $0.01 fee.

Dial three: how heavy the fetched page is. The fetch fee never moves; the page decides the rest. Our ladder, all through the same model:

On a cheap model even the Wikipedia article is a cent and a half; route the same fetch through a $2-per-million model and that one page costs six and a half cents, five times the fee. One supporting fact for the budget sheet: the same page tokenizes differently per model family. The data-heavy post was 5,196 tokens on DeepSeek and 5,508 on qwen3.8-max, a 6% tokenizer premium consistent with our density measurements.

What happens to search results on the next turn?

The split is a design difference between the two API protocols themselves, and it decides your follow-up bill. The /v1/messages protocol defines an assistant turn as a list of content blocks, so server-tool activity is part of the turn’s official record: the response carries server_tool_use, web_search_tool_result, then text, and the protocol expects those blocks back on the next turn. The evidence rides forward as input tokens by design. The /v1/chat/completions protocol defines an assistant message as a single content string with no slot for server-tool results, so injected results are absorbed server-side; only the visible answer enters history, and the evidence is gone.

We ran the same search-then-follow-up pair on claude-sonnet-5 through both surfaces. Via /v1/messages, the follow-up billed 3,911 input tokens and $0.0109, all of it token cost: no new search, because the model still had the results to draw on. Via /v1/chat/completions, the follow-up billed $0.0204, more than the replay, because the model, holding nothing but its own one-line summary, ran a fresh search: a new $0.01 fee plus a new result load. And the re-search is a choice, not a law: an earlier run of the same absorbed-style follow-up on deepseek-v4-flash-0731 answered straight from its summary at 460 input tokens and $0.00009. Absorption makes your follow-up bill bimodal: nearly free when the summary suffices, fee-plus-load when the model decides it needs the web again.

So the honest framing is not that one endpoint is cheaper; it is that they move the cost to different places. The block style pays a predictable token toll each turn and never re-buys evidence it already has; the absorbed style bets that follow-ups will not need the evidence, and pays a fresh fee whenever the bet loses. High-turn chat with shallow follow-ups suits /v1/chat/completions; research agents that interrogate sources suit /v1/messages, where the prompt-cache layering discipline applies to carried results like any other bulky context.

What do Anthropic and OpenAI charge, and where do their tools run?

The comparison is short: everyone charges $0.01 per search, and after that the bill is just your model’s token price. Anthropic bills $10 per 1,000 searches with results as input tokens (and its web fetch is fee-free, tokens only); OpenAI bills the same $10 per 1,000 calls with token treatment varying by model tier. The fee is settled; the model’s input rate on 1,500-3,100 injected tokens is the variable.

The row that actually separates the three is not on the price sheet: it is where the tools run. First-party server tools are built for their vendors’ own agent stacks and stay on first-party surfaces: Anthropic’s docs state web search is not available on Amazon Bedrock, only basic search reaches Google Cloud, and Microsoft Foundry requires a hosted-on-Anthropic deployment; web fetch skips Bedrock and Google Cloud entirely. OpenAI’s search is bound to its Responses API. Move your workload across a cloud boundary or a model family and the first-party tool stays behind, which is also why a gateway does not pass those tools through: they cannot follow the traffic. A gateway-level tool takes the opposite trade: one declaration that survives both a model swap and a platform move.

FAQ

How much does the web search API cost per request?

$0.01 per search executed, itemized as its own line in the billing records, plus the injected results billed as input tokens at your model’s rate (1,500-3,100 tokens per search in our runs). A request that declares the tool but never searches bills no fee. Budget $0.010-0.012 all-in per search on typical models; on very cheap models the fee is 97% of the total.

Do search results get re-billed on later conversation turns?

Depends on the endpoint. Via /v1/messages the result blocks replay with history (about 3,900 input tokens per turn in our runs) and no new fee accrues. Via /v1/chat/completions results are absorbed after the turn; the follow-up is nearly free if the model answers from its summary ($0.00009 in one run) but incurs a fresh fee and result load if it re-searches ($0.0204 in another). Anthropic’s first-party search documents the replay behavior as standard; there, results re-bill every turn.

How do I cap web search spend on a request?

max_uses. It is a hard ceiling the model cannot exceed (default 3, cap 10), fees scale only with searches actually executed, and unused headroom is free. For single-fact routes, max_uses: 1 bounds the worst case at one fee plus one result load.

When should I use web fetch instead of web search?

Fetch when you already know the URL and want the full page; search when you need discovery. Both cost $0.01 per use through the gateway, but a fetch injects the entire page (209 tokens for a minimal page up to 27,380 for a long article in our ladder) while a search injects snippets from several sources. For read-and-summarize pipelines on Claude models specifically, Anthropic’s own fetch tool is fee-free and cheaper.

Measured 2026-08-10 through the Synthorai gateway using synthorai:web_search and synthorai:web_fetch on deepseek-v4-flash-0731, gpt-5.6-luna, qwen3.8-max, and claude-sonnet-5: per-model token rates solved from tool-free two-point baselines, search fees read as billed-cost residuals over token value (n=3 per model), a max_uses ladder, a query-type result-load sweep (4 types x 3 runs), follow-up-turn probes on both endpoints with identical questions, and a five-page fetch ladder (three of our own pages plus a minimal external page and a long article). Fees were confirmed against itemized billing records (per-call tool-charge and tool-injected-token lines), not inferred from totals alone. Anthropic and OpenAI figures are their published docs rates at publication time. The diagram’s numbers are one unedited measured call. Fees and behavior may change; verify against your own usage records.

← Back to blog