Claude Web Search Tool - Dynamic Filtering for Smarter AI Agents

When you're building AI agents that need to answer questions about real-world, current information, you hit a fundamental problem. The language model's training data has a cutoff date. It doesn't know today's stock prices, this week's policy changes, or the latest version of a software library. You need to give it access to the web.

Anthropic's web search tool for Claude handles this. It's a server-side tool that lets Claude search the web, read results, and incorporate current information into its responses with proper citations. That's useful on its own. But the latest version - web_search_20260209 - adds something genuinely interesting: dynamic filtering.

What Dynamic Filtering Actually Does

The basic web search workflow is straightforward. Claude decides it needs to search, sends a query, gets results back, reads the pages, and synthesises an answer. The problem? Web pages are large. A single documentation page might be 50KB of HTML. Multiply that by the five or ten pages Claude reads per search, and you're pushing hundreds of thousands of tokens through the context window. Most of that content is irrelevant - navigation menus, sidebars, footers, unrelated sections.

Dynamic filtering changes this. Instead of dumping raw HTML into the context window, Claude writes and executes code to filter search results before they enter context. It keeps the relevant paragraphs and discards the rest.

The practical effect: more accurate answers with fewer tokens consumed. That's a cost saving and a quality improvement at the same time, which isn't something you get to say very often.

When This Matters

For basic Q&A agents - "What's the weather in Sydney?" - basic web search is fine. The answer is short, the context needed is minimal.

Dynamic filtering becomes valuable when:

• Technical documentation searches. Your agent needs to find a specific configuration option buried in a 200-page docs site. Without filtering, Claude ingests the entire page. With filtering, it extracts just the relevant section.
• Research tasks. Literature reviews, citation verification, competitive analysis. These tasks involve reading many pages and extracting specific facts from each one.
• Response grounding. When you need Claude to verify its claims against current sources, filtering ensures it's checking the right parts of those sources rather than getting lost in irrelevant content.

We've been using this with AI agent builds for clients, particularly for agents that need to stay current with regulatory changes, market data, or technical specifications. The difference in response quality when filtering is active is noticeable.

How to Enable It

The implementation is simple. You add the tool to your API request with the newer tool version:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "What are the current Azure AI Foundry pricing tiers for GPT-4o?",
        }
    ],
    tools=[{"type": "web_search_20260209", "name": "web_search"}],
)

That's it. No additional configuration needed. Claude will automatically use dynamic filtering when it decides a search would benefit from it.

The older tool version (web_search_20250305) still works if you want basic web search without filtering. But for most use cases, the newer version is strictly better.

One requirement: dynamic filtering needs the code execution tool to be enabled, because Claude writes and runs code to perform the filtering. If code execution isn't available, the tool falls back to basic web search behaviour.

Supported Models

Dynamic filtering works with:

• Claude Opus 4.7
• Claude Opus 4.6
• Claude Sonnet 4.6
• Claude Mythos Preview

For Mythos Preview, web search is available on the Claude API, Microsoft Foundry, and Google Vertex AI, but not Amazon Bedrock.

The basic web search tool (without dynamic filtering) has broader model support.

What Happens Under the Hood

When Claude decides to search:

1. It formulates a search query based on the conversation context
2. The API executes the search and returns results
3. With dynamic filtering, Claude writes a short script to extract relevant content from the results
4. The filtered content enters the context window
5. Claude may repeat this process multiple times in a single turn (searching, filtering, searching again with refined queries)
6. It produces a final answer with citations

The citations part is worth emphasising. Claude includes source URLs in its response, so you can verify the information and your end users can follow the links. This matters for enterprise applications where "the AI said so" isn't a sufficient answer.

Multiple Language SDK Support

The web search tool works across all the Anthropic SDKs. Here's what the setup looks like in TypeScript:

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic();

const response = await anthropic.messages.create({
    model: "claude-opus-4-7",
    max_tokens: 4096,
    messages: [
        {
            role: "user",
            content: "Find the latest changes to Australian privacy legislation in 2026"
        }
    ],
    tools: [{ type: "web_search_20260209", name: "web_search" }]
});

There are also official examples for Go, Java, C#, PHP, and Ruby. The tool specification is identical across all SDKs - you just pass the tool type and name.

Token Cost Implications

This is where it gets interesting from a business perspective. Web search is already one of the most token-intensive operations an AI agent can perform. A single search might pull in 100,000+ tokens of raw web content. At current pricing, that adds up fast if your agent is handling thousands of queries per day.

Dynamic filtering typically reduces the content that enters context by 60-80%, based on what we've seen in our deployments. That's a direct cost reduction. And because the remaining content is more relevant, Claude produces better answers on the first attempt rather than needing follow-up searches to find what it missed.

For organisations building AI-powered customer service agents or research assistants that handle high query volumes, this cost reduction matters.

Building It Into Your Agent Architecture

A few patterns we've found work well:

Search-then-verify. Have your agent answer from its training data first, then use web search to verify and update its answer. This reduces unnecessary searches for questions where the training data is sufficient.

Scoped searches. Include domain restrictions in your system prompt. If your agent only needs to search government websites or specific documentation sites, tell it. This reduces irrelevant results and makes filtering more effective.

Citation requirements. Include an explicit instruction that the agent must cite sources for any claim that comes from web search. This turns "the AI said" into "the AI found this at [URL]", which is much more useful for enterprise applications.

Fallback handling. Web search can fail - the site might be down, the content might be behind a paywall, the search might not return relevant results. Build error handling that gracefully falls back to the model's training data with a clear disclaimer.

What It Doesn't Do

A few limitations to be aware of:

• Web search can't access authenticated content. If the information is behind a login, the search won't reach it. For those cases, you need custom tools that authenticate with the specific service.
• Search quality depends on public web content. If the information doesn't exist on the public web, Claude won't find it.
• Dynamic filtering is code execution, which adds a small amount of latency to each search. For latency-sensitive applications, this trade-off might matter.

Zero Data Retention

For organisations with strict data handling requirements, there's a Zero Data Retention option. The details are in Anthropic's documentation on server tools, including the allowed_callers workaround for ZDR eligibility. This matters for financial services and healthcare clients who need to ensure search queries and results aren't retained.

Our Take

Web search is one of those tools that sounds simple but changes what AI agents can do in practice. Without it, your agent is limited to what it learned during training. With it, your agent can answer questions about things that happened yesterday.

Dynamic filtering makes it practical at scale. Without filtering, the token costs and quality issues make high-volume web search expensive and unreliable. With filtering, you get better answers for less money. That's a straightforward win.

If you're building AI agents that need real-time information - and most enterprise agents eventually do - the web search tool should be part of your architecture from the start. We help Australian businesses design and build AI agent systems on Claude and other platforms. Get in touch if you'd like to discuss how web search fits into your use case.

For the complete API reference and additional examples, see the Claude web search tool documentation.