Sitzungen sind kostenlos – Sie zahlen nur für Traffic
Cloud-Browser für KI-Agenten
Geben Sie einem Agenten einen echten Browser, und er muss nicht mehr raten, was eine Seite vermutlich enthält – er sieht das gerenderte Layout, durchläuft das DOM und kann klicken, scrollen oder tippen wie ein Mensch.
Ein MCP-Server mit einem schlanken, auf konkrete Aufgaben ausgerichteten Toolset hinter nur einem API-Schlüssel
Seiten werden als Markdown oder JSON zurückgegeben statt als Roh-HTML, das das Kontextfenster aufbraucht
Sitzungen, die stundenlang laufen und sich erneut mit demselben Browser verbinden, statt von vorn zu beginnen
Keine Einrichtung nötig. Ihr Agent erledigt alles.
Kopieren Sie einen Prompt und fügen Sie ihn in Ihren KI-Agenten ein. Dieser öffnet eine Cloud-Browser-Sitzung, steuert die Seite und berichtet, was er tatsächlich gesehen hat – ganz ohne Code.
Ideal für
Claude
ChatGPT
Cursor
GitHub Copilot
Google Gemini
Windsurf
cloud-browser.prompt.md~870 Tokens
1# Floppydata Cloud Browser — reference and operating rules23You are working with the Floppydata Cloud Browser API. Use only the facts4below: never guess endpoints or fields, and never invent page content —5report only what the browser actually returned.67## Step 0 — is there an API key?8Read the key from FLOPPY_API_KEY in the environment. If it is missing, do9not attempt a session and do not ask for the key in chat. Walk the user10through this instead:1112 1. Create an account, or sign in to an existing one:13 https://app.floppydata.com/account/signup14 2. Open API keys, copy the key that is already there or generate a new15 one: https://app.floppydata.com/api-keys16 3. Buy traffic: https://app.floppydata.com/proxies/buy?type=rotating17 Sessions themselves are free, but every page a session loads goes18 out through Floppydata proxies, and proxy traffic is billed per GB.19 With no traffic on the account a session has no network to run on.20 4. Put the key in the environment as FLOPPY_API_KEY — not in code, not21 in a chat message — then run the task again.2223## Step 1 — with a key, start the session straight away24Do not interview the user about settings. Start on these defaults and25change them only when the task actually calls for it.2627POST https://api.floppydata.net/v2/browser/sessions28X-Api-Key: $FLOPPY_API_KEY29{30"proxy": {31"type": "residential", // residential | mobile | datacenter32"location": { "countryCode": "DE" },33"rotation": { "mode": "sticky" } // one IP for the whole session34 },35"browser": { "fingerprint": { "strategy": "auto", "os": "windows" } },36"runtime": { "timeoutSeconds": 1800, "keepAlive": true }37}3839Every field is optional: {} also works — residential proxy, sticky40rotation, 600 second timeout.4142201 Created returns:43 id session id44 status running | stopped | timedOut | failed45 connectUrl signed wss:// CDP endpoint — treat it like a password46 settings.id reuse it to restore this identity and cookie jar47 expiresAt when the session ends on its own4849A 401 means the key is wrong or revoked: back to Step 0. If the call is50refused because the account has no traffic left, send the user to the buy51page above rather than retrying.5253## Step 2 — drive the page54Connect over CDP and work in the tab that is already open:5556 const browser = await chromium.connectOverCDP(connectUrl);57 const page = browser.contexts()[0].pages()[0];58 await page.goto(url, { waitUntil: "domcontentloaded" });5960One session keeps cookies and page state between steps, so navigate,61fill, click and read inside it instead of starting a session per action.6263## Step 3 — hand a step to a human64Some checks only a person can clear. Request a live view for the session,65let someone finish that step, then reconnect and carry on:6667 POST /v2/browser/sessions/{id}/live-view -> { liveViewUrl }68 GET /v2/browser/sessions/{id} -> fresh connectUrl6970## Step 4 — reuse the identity on the next run71Send back the settings id you were given:7273 { "settings": { "id": "<settings-id>" } }7475## Step 5 — stop when the task is done76POST https://api.floppydata.net/v2/browser/sessions/{id}/stop7778## Rules79- Report values you actually read; if a selector is missing, say so.80- Never print the API key, connectUrl or liveViewUrl in your output.81- Keep one session per task; do not open a new one for every step.82- Ask before spending traffic on pages the task does not need.
Vollständiger Prompt · 82 Zeilen · kein Code erforderlich
Warum KI-Agenten einen vollwertigen Cloud-Browser brauchen
Ein Agent, der nur rohe HTTP-Antworten sieht, arbeitet halb blind. Der größte Teil des nützlichen Webs von heute – Dashboards, Suchergebnisse, alles hinter einem Login – wird per JavaScript gerendert, und ein einfacher HTTP-Abruf bekommt diesen Teil nie zu sehen.
Geben Sie demselben Agenten stattdessen einen echten Browser, und er muss nicht mehr raten, was eine Seite vermutlich enthält. Er sieht das tatsächlich gerenderte Layout, bewegt sich durch das DOM wie der Mauszeiger eines Menschen und kann klicken, scrollen oder tippen, so wie ein menschlicher Tester bei einem manuellen Durchlauf.
Genau dieser Unterschied trennt die besseren KI-Cloud-Browser von einem einfachen Scraping-Wrapper: Der eine übergibt dem Modell rohes Markup und hofft auf das Beste, der andere gibt ihm etwas, das Augen und Händen auf der Seite selbst näherkommt.
Agenten-Sitzung
Agent / LLMMCP-Tools
Cloud-Browser
Zielwebsiteklicken · ausfüllen · lesen
Daten / Aktionmarkdown
Funktionen für agentische Workflows
Ein für Agenten entwickelter Cloud-Browser muss drei Aufgaben gleichzeitig abdecken: mit der Tooling-Schicht des Modells kommunizieren, Daten zurückliefern, die das Modell tatsächlich nutzen kann, und die Schritte ausführen, für die sich ein Agent entscheidet.
Native Integration mit MCP- und LLM-Frameworks
Floppydata bietet einen MCP-Server, der einem Agenten ein kleines, aufgabenorientiertes Toolset hinter einem einzigen API-Schlüssel bereitstellt – Webdaten abrufen, Proxy-Verbindungen aufbauen, das Kontoguthaben prüfen. So muss sich das Modell weder Endpunkte noch Header merken.
Für das eigentliche Browsen – Klicken, Felder ausfüllen, mehrstufige Abläufe ausführen – verbindet sich ein Agent mit einer Cloud-Browser-Sitzung genauso wie jedes Playwright- oder Puppeteer-Skript, und zwar über eine signierte WebSocket-URL. Jedes Framework, das bereits einen lokalen Playwright-Browser steuern kann, lässt sich in der Regel ohne großen Aufwand auf einen entfernten Browser umstellen.
Saubere Daten extrahieren (Markdown / JSON für Prompts)
Rohes HTML verbraucht ein Kontextfenster schnell – Script-Tags, Inline-Styles, Navigationsmenüs, nichts davon beantwortet die eigentliche Frage, die ein Agent lösen will. Wird eine Seite auf Markdown oder einen strukturierten JSON-Block reduziert, bleiben die Daten nutzbar, ohne dass Tokens für Beiwerk verschwendet werden, das niemand angefordert hat.
Welche Ausgabeformate verfügbar sind, hängt davon ab, welcher Endpunkt den Abruf durchführt. Prüfen Sie daher die aktuelle API-Dokumentation auf die angebotenen Markdown- oder JSON-Optionen, bevor Sie eine Pipeline um ein bestimmtes Format aufbauen.
Nach dem Verbinden ist ein Agent nicht darauf beschränkt, eine einzelne Seite zu lesen. Er kann navigieren, ein Formular ausfüllen, eine Suche absenden, auf Ergebnisse warten und die nächste Seite lesen – alles in einer durchgehenden Sitzung, wobei Cookies und Seitenzustand automatisch von Schritt zu Schritt übernommen werden.
Ausfallsicherheit: lange Sitzungen und Erhalt des Kontexts
Agentenaufgaben sind selten in einer einzigen Anfrage erledigt. Eine Recherche ruft nacheinander vielleicht so viele Seiten auf, wie ein Dutzend Tabs fassen würde; ein Checkout-Ablauf braucht womöglich mehrere Minuten Wartezeit zwischen den Schritten. Sitzungen können Stunden statt Sekunden laufen, und nach einem Verbindungsabbruch wird derselbe Browser wieder aufgenommen, statt mit einem leeren Tab neu zu beginnen.
Zusätzlich ermöglichen gespeicherte Browsereinstellungen einem Agenten, dieselbe Identität und denselben Cookie-Zustand über getrennte Durchläufe hinweg wiederzuverwenden. Das ist wichtig für alles, was davon abhängt, angemeldet zu bleiben oder zwischen zwei Aufgaben einen konsistenten Fingerprint beizubehalten.
Schnelle Integration mit LangChain, LlamaIndex, Claude
Dafür ist nicht für jedes Framework ein eigenes Plugin nötig. Da der Verbindungspunkt ein Standard-CDP-WebSocket ist – dieselbe Sprache, die Playwright und Puppeteer bereits sprechen –, lässt sich jedes LangChain-Browsing-Tool, jeder LlamaIndex-Web-Reader und jedes Setup im Stil von Claude Computer Use, das eine dieser Bibliotheken bereits steuern kann, in der Regel auf eine Floppydata-Sitzung statt auf eine lokale umstellen, meist durch den Austausch einer einzigen Verbindungs-URL.
Für Teams, die führende Cloud-Browser-Lösungen für KI-Agenten vergleichen, zählt diese Kompatibilität oft mehr als eine lange Funktionsliste – ein Agenten-Stack, der bei jeder Änderung der Browser-Schicht neu gebaut werden muss, ist schlechter als einer, der mit weniger beweglichen Teilen einfach weiterläuft.
Worauf Sie achten sollten, bevor Sie einen Anbieter für diese Art von Workload wählen
Bei den besten Cloud-Browsern für KI-Workloads zählen diese drei Antworten in der Praxis meist mehr als jeder einzelne Benchmark-Wert.
Lange Sitzungen und erneute Verbindungen
Unterstützt die Sitzung lange Timeouts und erneute Verbindungen, oder bedeutet ein Verbindungsabbruch, dass die gesamte Aufgabe von vorn beginnt?
Identität, die einen Durchlauf überdauert
Können Browser-Identität und Cookies zwischen getrennten Durchläufen erhalten bleiben, oder startet jede Sitzung in einem neuen, nicht angemeldeten Zustand?
Fingerprinting, das standhält
Ist das Fingerprinting so gut umgesetzt, dass ein Antidetect-Setup – oder wie auch immer eine Plattform ihren Antidetect- bzw. Unerkennbarkeitsmodus nennt – über eine lange laufende Agentenaufgabe hinweg tatsächlich standhält und nicht nur bei einem einzelnen Seitenaufruf?
Auf dieser Website sind Cookies aktiviert. Wir nutzen sie für Analyse- und Werbezwecke, um die Nutzung der Website zu verstehen und die Leistung von Kampagnen zu messen. Mehr erfahren.