Eine Anwendung, die auf KI-Sprachmodelle angewiesen ist, benötigt regelmäßig API-Aufrufe – für Textgenerierung, Bildkreation oder Workflows mit LangChain. Die offizielle OpenAI-API verursacht schnell hohe Kosten, enge Ratenlimits und aufwändige Einrichtung von API-Schlüsseln. Da entstand die Idee: die vorhandene ChatGPT-Oberfläche nutzen, die im Browser läuft und für Abonnenten bereits bezahlt ist. Allerdings gibt es keine offizielle Schnittstelle zur programmatischen Steuerung. Ein Entwickler experimentierte in einem Wochenendprojekt. Das Ergebnis ist CatGPT-Gateway, ein System, das die ChatGPT-UI in eine OpenAI-kompatible REST-API verwandelt. Technisch interessant, aber ethisch und rechtlich fragwürdig. Dieser Artikel beschreibt die Funktionsweise, die Hürden und warum der Nachbau nicht empfohlen wird.
Gautam Vhavle entwickelte das Projekt aus technischer Neugier, nicht aus finanziellen Gründen. Er arbeitete an einer Anwendung mit wiederholten API-Aufrufen und fragte sich, ob er die Chat-Oberfläche automatisieren könnte. Sein Ziel war ein Strukturexperiment – die Grenze zwischen Benutzeroberfläche und programmatischem Endpunkt auszuloten. Was an einem Freitagabend begann, dauerte mehrere Wochen und erforderte Auseinandersetzung mit Browserautomation, Anti-Bot-Systemen und Chromes Verhalten in Docker-Containern.
Die technische Grundlage: Ein Browser, der für eine API gehalten wird
Das Konzept ist einfach, die Umsetzung komplex. Der Entwickler startet einen echten Chrome-Browser – mit sichtbarem Fenster – und lässt ihn auf die ChatGPT-Webseite zugreifen. Ein FastAPI-Server empfängt Anfragen im Standard-OpenAI-Format, zum Beispiel POST /v1/chat/completions. Diese Anfrage wird an einen ChatGPT-Client weitergereicht. Der Client simuliert einen menschlichen Benutzer: Er tippt die Nachricht in das Eingabefeld von ChatGPT, wartet auf die Antwort und extrahiert den Text durch Klicken auf den Kopieren-Button. Der Benutzer erhält eine JSON-Antwort, die der OpenAI-Spezifikation entspricht. Aus Sicht der Anwendung – ob LangChain, CrewAI oder ein einfaches curl-Skript – scheint es, als ob sie direkt mit OpenAIs Servern spricht. Tatsächlich spricht sie mit einem Browser, der von einer Katze gesteuert wird, wie der Autor augenzwinkernd anmerkt.
Der Ablauf hat jedoch einige Hürden. OpenAI verwendet Cloudflare zur Bot-Erkennung. Cloudflare prüft nicht nur navigator.webdriver, sondern auch Canvas-Fingerprinting, WebGL-Signaturen, Plugin-Listen und das Verhalten von Mausbewegungen und Tippgeschwindigkeit. Ein automatisiertes Skript, das Nachrichten sofort einfügt, fällt sofort auf. Der Entwickler setzte Stealth-Techniken ein, um den Browser menschlich erscheinen zu lassen. Er verwendet eine spezielle Variante von Playwright namens Patchright, kombiniert mit playwright-stealth, das viele Fingerprinting-Merkmale überschreibt. Die Texteingabe erfolgt nicht zeichenweise, sondern per Zwischenablage mit zufälligen Verzögerungen. Mausbewegungen werden mit Zwischenschritten simuliert, und die Fenstergröße wird bei jedem Start leicht variiert. Ein Bug trat im Docker-Container auf: Der Aufruf von add_init_script() zerstörte die DNS-Auflösung von Chrome vollständig. Die Lösung war, das JavaScript zur Laufzeit über page.evaluate() zu injizieren und bei jedem Seitenwechsel erneut auszuführen. Ein typischer Fall von stundenlanger Fehlersuche, behoben mit einer einzigen Zeile Code.
Der VNC-Trick: Ein Browser, der gleichzeitig sichtbar und unsichtbar ist
Ein cleverer Teil des Projekts ist der Browserbetrieb. Um Cloudflare zu täuschen, muss ein sichtbarer Browser laufen. Auf einem Server gibt es keinen Monitor. Der Entwickler richtete Xvfb (X Virtual Framebuffer) ein, der eine künstliche Anzeige erzeugt. Diese wird von x11vnc als VNC-Server bereitgestellt, und über noVNC kann man per Webbrowser auf den virtuellen Bildschirm zugreifen. Das Ergebnis: Für Cloudflare sieht es aus wie ein echter Chrome-Browser mit GPU-beschleunigter Anzeige. Für den Server ist es ein kopfloser Prozess ohne physische Anzeige. Als Administrator kannst du über localhost:6080 live zusehen und manuell CAPTCHAs lösen. Der Autor nennt es Schrödingers Browser – gleichzeitig sichtbar und unsichtbar. Diese Architektur erfordert mehrere Prozesse, die von supervisord verwaltet werden: Xvfb, x11vnc, noVNC und den FastAPI-Server. Ein einfaches docker compose up startet die gesamte Umgebung.
OpenAI-kompatible Endpunkte: Mehr als nur Text
Das Projekt unterstützt nicht nur Chat. Der Entwickler gestaltete die API als vollwertigen Ersatz für die OpenAI-API. Endpunkte wie /v1/chat/completions und /v1/images/generations verwenden Pydantic-Schemata, die der OpenAI-Spezifikation entsprechen. Antworten enthalten Felder wie id, choices und usage. Tool Calling (Funktionsaufrufe) wird ebenfalls unterstützt. Da der Browser keine native Funktion zum Aufrufen von Tools hat, nutzt CatGPT einen Prompt-basierten Trick: Es fügt der System-Nachricht die Definitionen der verfügbaren Tools hinzu, mit wenigen Beispielen (Few-Shot). ChatGPT wird aufgefordert, strukturiertes JSON auszugeben. Dieses JSON wird mittels regulärer Ausdrücke extrahiert und in eine tool_calls-Antwort umgewandelt. Frameworks wie LangChain oder AutoGen können nahtlos mit dem Gateway zusammenarbeiten, indem sie einfach die base_url umstellen.
DALL-E-Integration ist ebenfalls möglich. Der Auslöser für das gesamte Projekt war der Bedarf an wiederholter Bildgenerierung. Der Entwickler stellte fest, dass ChatGPT selbst DALL-E-Bilder im Chat erzeugen kann. CatGPT sendet eine entsprechende Textnachricht an ChatGPT, wartet, bis im DOM ein Bild-Element mit der Kennung img[alt='Generated image'] erscheint, und lädt das Bild über die Browsers fetch()-API herunter. Da der Browser bereits authentifiziert ist, werden die Cookies automatisch mitgesendet. Das Bild wird als Base64 oder URL zurückgegeben, wiederum im OpenAI-kompatiblen Format. Der Benutzer erhält sogar den revised_prompt – den intern von DALL-E verwendeten Prompt. Das funktioniert selbst mit dem offiziellen OpenAI Python SDK, wenn der Endpunkt entsprechend konfiguriert ist.
Warum der Nachbau problematisch ist
Der Entwickler betont mehrfach, dass das Projekt nur zu Bildungszwecken und für Cybersicherheitsforschung dient. Es ist keine Aufforderung, die Nutzungsbedingungen von OpenAI zu umgehen. Die Nutzung in Produktion ist aus mehreren Gründen problematisch. Erstens verstößt es gegen die Nutzungsbedingungen von OpenAI, die automatisierte Zugriffe auf die Chat-Oberfläche verbieten. Das kann zur Sperrung des Kontos führen. Zweitens ist die Lösung extrem fragil: Jede Änderung der ChatGPT-Oberfläche – ein neuer CSS-Klasse, ein anderer Button-Text – kann die gesamte Automation zerstören. Drittens ist die Latenz deutlich höher als bei der echten API, da jeder Aufruf einen Browser-Start und die Interaktion mit einer Webseite erfordert. Viertens gibt es Sicherheitsrisiken: Der Browser läuft mit den Sitzungscookies – ein Fehler im Skript könnte diese offenlegen. Der Autor selbst sagt: „Ich bin kein Hacker, das ist kein Bug. Ich bin nur ein neugieriger Entwickler, der die Grenzen der Browserautomation verstehen wollte.“ Diese Haltung ist vorbildlich. Sie zeigt auch, wie verführerisch solche Workarounds sein können, besonders wenn die offizielle API teuer oder umständlich ist.
Was wir daraus lernen können
Das Projekt zeigt: Browserautomation ist weit fortgeschritten, und Plattformen wie OpenAI müssen ihre Schutzmechanismen ständig verbessern. Es unterstreicht den Bedarf an besseren, günstigeren API-Zugängen. Die Umgehung von Nutzungsbedingungen hat rechtliche und ethische Konsequenzen. Bevor du einen Workaround baust, prüfe, ob der offizielle Weg nicht doch bezahlbar oder mit Optimierung nutzbar ist. Die Preise sinken, die Limits steigen. Vielleicht werden solche Proxy-Lösungen bald überflüssig.
Quelle: dev.to
