Claude schreibt Python, um sich selbst beim Suchen zu helfen — und das ist relevanter als es klingt
Anthropic's Dynamic Filtering für Web Search ist kein Marketing-Feature. Es löst ein strukturelles Problem von agentic AI und gibt uns einen Hinweis, wohin sich die Tool-Architektur entwickelt.
Am 17. Februar hat Anthropic leise ein technisches Detail veröffentlicht, das mehr Aufmerksamkeit verdient als es bekam: Claude kann jetzt während einer Websuche selbst Code schreiben und ausführen, um die Suchergebnisse zu filtern — bevor sie überhaupt den Kontext-Window erreichen.
Klingt nach einem Implementierungsdetail. Ist es aber nicht.
Das strukturelle Problem mit Web Search in LLM-Agents
Wer schon mal einen Agenten mit Web-Suche gebaut hat, kennt das Problem: Du schickst eine Anfrage, der Agent sucht, bekommt rohe HTML-Dateien von drei bis fünf Webseiten zurück — und all das landet im Kontext. Irrelevant oder nicht.
Das führt zu zwei Problemen gleichzeitig:
- Qualitätsverlust: Mehr Rauschen im Kontext = schlechtere Antworten
- Tokenkosten: Vollständige HTML-Seiten fressen Input-Budget
Das war der Status quo. Die übliche Lösung war: mehr Kontext-Window. Die eigentliche Lösung wäre: besseres Filtern.
Was Dynamic Filtering macht — und warum das anders ist
Anthropic's Antwort ist konzeptuell interessant: Statt Claude mehr Kontext zu geben, lässt man Claude Code schreiben, der die Ergebnisse vor dem Einlesen filtert.
In der Praxis bedeutet das: Claude generiert ad-hoc Python, das die geholten Seiten durchsucht, die relevanten Teile extrahiert und den Rest verwirft. Erst dann landet der reduzierte Inhalt im Kontext.
Das ist keine RAG-Pipeline, kein statischer Extraktionsregex, kein hardcodiertes Preprocessing. Es ist situationsabhängige, selbstgeschriebene Filterlogik — pro Query unterschiedlich.
Quora's Poe hat das intern evaluiert und beschreibt es treffend: Das Modell verhält sich wie ein echter Researcher, der Python schreibt, um Ergebnisse zu parsen, zu filtern und gegenzuchecken — statt rohe HTML-Blöcke in den Prompt zu laden ¹.
Die Benchmark-Zahlen
Anthropic hat auf zwei Benchmarks evaluiert ¹:
BrowseComp (OpenAI, 2025) ² — testet, ob ein Agent viele Websites durchsuchen kann, um eine spezifisch schwer auffindbare Information zu finden:
| Modell | Ohne Filtering | Mit Filtering |
|---|---|---|
| Sonnet 4.6 | 33.3% | 46.6% (+13.3 Punkte) |
| Opus 4.6 | 45.3% | 61.6% (+16.3 Punkte) |
DeepsearchQA (Google DeepMind, 2025) ³ — testet multi-step Research mit vielen gesuchten Antworten (F1-Score):
| Modell | Ohne Filtering | Mit Filtering |
|---|---|---|
| Sonnet 4.6 | 52.6% | 59.4% (+6.8 Punkte) |
| Opus 4.6 | 69.8% | 77.3% (+7.5 Punkte) |
Durchschnitt: +11% Genauigkeit bei -24% Input-Token.
Eine Caveat bei den Kosten: Output-Tokens können steigen, weil der generierte Filter-Code selbst Token kostet. Bei Opus 4.6 stiegen die gewichteten Token-Kosten auf DeepsearchQA sogar leicht an — was bei einem teureren Modell spürbar sein kann. Evaluierung gegen eigene Production-Queries ist also empfohlen ¹.
Was das für die Tool-Architektur bedeutet
Das eigentlich Interessante ist nicht das Feature selbst, sondern was es über die Richtung von agentic AI aussagt.
Bisher dachten wir in statischen Tool-Definitionen: Ein Tool macht X, liefert Y. Der Agent ruft Tools auf und verarbeitet deren Output im Kontext.
Dynamic Filtering verschiebt das Modell: Der Agent schreibt situationsabhängig Code, der zwischen Tool-Output und Kontext-Einlesen läuft. Das Tool-Ergebnis ist nicht mehr der Endpunkt — es ist der Rohstoff für eine dynamisch generierte Verarbeitungslogik.
Das passt zu Anthropic's breiterem Push in diesem Release: Code Execution, Programmatic Tool Calling, Tool Search — alles zielt darauf ab, dass Agents weniger passiv konsumieren und aktiver verarbeiten, bevor etwas den Kontext erreicht ¹.
Das reduziert nicht nur Kosten. Es reduziert fundamentale Schwächen der "alles im Kontext" Architektur.
Verfügbarkeit und Setup
Das neue Tool (web_search_20260209) ist ab sofort auf der Claude API verfügbar, standardmässig aktiviert für Sonnet 4.6 und Opus 4.6 ⁴:
const response = await anthropic.messages.create({
model: "claude-opus-4-6",
max_tokens: 4096,
messages: [{ role: "user", content: "..." }],
tools: [{ type: "web_search_20260209", name: "web_search" }]
})
Voraussetzung: Dynamic Filtering benötigt das Code Execution Tool — es läuft on-demand im Anthropic-Sandbox und ist Zero Data Retention (ZDR) kompatibel. Auf Google Vertex AI ist nur das ältere Tool ohne Filtering verfügbar.
Das alte Tool (web_search_20250305) bleibt weiterhin verwendbar.
Fazit
Dynamic Filtering ist kein Flagship-Feature, das auf der Homepage glänzt. Es ist eine architektonische Entscheidung: Lass den Agenten die Arbeit tun, für die er gemacht ist — nicht nur reagieren, sondern aktiv verarbeiten.
Die +11% Genauigkeit bei -24% Token-Verbrauch sind für produktive Deployments real meaningful. Wer Agenten mit Web-Suche baut, sollte web_search_20260209 evaluieren — die Upgrade-Kosten sind minimal, das Upside ist messbar.
Quellen:
¹ Anthropic Blog — "Improved Web Search with Dynamic Filtering" (Feb 17, 2026): claude.com/blog/improved-web-search-with-dynamic-filtering
² OpenAI BrowseComp Benchmark Paper (2025): cdn.openai.com/pdf/…/browsecomp.pdf
³ Google DeepMind DeepSearchQA Benchmark (2025): storage.googleapis.com/…/DeepSearchQA_benchmark_paper.pdf
⁴ Claude API Dokumentation — Web Search Tool: platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool