Playwright MCP: Token-Kosten vs. Webseiten als Markdown lesen
Wir haben den echten Playwright-MCP-Server und FastAF-Markdown über 11 öffentliche Seiten laufen lassen und Tokens gezählt. Median: 9.874 gegen 5.083, mit Ausreißern in beide Richtungen.
Ein Seitenabruf über Playwright MCP kostet in unserem Test im Median 9.874 Tokens, gegen 5.083 für dieselben Seiten als Markdown von FastAF. Das ist etwa das Doppelte an Tokens, nicht das Hundertfache. Die Streuung ist allerdings groß: von 0,4x bei einer Seite bis 4x bei einer anderen. Wir haben am 19. Oktober 2026 11 öffentliche Seiten mit @playwright/mcp 0.0.83 gemessen und die Tokens mit tiktoken o200k_base gezählt.
Eine reproduzierbare Messung pro Seite zu Playwright MCP haben wir nicht gefunden, also haben wir selbst eine gemacht. Methode und Skript stehen unten, ebenso die Fälle, in denen der Browser das richtige Werkzeug ist.
Wie viele Tokens braucht Playwright MCP pro Seite?
Wir haben den echten Server gestartet (@playwright/mcp 0.0.83, zu diesem Datum die neueste Version auf npm, mit Playwright 1.64 alpha), headless über stdio, mit dem offiziellen MCP-Python-SDK als Client. Für jede Seite rief der Client browser_navigate und danach browser_snapshot auf, und wir zählten jedes Zeichen, das das Modell bekommen hätte. In 0.0.83 liefert browser_navigate nur einen Link auf eine Snapshot-Datei (78 bis 168 Tokens), das Lesen der Seite braucht also den zweiten Aufruf. Die andere Seite war FastAF /v1/scrape mit formats=markdown, zuerst einfach und mit dynamic=true nur, wenn der einfache Aufruf scheiterte oder die Prüfphrasen fehlten.
„Hat funktioniert” heißt: Zwei vorab festgelegte Phrasen waren in dem enthalten, was das Modell gesehen hätte. Die Tokens stammen aus Lauf 1 von 3 und umfassen Navigate plus Snapshot.
| Seite | Roh-HTML | Playwright-Snapshot | Playwright --mobile |
FastAF-Markdown |
|---|---|---|---|---|
| MDN, Fetch API (Docs) | 41.439 | 7.481 | 6.367 | 4.110 |
| Python-Docs, asyncio-Tasks (lange Docs) | 50.276 | 34.405 | 33.354 | 15.236 |
| Guardian-Artikel (News) | 101.462 | 6.343 | 6.129 | 3.585 |
| IKEA-Bücherregal BILLY (Produkt) | 336.714 | 10.017 | 7.812 | 5.092 |
| Wikipedia, Model Context Protocol | 79.923 | 24.931 | 3.864 (eingeklappt) | 21.784 |
| GitHub, python-sdk (Repo) | 135.152 | 9.874 | 6.807 | 5.083 |
| crates.io, serde (JS-gerenderte App) | n/a (404) | 4.693 | 4.767 | 1.408 (5 Credits) |
| Hacker-News-Startseite (Liste) | 11.694 | 13.649 | 13.649 | 3.365 |
| Anthropic-Engineering-Blogbeitrag | 51.697 | 11.689 | 11.447 | 6.115 |
| PyPI, requests (Paket) | 73.730 | 7.931 | 4.840 (dünn) | 20.165 |
| GOV.UK Mehrwertsteuersätze | 19.415 | 3.378 | 3.337 | 1.392 |
| Median, 11 Seiten | 51.697 | 9.874 | 6.367 | 5.083 |
| Summe, 11 Seiten | 901.502 | 134.391 | 102.373 | 87.335 |
„Roh-HTML” ist ein einfacher GET, zur Einordnung der Größe. crates.io lieferte darauf eine 404-Hülle. Die Zeiten lagen dicht beieinander: Eine warme Playwright-Seite brauchte im Median 0,5 s (der erste Aufruf nach dem Start addierte 0,4 bis 0,9 s), und FastAF im Median 0,5 s über drei Läufe, mit dynamischem Rendering bei 6 bis 7 s. Die Token-Zahlen von Playwright änderten sich zwischen den Läufen um unter 2 %, außer beim Guardian (5.671 bis 6.343) und bei der GitHub-Seite (9.376 bis 9.874). Die Ausgabe von FastAF für Wikipedia lag in zwei Aufrufen bei 21.784 Tokens und in zwei anderen bei 9.513, nimm diese Zeile also als Spanne.
Warum ist ein Snapshot größer als Markdown?
Ein Snapshot ist ein YAML-Accessibility-Baum. Jeder Knoten trägt eine Rolle, eine Verschachtelungsebene und eine [ref=...]-ID, damit der Agent ihn anklicken kann, und jeder Link verbraucht eine Zeile für sein - /url:-Ziel. Allein die URL-Zeilen machten über alle Seiten 18 % der Snapshot-Tokens aus (9 % bei den Python-Docs, 25 % bei Hacker News). Hacker News ist der klarste Fall: Sein Tabellenlayout wird zu table > rowgroup > row > cell, mehrere Ebenen tief, bevor die erste Story kommt, und der Snapshot ist 4x so groß wie das Markdown.
Markdown hat keine Refs und kaum Struktur, textlastige Seiten fallen deshalb etwa 2x kleiner aus. Zwei Seiten folgten diesem Muster nicht. Das Markdown von PyPI (20.165) behielt die ganze Seite einschließlich Dateiliste und Klassifikatoren, der Snapshot (7.931) nicht. Das Markdown von Wikipedia lag innerhalb von 13 % des Snapshots. Ehrlich zusammengefasst: Der Snapshot ist auf den meisten Seiten etwas größer, und die Struktur ist das, wofür du zahlst, aber eine Seite mit viel Text kann als Markdown mehr kosten.
Was kostet das in Dollar?
Die Preisseite von Anthropic listet Claude Sonnet 5.5 mit 2 $ pro Million Input-Tokens und Claude Fable 5.1 mit 10 $ (beides Stand 19. Oktober 2026, Preisseite). Unsere Zählungen nutzen einen OpenAI-Tokenizer, die Zahlen von Claude selbst weichen also etwas ab; die Verhältnisse sind das, dem man trauen kann. Bei der Median-Seite:
| Pro 1.000 Seitenabrufe | Tokens | Sonnet 5.5 Input | Fable 5.1 Input |
|---|---|---|---|
| Roh-HTML | 51,7 Mio. | 103,39 $ | 516,97 $ |
| Playwright-MCP-Snapshot | 9,9 Mio. | 19,75 $ | 98,74 $ |
Playwright MCP, --mobile |
6,4 Mio. | 12,73 $ | 63,67 $ |
| FastAF-Markdown | 5,1 Mio. | 10,17 $ plus 1.000 Credits | 50,83 $ plus 1.000 Credits |
Beim Starter-Paket (10 $ für 20.000 Credits) kosten 1.000 einfache Scrapes 0,50 $, FastAF landet bei Sonnet also bei etwa 10,70 $ gegen 19,75 $ für den Snapshot. Das ist etwa die Hälfte, und es betrifft nur den Input. Ein Seitenabruf bleibt außerdem in jedem späteren Turn im Kontext, solange du ihn nicht cachst oder verwirfst, ein langer Lauf zahlt ihn also mehr als einmal. Tool-Definitionen sind ein fester Posten pro Session: Playwright MCP listet 25 Tools (5.250 Tokens), der FastAF-MCP-Server 15 (3.831).
Lässt sich Playwright MCP günstiger machen?
Ja, und das README des Pakets sagt das selbst: Es empfiehlt für Coding-Agenten die Playwright CLI mit Skills, weil sie Accessibility-Bäume aus dem Kontext des Modells heraushält. Innerhalb von MCP senkte das Flag --mobile (dokumentiert als Token-Sparer) den Median hier von 9.874 auf 6.367. Es hat einen Haken. Bei Wikipedia sank es von 24.931 Tokens auf 3.864, weil das mobile Layout Abschnitte einklappt: 1 Absatz im Snapshot statt 22. Bei PyPI verlor es das Lizenzfeld und fiel durch unsere Prüfung. Lies einen kleineren Snapshot nicht als denselben Inhalt.
Weitere Stellschrauben stehen in der Tool-Liste, und wir haben sie nicht gemessen: browser_find liefert passende Knoten mit Kontext statt des ganzen Baums, browser_snapshot nimmt depth und filename, und browser_navigate schreibt schon jetzt in eine Datei statt in den Chat. Wenn du weißt, welchen Teil der Seite du brauchst, schlagen diese jeden Abruf der ganzen Seite.
Wann ist der Browser das richtige Werkzeug?
Wenn die Aufgabe Interaktion ist: durch eine Oberfläche klicken, ein Formular ausfüllen, ein Ablauf hinter einem Login, der dir gehört, eine Seite, bei der der nächste Schritt davon abhängt, was der letzte Klick bewirkt hat. Dafür gibt es die Refs im Snapshot, und Markdown hat nichts zum Anklicken.
Wir haben auch eine Stack-Overflow-Frage probiert und aus der Tabelle gelassen: Sie antwortete mit einer Bot-Prüfseite (HTTP 403), und FastAF lieferte 400 und 422 target_unavailable ohne Berechnung. Die Bot-Prüfungen einer Seite sind Sache ihres Betreibers; FastAF liest öffentliche Seiten und versucht nicht, daran vorbeizukommen, und wir haben keine Tools dagegen gemessen.
JavaScript-Apps sind der Mittelfall. Bei crates.io war der erste Playwright-Snapshot 35 Tokens groß, weil die App noch nicht geladen war; ein zweiter nach einer Wartezeit ergab 4.693. Der einfache Aufruf von FastAF lieferte 422, und das Rendering mit dynamic=true kostete 5 Credits und 1.408 Tokens in 6,3 s. Siehe warum ein Fetch leer zurückkommt und JavaScript-Rendering. Eine Korrektur: Unsere erste Prüfphrase für crates.io passte nicht dazu, wie die Seite ihren Text aufteilt, also haben wir sie korrigiert und beide Tools auf dieser Seite neu laufen lassen.
Wenn die Aufgabe ist, eine öffentliche Seite zu lesen und daraus zu antworten, genügt Lesen, und die Web-Scraping-API oder das Tool scrape_page erledigt das in einem Aufruf. Für die Einbindung in Claude Code, Cursor und Codex siehe Websuche über MCP.
Wie reproduziere ich das?
import asyncio, os, sys, requests, tiktoken
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
enc = tiktoken.get_encoding("o200k_base")
tokens = lambda s: len(enc.encode(s, disallowed_special=()))
def fastaf_markdown(url, dynamic=False):
params = {"url": url, "formats": "markdown"}
if dynamic:
params.update(dynamic="true", wait=3000)
r = requests.get("https://api.fastaf.co/v1/scrape", params=params, timeout=120,
headers={"Authorization": f"Bearer {os.environ['FASTAF_API_KEY']}"})
return r.text if r.status_code == 200 else "", r.headers.get("X-FastAF-Credits-Used")
async def playwright_snapshot(urls):
# npm i @playwright/mcp@0.0.83 (the real server, over stdio, headless)
server = StdioServerParameters(command="node", cwd=os.getcwd(),
args=["node_modules/@playwright/mcp/cli.js", "--headless", "--isolated"])
out = {}
async with stdio_client(server) as (r, w), ClientSession(r, w) as s:
await s.initialize()
for url in urls:
nav = await s.call_tool("browser_navigate", {"url": url})
snap = await s.call_tool("browser_snapshot", {})
text = lambda res: "\n".join(c.text for c in res.content if c.type == "text")
out[url] = tokens(text(nav)) + tokens(text(snap))
return out
urls = sys.argv[1:]
pw = asyncio.run(playwright_snapshot(urls))
for url in urls:
md, credits = fastaf_markdown(url)
print(f"{url}\n playwright {pw[url]:>7,} tokens fastaf {tokens(md):>7,} tokens ({credits} credit)")Am 19. Oktober 2026 gegen zwei der obigen Seiten ausgeführt, druckte es:
https://www.gov.uk/vat-rates
playwright 3,038 tokens fastaf 1,392 tokens (1 credit)
https://news.ycombinator.com/
playwright 13,647 tokens fastaf 3,323 tokens (1 credit)Der Snapshot von GOV.UK kam hier auf 3.038 gegen 3.378 in der Tabelle, weil sich Seiten zwischen Läufen ändern. Unser vollständiger Lauf ergänzte die Needle-Prüfungen, einen Retry nach 3 s Wartezeit für dünne Snapshots, drei Wiederholungen und den Zweig mit --mobile. Durchgehend haben wir Chromium auf einem Laptop in Italien laufen lassen, und es sind dieselben URLs wie in der Tabelle, du kannst sie also erneut laufen lassen.
Die Kurzfassung
Auf 11 öffentlichen Seiten brauchte ein Abruf über Playwright MCP im Median 9.874 Tokens und das Markdown 5.083: grob die Hälfte, nicht ein Hundertstel. Der Snapshot gibt Tokens für Refs, Rollen und URLs aus; --mobile kürzt ihn, kann aber Inhalt verlieren; und der Snapshot kann bei Seiten, die fast nur Struktur sind, trotzdem gewinnen. Nimm den Browser, wenn du klicken, tippen oder dich bei etwas Eigenem anmelden musst, und lies die Seite als Markdown, wenn du nur wissen willst, was drinsteht. Hol dir 500 kostenlose Credits und lass das Skript auf den Seiten laufen, die dein Agent am häufigsten liest. Preise und Limits stehen auf der Preisseite und in den Docs.