KI-Agent im Web: ein echtes Chrome mit GPU für Claude

Ein KI-Agent, der im Web handelt (ein Formular ausfüllen, Angebote vergleichen, ein Dashboard überwachen), braucht einen echten Browser, der dauerhaft läuft, und zwar nicht auf Ihrem Laptop. Zwei Fehler sorgen dafür, dass er schon auf der ersten Seite als Bot erkannt wird:

1. ihn im Headless-Modus starten: Chrome gibt sich dann in seinem User-Agent selbst als HeadlessChrome zu erkennen;
2. ihn ohne GPU starten: Die Grafikkarte wird zu SwiftShader (einer emulierten GPU), oder WebGL verschwindet ganz.

Ein Desktop-PC hat nie diese Merkmale. Die Regel ist also einfach: ein echtes Chrome, im Fenster, auf einem virtuellen Bildschirm, mit einer echten GPU.

Dieser Artikel zeigt, wie Sie Chrome mit der GPU für einen Claude-Agenten betreiben, vergleicht Xvfb und Xorg „dummy“, behandelt Selenium und erklärt, was die GPU gegenüber der Boterkennung von Cloudflare ändert (oder nicht). Alle Messungen sind reproduzierbar: Das Skript ist öffentlich.

Die Architektur

• Der Agent (Claude Code oder das Claude Agent SDK) entscheidet über die Aktionen;
• Playwright MCP stellt dem Agenten den Browser als Werkzeuge bereit (browser_navigate, browser_click, browser_type, browser_snapshot…) und steuert Chromium per CDP (Chrome DevTools Protocol);
• Chromium läuft im Fenstermodus auf einem virtuellen Xvfb-Bildschirm und rendert über ANGLE/Vulkan auf der GPU;
• x11vnc ermöglicht es Ihnen, den Bildschirm zu beobachten und selbst einzugreifen (zum Beispiel für eine Zwei-Faktor-Authentifizierung).

Der Ablauf einer Aktion:

Die Messungen

Bedingungen

• Linux-GPU-Testserver, VM konfiguriert wie das Angebot Perf 2 (4 vCPU), Intel-UHD-770-GPU zwischen mehreren VMs geteilt (die VM sieht ihr eigenes GPU-Gerät, /dev/dri, mit dem Standard-Linux-Treiber), Debian 13;
• Chromium 156, Playwright MCP 0.0.83, Selenium 4.31 + chromedriver 156, Xvfb (Xorg 21) und xserver-xorg-video-dummy 0.4.0;
• die GPU wurde während der Messungen nicht von anderen VMs beansprucht;
• Messungen vom 29.10.2026.

Wie gerechnet wird

Der Benchmark ist eine WebGL-2-Seite (webgl-bench.html):

1. ein Canvas mit 1920×1080;
2. ein Fragment-Shader, der 64 Sinus/Kosinus pro Pixel berechnet, also etwa 265 Millionen Sinus/Kosinus pro Bild;
3. ?draws=N zeichnet N Vollbild-Bilder pro Frame (requestAnimationFrame);
4. nach jedem Frame liest readPixels ein Pixel: Das zwingt den Browser, das Rendering abzuschließen; sonst könnte er die Befehle in eine Warteschlange stellen und einen schmeichelhaften, aber falschen Wert anzeigen;
5. nach 5 s: Bilder/s = Anzahl der Bilder ÷ Dauer. Außerdem wird geprüft, dass das Programm korrekt gelinkt ist und das gelesene Pixel die richtige Farbe hat.

Chrome wird mit --disable-gpu-vsync --disable-frame-rate-limit gestartet, damit es nicht auf 60 Bilder/s begrenzt ist. Die CPU-Last ist die Differenz der Zähler aus /proc/stat allein während der Testdauer, umgerechnet in belegte vCPU.

chromium --headless=new --use-angle=vulkan --ignore-gpu-blocklist \
  --disable-gpu-vsync --disable-frame-rate-limit \
  --enable-logging=stderr --v=0 "file:///root/webgl-bench.html?draws=10" \
  2>&1 | grep -m1 RESULT

Ergebnis 1: Die GPU macht den Unterschied (×20)

--headless=new, 10 Bilder pro Frame:

Rendering	1080p-Bilder/s	Belegte CPU
SwiftShader (Standard, CPU)	13	3,9 von 4 vCPU
UHD 770, --use-angle=vulkan	~260	0,6 vCPU
UHD 770, --use-angle=gl-egl	~230	—

Mit der GPU ist das Rendering 20-mal schneller, und der Prozessor bleibt frei. Für einen Agenten ist das der entscheidende Punkt: Ohne GPU lastet eine schwere Seite (Karte, Dashboard, Video) die 4 vCPU voll aus, und Agent, Playwright und virtueller Bildschirm streiten sich um den Rest.

Ergebnis 2: Xvfb oder Xorg dummy, egal

Man hört oft, man solle Xvfb durch Xorg mit dem dummy-Treiber ersetzen, um „echter zu wirken“. Gemessen im Fenstermodus, 1 Bild pro Frame:

Virtueller Bildschirm	Ohne Option	SwiftShader erzwungen	GPU (--use-angle=vulkan)
Xvfb	WebGL deaktiviert	9,2 Bilder/s	67,6 Bilder/s
Xorg + dummy-Treiber	WebGL deaktiviert	8,7 Bilder/s	58,8 Bilder/s, dann WebGL-Kontext verloren

• Keiner der beiden nutzt von sich aus die GPU: glxinfo zeigt bei beiden llvmpipe (Software-Rendering);
• ohne Option deaktiviert Chrome WebGL auf beiden;
• mit dem dummy-Treiber hat unser GPU-Versuch den WebGL-Kontext nach einigen Bildern verloren (eglCreateWindowSurface failed with error EGL_BAD_MATCH). Xvfb dagegen lief stabil.

Die Wahl des virtuellen Bildschirms ist also zweitrangig: Für die Leistung zählt meistens die GPU. Bleiben Sie bei Xvfb, das ist einfacher, und ergänzen Sie Chrome um die beiden GPU-Optionen.

Ergebnis 3: Welchen Renderer die Website sieht

Das liest ein Erkennungsskript aus (WEBGL_debug_renderer_info):

Konfiguration	Gemeldeter WebGL-Renderer
--headless=new ohne Option	SwiftShader (auf der CPU emuliert)
Xvfb oder dummy, ohne Option	kein WebGL
Selenium + Xvfb, ohne Option	kein WebGL
Selenium + Xvfb, GPU-Optionen	Intel(R) UHD Graphics 770
Playwright MCP, Fenstermodus auf Xvfb, GPU-Optionen	Intel(R) UHD Graphics 770
headless, GPU-Optionen	Intel(R) UHD Graphics 770

Ergebnis 4: headless = sofort erkannt

Was ein JavaScript-Skript mit einer Zeile auf der Seite ausliest, in den vier Konfigurationen (Chromium 156):

	Headless ohne GPU	Headless + GPU	Xvfb-Fenster ohne GPU	Xvfb-Fenster + GPU
navigator.userAgent	❌ HeadlessChrome/156…	❌ HeadlessChrome/156…	✅ Chrome/156…	✅ Chrome/156…
Grafikkarte (WebGL)	❌ SwiftShader	✅ Intel UHD Graphics 770	❌ keine (WebGL abgeschaltet)	✅ Intel UHD Graphics 770
screen	❌ 800×600	❌ 800×600	✅ 1920×1080	✅ 1920×1080
Fenstergröße	780×580	780×580	945×1060	1919×1079

• Der Headless-Modus verrät sich selbst: Das Wort HeadlessChrome steht im User-Agent, der mit jeder Anfrage gesendet wird. Es ist das am einfachsten zu blockierende Signal, und alle Anti-Bot-Systeme tun das. Der Bildschirm mit 800×600 bestätigt die Diagnose;
• ohne GPU verschwindet WebGL, selbst im Fenster: Kein moderner Desktop-Browser befindet sich in dieser Lage;
• nur die letzte Spalte sieht wie ein echter Arbeitsplatz aus: ein Chrome im Fenster auf einem 1080p-Bildschirm, mit einer echten Intel-Grafikkarte.

Den User-Agent von Hand zu korrigieren, reicht nicht: Der Headless-Modus hat weitere Unterschiede (Bildschirmgröße, Renderverhalten, fehlende APIs), und ein User-Agent, der nicht zum Rest passt, ist selbst verdächtig. Am zuverlässigsten ist es, den Headless-Modus gar nicht zu verwenden: Auf einem Server ist genau dafür Xvfb da.

Ergebnis 5: Im Fenster entlastet die GPU die CPU enorm

Der Fenstermodus hat seinen Preis: Chrome muss die ganze Seite auf den Bildschirm zeichnen. Ohne GPU erledigt der Prozessor alles. Dieselbe WebGL-Animation in 1080p, Chrome im Fenster auf Xvfb, normale Bildrate (maximal 60 Bilder/s), CPU-Last während des Tests über die gesamte VM gemessen:

Chrome im Fenster auf Xvfb	Bilder/s	Belegte CPU (VM mit 4 vCPU)
Ohne GPU (SwiftShader)	9,8	3,4 vCPU: Die VM ist ausgelastet
Ohne GPU, 3× schwerere Szene	4,0	3,7 vCPU
Mit der UHD-770-GPU	60 (flüssig)	0,3 vCPU
Mit der GPU, 3× schwerere Szene	60	0,3 vCPU

Mit der GPU zeigt Chrome 6-mal mehr Bilder an und braucht dabei mehr als 10-mal weniger CPU, also etwa 70-mal weniger CPU pro Bild. Ohne GPU ist die VM ausgelastet und erreicht nicht einmal 10 Bilder/s: Agent, Playwright und der Rest des Systems kämpfen um die Krümel, jede Aktion dauert länger, und schwere Seiten werden unbrauchbar. Mit der GPU bleiben 3,7 vCPU frei für die eigentliche Arbeit.

Das ist die Gewinnerkombination: Der Fenstermodus verhindert die Erkennung, und die GPU macht ihn für den Prozessor kostenlos.

Was die GPU gegenüber Cloudflare ändert

Cloudflare (Bot Management, Turnstile) kombiniert viele Signale: TLS- und HTTP/2-Fingerabdruck, Reputation der IP-Adresse, JavaScript-Tests in der Seite, Verhalten (Tempo, Bewegungen), statistische Modelle. Ein Browser ohne GPU verrät sich schnell in den JavaScript-Tests: SwiftShader als Grafikkarte oder gar kein WebGL ist eine typische Signatur eines automatisierten Browsers in einem Rechenzentrum.

Mit der GPU meldet Chrome eine echte Intel-Karte und rendert die Seite wie ein Desktop-PC. Konkret verringert das Fehlalarme: CAPTCHAs oder Sperren auf Websites, die Ihr Agent völlig legitim besuchen darf.

Aber eines muss klar sein: CDP + Treiber + gute IP ist NICHT unerkennbar.

• die Steuerung per CDP hinterlässt selbst erkennbare Spuren;
• Rechenzentrumsadressen sind als solche bekannt;
• das Verhalten eines Agenten (Geschwindigkeit, Abfolge der Aktionen) lässt sich erkennen;
• die Regeln ändern sich ständig: Was heute durchkommt, wird morgen blockiert.

Der richtige Ansatz: sich zu erkennen geben

Für einen legitimen Agenten ist der nachhaltige Weg, identifiziert statt versteckt zu sein:

• Web Bot Auth („signed agents“ bei Cloudflare): Der Agent signiert seine HTTP-Anfragen mit einem Ed25519-Schlüssel (HTTP Message Signatures, RFC 9421) und veröffentlicht seinen öffentlichen Schlüssel in einem Verzeichnis; Websites können ihn dann ausdrücklich zulassen;
• ein ehrlicher User-Agent, die Einhaltung von robots.txt und der Nutzungsbedingungen, eine vernünftige Anfragerate;
• auf Ihren eigenen Websites hinter Cloudflare (E2E-Tests, Monitoring) eine WAF-Regel, die die IP Ihres Servers durchlässt.

Einrichtung

1. Pakete

apt install chromium xvfb x11vnc nodejs npm

2. Virtueller Bildschirm und VNC (systemd)

# /etc/systemd/system/xvfb.service
[Unit]
Description=Xvfb :99
[Service]
ExecStart=/usr/bin/Xvfb :99 -screen 0 1920x1080x24 -nolisten tcp
Restart=always
[Install]
WantedBy=multi-user.target

# /etc/systemd/system/x11vnc.service
[Unit]
Description=x11vnc auf :99 (nur localhost)
After=xvfb.service
Requires=xvfb.service
[Service]
ExecStart=/usr/bin/x11vnc -display :99 -localhost -forever -shared -nopw
Restart=always
[Install]
WantedBy=multi-user.target

systemctl enable --now xvfb x11vnc
# von Ihrem Computer aus:
ssh -L 5900:localhost:5900 root@ihr-server   # dann ein VNC-Client auf localhost:5900

VNC lauscht nur auf localhost: Der Zugriff erfolgt ausschließlich über den SSH-Tunnel.

3. Playwright MCP mit der GPU

Datei /root/mcp.json:

{
  "browser": {
    "browserName": "chromium",
    "launchOptions": {
      "executablePath": "/usr/bin/chromium",
      "headless": false,
      "args": ["--use-angle=vulkan", "--ignore-gpu-blocklist", "--no-sandbox"]
    }
  }
}

Mit auf dem Server installiertem Claude Code:

claude mcp add playwright --env DISPLAY=:99 -- \
  npx @playwright/mcp@latest --config /root/mcp.json

Oder als HTTP-Server, wenn der Agent anderswo läuft (SSH-Tunnel zum Port):

DISPLAY=:99 npx @playwright/mcp@latest --config /root/mcp.json --port 8931
# MCP-Endpunkt: http://localhost:8931/mcp

Zur Überprüfung bitten Sie den Agenten, eine Seite zu öffnen, die den WebGL-Renderer anzeigt: Sie muss Intel(R) UHD Graphics 770 melden.

4. Selenium + Xvfb

apt install python3-selenium chromium-driver

from selenium import webdriver
from selenium.webdriver.chrome.service import Service

o = webdriver.ChromeOptions()
o.binary_location = "/usr/bin/chromium"
for a in ["--use-angle=vulkan", "--ignore-gpu-blocklist",
          "--no-sandbox", "--window-size=1920,1080"]:
    o.add_argument(a)
driver = webdriver.Chrome(options=o, service=Service("/usr/bin/chromedriver"))

xvfb-run -a -s "-screen 0 1920x1080x24" python3 mein_skript.py

Geben Sie beim Selenium 4.31 aus Debian chromedriver explizit über Service(...) an: Sonst wird er nicht gefunden (NoSuchDriverException).

Häufige Fragen

Headless oder Fenstermodus auf Xvfb? Ohne Zögern der Fenstermodus. Headless meldet sich als HeadlessChrome und wird auf den meisten geschützten Websites blockiert. Im Fenstermodus können Sie den Agenten außerdem per VNC verfolgen und selbst eingreifen. Behalten Sie headless Ihren eigenen Tests auf Ihren eigenen Websites vor.

Und Claudes Computer Use (Screenshots + Klicks)? Das braucht einen echten Bildschirm: Xvfb + einen Browser im Fenstermodus, genau das Schema oben. Die GPU rendert jeden Screenshot schneller und lässt die CPU für den Rest frei.

Reicht ein Perf-1-Angebot? Für einen Agenten, der klassische Websites besucht, ja. Die Messungen oben wurden mit 4 vCPU (Perf 2) durchgeführt, was nützlich ist, wenn der Agent mehrere Tabs oder schwere Seiten öffnet.

Ausprobieren

Linux-GPU-Server mit Intel UHD 770 in der VM, Mesa und Vulkan bereits installiert. Ab 14,99 € netto/Monat, Root-Zugriff, dedizierte IPv6. Siehe auch: Chrome mit GPU auf einem Linux-Server starten und Xvfb: Praxisleitfaden.