Kategorie: Erklärer

Die versteckte Kostenfalle der KI-Modelle

Du kaufst Kaffee – aber jede Tasse wird in unterschiedlich große Stücke geteilt, und du zahlst pro Stück, nicht pro Tasse. So funktionieren die Preise für KI-Modelle wie GPT oder Claude. Nur heißen die Stücke Tokens. Ein aktueller Test zeigt: Derselbe Inhalt erzeugt bei verschiedenen Anbietern völlig unterschiedlich viele Tokens. Der gleiche TypeScript-Code kostet bei Claude mit dem neuen Tokenizer 73 Prozent mehr als bei GPT – obwohl die Listenpreise auf dem Papier vergleichbar sind.

Viele Entwickler vergleichen KI-Modelle nur anhand der Dollar-pro-Million-Tokens-Preise auf den Preisseiten. Aber ein Token ist keine feste Einheit. Jeder Anbieter zerlegt denselben Text anders. Manche Tokenizer sind effizienter, andere zerstückeln den Text stärker. Da die Abrechnung pro Token erfolgt, entscheidet die Effizienz des Tokenizers über die tatsächlichen Kosten. Der Listenpreis ist nur die eine Hälfte; die andere ist die Anzahl der Tokens, die dein Inhalt ergibt.

Wie der Test durchgeführt wurde

Die Macher des Tests nahmen 16 verschiedene Textbeispiele: englische Prosa, eine HTML-Seite, JavaScript, Python, TypeScript, Rust, JSON-Tool-Schemas, chinesische Texte und den System-Prompt eines Agenten. Jeden Text zählten sie Byte für Byte mit den offiziellen Tokenizern aller aktuellen Modelle. Für Anthropic (Claude Opus, Sonnet, Fable) nutzten sie den offiziellen count_tokens-Endpunkt. Für OpenAI kam der dokumentierte o200k_base-Tokenizer via Tiktoken zum Einsatz, auch Gemini und Grok wurden über die entsprechenden Endpunkte gemessen.

Zur Überprüfung sendeten sie echte API-Anfragen mit max_tokens: 1. Die gemessenen usage.input_tokens stimmten mit den Vorhersagen überein. Die Überprüfung kostete weniger als zehn Cent.

Das erste Ergebnis: Gleicher Listenpreis, 30 Prozent mehr Tokens

Claude Opus 4.6 und Opus 4.8 haben denselben Listenpreis von 5 Dollar für eine Million Eingabe-Tokens. Opus 4.8 verwendet einen neuen Tokenizer, der aus dem gleichen Text rund 30 Prozent mehr Tokens macht. Das gilt auch für Sonnet 5 und Fable 5. Die Steigerung variiert je nach Inhaltstyp: Englische Prosa +34 Prozent, HTML +15 Prozent, JavaScript +20 Prozent, Python +23 Prozent, TypeScript +31 Prozent, Rust +29 Prozent, JSON-Tool-Schema +26 Prozent, Agenten-System-Prompt +39 Prozent. Chinesische Texte blieben nahezu unverändert.

Bei der Gewichtung eines typischen Coding-Agenten – viel System-Prompt, Tool-Schemas, Code und JSON – ergibt sich eine durchschnittliche Steigerung von etwa 32 Prozent pro Anfrage. Wer denselben Code auf Claude Opus 4.8 ausführt, bezahlt effektiv 32 Prozent mehr als auf Opus 4.6. Der Listenpreis ist identisch. Sonnet 5 hatte einen Einführungspreis von 2 Dollar bis Ende August 2026, dann steigt er auf 3 Dollar. In der Einführungsphase gleicht der niedrigere Preis die extra Tokens teilweise aus, aber ab September wird die Arbeit auf Sonnet 5 etwa ein Drittel teurer als auf Sonnet 4.6.

Zweites Ergebnis: Der größte Unterschied tritt bei Code auf

GPT dient als Referenz (Faktor 1,0). Claude schneidet bei Code besonders schlecht ab: TypeScript 1,73x, Rust 1,58x, JavaScript 1,52x, Python 1,50x. Bei englischer Prosa sind es 1,40x, bei HTML 1,36x. Gemini 3 Flash liegt meist nur bei 1,01x bis 1,23x, Grok nahe 1,0x. Chinesische Texte sind bei Claude ebenfalls teurer (1,44–1,55x), während Gemini und Grok hier effizienter sind als GPT.

TypeScript ist der schlimmste Fall, weil GPTs Tokenizer o200k darauf besonders effizient ist: etwa 4,24 Zeichen pro Token. Das liegt vermutlich an vielen Webinhalten im Training, in denen camelCase-Bezeichner und JSX-Muster zu einem einzigen Token zusammengefasst werden. Auf Rust sinkt die Effizienz auf 3,51 Zeichen pro Token. Claudes Tokenizer ist auf beide Sprachen ähnlich dicht – die Lücke ist dort am größten, wo GPT am besten ist.

Was das für den effektiven Preis bedeutet

Der effektive Preis ergibt sich aus Listenpreis mal Token-Faktor. Für einen typischen englischsprachigen Coding-Request: GPT-5.1 liegt bei 1,25/10 Dollar pro Million Tokens (Eingabe/Ausgabe). Claude Sonnet 5 (ab September) kostet 3/15 Dollar, aber wegen des 1,5-fachen Token-Faktors effektiv 4,50/22,50 Dollar. Opus 4.8: Listenpreis 5/25, effektiv 7,50/37,50. Fable 5: 10/50, effektiv 15/75. Gemini 3 Flash bleibt mit 0,50/3 Dollar und einem Faktor von 1,09x bei 0,55/3,27 Dollar der günstigste Anbieter.

Ein Entwickler berichtete bei einer Produktionsmigration zu GPT-5.6 Sol von 1,70 Millionen Eingabe-Tokens gegenüber 2,60 Millionen bei Claude Opus 4.8 für dieselben Builds – etwa 35 Prozent weniger. Das schließt die Modell-Wortwahl (Verbosity) ein, zeigt aber denselben Trend.

Was der reine Input-Vergleich nicht abbildet

Der Test misst nur, wie viele Eingabe-Tokens aus identischen Bytes werden. Bei einer vollständigen Agentenaufgabe kommen weitere Faktoren hinzu: Wie viele Ausgabe- und Thinking-Tokens benötigt das Modell? Wie viel Kontext wird pro Schritt geladen? Wie oft werden Tools aufgerufen oder Subagenten gestartet? Wie werden Cache-Schreib- und Lesevorgänge abgerechnet? Diese Variablen können die Gesamtkosten weit stärker beeinflussen als der reine Input-Unterschied.

Cache-Traffic wird ebenfalls pro Token abgerechnet. Ein Tokenizer, der 32 Prozent mehr Tokens produziert, macht auch jeden Cache-Write und Cache-Read etwa 32 Prozent teurer. In langen Agenten-Sitzungen dominieren Cache-Reads oft die Rechnung. Zudem können sich die Gesamtkosten durch unterschiedliche Verbosity und Thinking-Stufen um ein Vielfaches unterscheiden – es gibt Berichte über Modelle, die zwei- bis viermal so viele Tokens verbrauchen.

Praktische Lehren für Entwickler

Vergleiche auf deinem eigenen Content. Deine Sprache und Dateitypen bestimmen den Multiplikator. Nimm eine repräsentative Stichprobe deiner tatsächlichen Anfragen und zähle sie mit den Tokenizern der Anbieter, bevor du einem Listenpreis vertraust. Wenn ein Anbieter ein neues Modell zum gleichen Listenpreis ausliefert, prüfe, ob der Tokenizer sich geändert hat. Opus 4.6 zu 4.8 ist eine Effektivsteigerung von 32 Prozent, die auf keiner Rechnung auftaucht.

Messe den Preis pro abgeschlossener Aufgabe. Die usage-Felder der API liefern die Rohdaten. Der Dollar-pro-Million-Tokens-Wert ist ein nützlicher erster Anhaltspunkt, aber nicht über verschiedene Tokenizer hinweg vergleichbar. GPT ist token-effizient bei Englisch und Code, Gemini ist günstig im effektiven Preis, Claude-Modelle haben oft eine höhere Qualität, kosten aber mehr Tokens. Der Preis nach Tokenizer-Arbeit zählt.

Quelle: playcode.io

Ein Assistent führt jeden Morgen denselben Ablauf durch: E-Mails checken, Aufgaben priorisieren, Kalender aktualisieren, Zusammenfassung schreiben. Anfangs erklärst du ihm jeden Schritt in ausführlichen Sätzen. Nach einigen Wochen wiederholt er sich immer gleich. Wäre es nicht sinnvoll, die immergleichen Schritte als festes Programm zu hinterlegen und nur noch Ausnahmen mit dem Assistenten zu besprechen? Ein erfahrener Entwickler hat das umgesetzt und erreichte: 94 Prozent weniger Tokenverbrauch, 87 Prozent niedrigere Latenz bei gleichbleibender Qualität.

Ausgangspunkt war ein täglicher Workflow: Ein KI-Agent – der Coding-Assistent Codex – durchstöberte das Archiv eigener Blogartikel, wählte einen Beitrag aus, prüfte, ob er kürzlich erwähnt wurde, und verfasste einen LinkedIn-Post-Entwurf. Der Entwurf diente als Inspiration, wurde nie automatisch veröffentlicht. Die ursprüngliche Version war vollständig in natürlicher Sprache als Agent Skill formuliert. Der Skill beschrieb Quellen, Prüfungen, Auswahlkriterien und Textstruktur. Bei jedem Durchlauf interpretierte der Agent diese Anweisungen, erstellte einen Plan, rief Werkzeuge auf und verfolgte den Zustand. Das war gut für die erste Version – natürliche Sprache macht den Workflow verständlich und änderbar.

Sobald ein Skill oft ausgeführt wird und immer dieselben Pfade nimmt, wird sein Verhalten festgelegt. Der Workflow kristallisiert sich heraus: Der Skill sucht an denselben Stellen, erstellt dasselbe Inventar, wendet identische Filter an und speichert Zwischenzustände gleich. Das muss nicht jeden Morgen neu durchdacht werden. Vieles braucht kein großes Sprachmodell (LLM). Nur zwei Schritte benötigen ein LLM: die Auswahl eines geeigneten Kandidaten und das Verfassen des LinkedIn-Entwurfs. Alles andere kann deterministischer Code erledigen.

Der Autor kompilierte den Skill in eine spezialisierte Softwareumgebung – eine Harness. Der neue Skill besteht nur noch aus einem dünnen Bootloader, der ein Python-Programm startet. Dieses Programm ruft Quellen ab, baut das Inventar auf, prüft aktuelle Beiträge, wendet Filter an und verwaltet den Workflow. Ein LLM wird nur für Auswahl und Texterzeugung genutzt. Ergebnis: 94 Prozent weniger Tokens, 87 Prozent niedrigere Latenz bei identischer Ausgabequalität. Die Einsparungen kommen nicht von einem kleineren Modell – die LLM-Schritte nutzen dasselbe Modell. Die Einsparung entsteht, weil alle Modellaufrufe entfernt wurden, die regulärer Code direkt und effizienter ausführen kann.

Was bedeutet „Kompilieren“ hier genau?

Der Entwickler hatte historische Spuren (Traces) früherer Ausführungen des Skills – der Workflow lief täglich als Automatisierung in Codex. Diese Traces zeigten Planung, Werkzeugaufrufe, Verzweigungen und benötigten Zustand. Er gab diese Traces, den ursprünglichen Skill und seine Gedanken zu spezialisierten Harnesses einem leistungsstarken Modell. Aufgabe: Identifiziere, welche Schritte wirklich ein LLM erfordern und welche stabil genug für Code sind, und baue die spezialisierte Harness. Der natürlichsprachliche Skill diente als hochrangige Spezifikation, die Traces lieferten operative Details – das Ergebnis vorheriger Modellreasonings. Die Compiler-Analogie passt: Beginne mit einer flexiblen, hochrangigen Darstellung der Absicht. Nachdem der Workflow oft genug ausgeführt wurde, senkt man die stabilen Teile in eine effizientere Repräsentation ab. Das Modell wird weiterhin dort eingesetzt, wo es nötig ist.

Das Ziel: Workflow-Teile unterscheiden, die deterministischer Code sein können, von denen, die Sprachverständnis, Textgenerierung oder Reasoning benötigen. Es geht nicht darum, Sprachverständnis in starre Regeln zu zwängen. Die Kandidatenauswahl hängt davon ab, was die Quelle sagt und ob der Beitrag interessant wäre. Das Verfassen profitiert von Sprachgenerierung. Diese bleiben Modellaufrufe, weil sie modellgeprägte Probleme sind. Die Wertschöpfung liegt darin, das LLM nur auf kleine, wirklich intelligente Aufgaben zu konzentrieren.

Der Workflow: Erst flüssig, dann optimieren

Die spezialisierte Harness von Anfang an zu schreiben, wäre verfrüht gewesen. Der Autor kannte den genauen Workflow nicht, wusste nicht, welche Regeln wichtig sein würden oder wo Urteilsvermögen nötig wäre. Die natürlichsprachliche Version des Skills ermöglichte es, diese Dinge durch wiederholte Ausführung zu entdecken. Doch den gesamten Workflow für immer in natürlicher Sprache zu belassen, hieße, das Modell bei jedem Durchlauf denselben Plan neu finden zu lassen. Das nützliche Muster: 1. Drücke den Workflow als natürlichsprachlichen Skill aus. 2. Führe ihn oft genug aus, um Traces zu sammeln und das Verhalten zu verfeinern. 3. Finde die Teile, die stabil und deterministisch geworden sind. 4. Kompiliere diese Teile in Code. 5. Behalte LLM-Aufrufe an den wenigen Stellen, an denen semantisches Urteilsvermögen erforderlich ist.

Es gibt einmalige Kosten für diesen Kompilierungsdurchlauf. Der Autor nutzte ein leistungsstarkes Modell und viel Kontext, um Traces zu inspizieren und die neue Harness zu erstellen. Diese Kosten werden nur einmal bezahlt. Der kompilierte Workflow kann hunderte Male laufen und spart jedes Mal Tokens und Zeit. Klassische Optimierungsökonomie: einmal ausgeben, über wiederholte Nutzung amortisieren. Der Entwickler betont, dass er lokale Agenten bevorzugt, weil diese genau diese Art von Historie ansammeln: Skills, Traces, Zustände und Artefakte früherer Läufe. Diese Geschichte liefert das Rohmaterial, um die Harness selbst zu verbessern.

Die langfristige Ökonomie der Agenten

Die langfristigen Kosten von Agenten-Workflows hängen von dieser Optimierung ab. Wenn jeder wiederkehrende Workflow für immer ein Frontline-Modell als Planer, Zustandsmaschine und Klebecode verwendet, sinken Kosten und Latenz nie wirklich. Eine spezialisierte Harness erlaubt dem Modell, sich auf den kleinen Bruchteil des Workflows zu konzentrieren, der von Intelligenz profitiert. Der Autor macht einen wichtigen Punkt: Die großen Modellanbieter haben wenig Anreiz, diese Technik aktiv zu promoten. Ihr Geschäft ist der Verkauf von Tokens – möglichst viele von ihren teuersten Modellen. Es gibt einen alten Spruch: Es ist schwer, jemanden von etwas zu überzeugen, wenn sein Gehalt davon abhängt, es nicht zu verstehen. Eine Technik, die die Ausgabequalität erhält und den Tokenverbrauch um 94 Prozent senkt, läuft den wirtschaftlichen Interessen eines Unternehmens zuwider, dessen Einnahmen mit dem Tokenverbrauch steigen.

Der Autor räumt ein, dass es innerhalb dieser Firmen Leute gibt, denen Effizienz wichtig ist – bessere Inferenz, Caching und günstigere Modelle machen deren Produkte nützlicher. Aber es gibt einen Unterschied zwischen günstigeren Tokens und der Hilfe für Kunden, zu entdecken, dass die meisten ihrer Workflows überhaupt keine Tokens benötigen. Derzeit sieht er wenig Anreiz für die großen Anbieter, diese zweite Idee stark zu verfolgen. Also liegt es an Nutzern und unabhängigen Entwicklern, diese Optimierungsmöglichkeiten selbst zu finden. Das ist auch die Chance. Es gibt einen großen offenen Raum für Gründer, die spezialisierte Harnesses, Compiler und Werkzeuge bauen, die wiederkehrende Agenten-Workflows untersuchen und die deterministischen Teile in Code verschieben. Das Wertversprechen ist konkret: Behalte die Ausgabequalität bei, senke Kosten und Latenz.

Die Modellanbieter werden weiterhin leistungsstärkere Motoren bauen. Jemand muss trotzdem sicherstellen, dass wir diese Motoren nicht aufdrehen, um einfache, deterministische Arbeit zu erledigen. Der Ansatz des Autors ist einleuchtend: Nutze natürliche Sprache, um den Workflow zu entdecken. Nutze Traces, um ihn zu verstehen. Dann kompiliere, was sich verfestigt hat. Dieses Prinzip lässt sich auf unzählige alltägliche Automatisierungen anwenden – E-Mails verfassen, Daten auswerten, Projekte verwalten. Es erfordert keine neuen, teuren Modelle, sondern nur den Willen, den eigenen Workflow zu analysieren und die richtigen Grenzen zu ziehen. Wer tiefer einsteigen möchte: Der ursprüngliche Prompt für den „Token Shrinker“ steht zur Verfügung, um ihn im eigenen Agenten auszuprobieren.

Wir können unsere KI-Assistenten effizienter machen, indem wir sie nicht jede einfache Routine neu durchdenken lassen. Stattdessen geben wir ihnen ein festes Skelett für immer gleiche Abläufe und rufen sie nur, wenn echtes Denken gefragt ist. Das spart Geld, Zeit und Rechenaufwand.

Quelle: vivekhaldar.com

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

Du suchst einen bestimmten Artikel auf TechCrunch, landest aber auf einer 404-Seite. Nervig. Während du dich umsiehst, fallen dir die Schlagzeilen in der Sidebar auf: Mira Murati launcht ein offenes KI-Modell, ein mit Private Equity finanzierter Startup will KI-Dienste im großen Stil an Unternehmen verkaufen, Apple bringt seine KI nach China – mit Hilfe von Alibabas Qwen-Modell. Das ist ein Querschnitt durch das, was die KI-Welt im Jahr 2026 bewegt. Kein Hype, keine Utopie, sondern konkrete Arbeit. Lass uns die wichtigsten Nachrichten auseinandernehmen und verstehen, was sie bedeuten – für dich, für Unternehmen und für die Technologie selbst.

KI-Modelle sind heute überall: auf deinem Smartphone, in deiner Mailbox, in Produktionshallen. Die Art, wie sie entwickelt, trainiert und ausgerollt werden, verändert sich grundlegend. Zwei gegenläufige Trends prägen die Szene: der Drang zu immer größeren, allumfassenden Modellen und das wachsende Bedürfnis nach spezialisierten, kontrollierbaren Systemen. Die aktuellen Meldungen spiegeln diese Dynamik.

Von Allzweck-Köchen und Spezialisten: Warum Mira Murati auf offene, spezialisierte KI setzt

Stell dir eine Küche vor, in der ein einziger Koch alles zubereiten muss – von der Vorspeise bis zum Dessert, von der japanischen bis zur italienischen Küche. Das Ergebnis wird selten perfekt. Genau so funktionieren die großen Foundation Models: Sie können vieles, aber nichts richtig gut. Thinking Machines Lab, das neue Unternehmen von Mira Murati, setzt mit seinem offenen Modell „Inkling“ genau hier an. Statt einem Modell, das für alle Aufgaben optimiert ist, sollen Unternehmen und Entwickler spezialisierte Modelle bauen können, die auf bestimmte Domänen zugeschnitten sind. „Offen“ bedeutet, dass der Quellcode und die Gewichte des Modells öffentlich zugänglich sind – eine Ansage gegen die Blackbox-Politik großer Anbieter. Das ist kein Bastelprojekt, sondern ein Versuch, KI demokratischer und gleichzeitig leistungsfähiger im Detail zu machen. Ein Modell, das nur eine Sache kann, diese aber exzellent, ist oft wertvoller als ein Allrounder, der bei allem mittelmäßig bleibt. Ein Sushi-Meister serviert bessere Nigiri als ein Küchenchef, der auch noch die Pasta kochen muss. Genau diese Spezialisierung sehen wir jetzt in der KI-Landschaft.

Enterprise-KI aus dem Baukasten: Was steckt hinter Anthropic und Inside Ode?

Während Murati auf offene Spezialisierung setzt, geht ein anderer Player einen Schritt weiter: Inside Ode, ein mit Private Equity finanzierter Startup, der mit Anthropic zusammenarbeitet, wettet darauf, dass Unternehmen KI nicht selbst entwickeln wollen, sondern lieber fertig konfektionierte Dienstleistungen kaufen. Stell dir vor, du betreibst eine Versicherung, eine Bank oder eine Logistikfirma. Du hast keine KI-Abteilung, aber Daten und Prozesse, die optimiert werden können. Inside Ode baut für dich eine maßgeschneiderte Lösung auf Basis von Anthropics Claude-Modellen – und betreibt sie. Das ist der Unterschied zwischen einem Kochbuch und einem Privatkoch. Das Modell heißt „KI als Service“, und es ist ein heißer Markt. Unternehmen sparen sich die teure Infrastruktur und das Spezialwissen, zahlen eine monatliche Gebühr und bekommen eine Lösung, die genau auf ihre Bedürfnisse zugeschnitten ist. Die Partnerschaft mit Anthropic ist kein Zufall: Anthropic legt Wert auf Sicherheit und Ausrichtbarkeit von KI – genau das, was Unternehmen brauchen, wenn sensible Kundendaten im Spiel sind. Diese Nachricht zeigt: KI ist nicht nur für Tech-Giganten, sondern zieht langsam in den Mittelstand ein – nicht als Spielerei, sondern als ernsthaftes Werkzeug.

Apple Intelligence in China: Warum regionale Anpassung mehr als ein Übersetzungsupdate ist

Ein drittes Puzzle-Stück: Apple Intelligence startet in China – mit Alibabas Qwen-Modell im Hintergrund. Warum nicht das eigene Modell oder ChatGPT? KI ist nicht nur Technik, sondern auch Gesetz und Kultur. China verlangt, dass KI-Modelle den lokalen Vorschriften entsprechen. Daten müssen im Land bleiben, Algorithmen müssen zensurkonform sein, Modelle müssen chinesische Sprach- und Kulturkontexte verstehen. Apple hatte zwei Optionen: ein eigenes Modell von Grund auf trainieren – teuer und zeitaufwendig – oder auf einen etablierten Partner setzen. Alibabas Qwen-Modell ist in China erprobt, kennt die regulatorischen Anforderungen und kann in iPhones integriert werden. Kein Kompromiss, sondern eine strategische Entscheidung. Für dich als Nutzer bedeutet das: Dein iPhone wird in Zukunft wahrscheinlich landesspezifisch unterschiedliche KI-Funktionen haben. In China andere als in Europa, in den USA andere als in Indien. Das ist der Preis für allgegenwärtige KI – sie muss sich lokalen Gegebenheiten anpassen, sonst wird sie blockiert. Und das ist gut so: Eine KI, die überall gleich funktioniert, könnte in manchen Ländern gegen Gesetze verstoßen oder kulturell unpassend sein.

Sicherheit durch KI und KI-Sicherheit: Microsofts Patches und Sunos Datenklau

Zwei weitere Nachrichten runden das Bild ab: Microsoft hat eine Rekordzahl von Sicherheitslücken geschlossen und gibt an, dass KI dabei eine zentrale Rolle gespielt hat. Und: Der Musik-KI-Generator Suno hat offenbar YouTube-Videos für sein Training genutzt – ohne Erlaubnis. Zwei Seiten derselben Medaille. Microsoft zeigt, wie KI zur Verteidigung eingesetzt wird: Algorithmen durchforsten Code nach Schwachstellen, simulieren Angriffe und schlagen Patches vor. Das passiert heute, nicht erst morgen. Auf der anderen Seite steht Suno: Um ein KI-Modell für Musik zu trainieren, braucht man riesige Mengen an Audiodaten. YouTube ist eine naheliegende Quelle, aber meist nicht legal nutzbar. Die Meldung, dass Suno Daten ohne Erlaubnis gescrapt hat, wirft ein Schlaglicht auf die dunkle Seite des KI-Trainings. Viele große Modelle wurden mit urheberrechtlich geschützten Daten trainiert – und die Anbieter hoffen, dass sie nicht erwischt werden oder sich die Rechtslage ändert. Für dich als Anwender bedeutet das: Nicht jede KI, die du nutzt, wurde mit sauberen Methoden trainiert. Achte darauf, woher die Anbieter ihre Daten beziehen, vor allem wenn du die KI geschäftlich einsetzt. Die rechtlichen Grauzonen sind noch da.

Was bedeutet das alles konkret?

Wenn wir die vier Nachrichten zusammenlegen, sehen wir ein klares Bild: KI wird spezialisierter, regionaler, dienstleistungsorientierter und gleichzeitig sicherheitsrelevanter. Kein Hype, sondern eine Evolution. Für Unternehmen bedeutet das: Sie müssen nicht mehr selbst Modelle trainieren, sondern können auf offene Modelle wie Inkling setzen oder auf Dienste wie Inside Ode zurückgreifen. Für dich als Privatnutzer: Deine Geräte werden mehr KI-Funktionen haben, aber diese Funktionen variieren je nach Land und Anbieter. Für die Branche: Die Frage nach sauberen Trainingsdaten und ethischer Entwicklung bleibt relevant. Wir stehen nicht am Ende einer Entwicklung, sondern in einer Phase der Konsolidierung und Ausdifferenzierung. KI ist kein Allheilmittel, sondern ein Werkzeug – wie ein Hammer oder ein Kochmesser. Du musst das richtige Werkzeug für die richtige Aufgabe wählen und sicherstellen, dass es nicht gestohlen oder illegal hergestellt wurde. Nüchtern, aber wahr.

Quelle: techcrunch.com

Du arbeitest seit Jahren mit KI-Assistenten. Erst halfen sie beim Vervollständigen von Codezeilen, dann beim Generieren ganzer Funktionen. Heute, im Jahr 2026, gibst du ein grobes Ziel ein. Ein Agent durchforstet deine Codebasis, ändert mehrere Dateien, führt Tests aus und präsentiert das Ergebnis. Das war vor drei Jahren Science-Fiction, heute ist es Realität. Die Frage: Wie baut man zuverlässige Systeme um diese mächtigen, aber unberechenbaren Modelle? Auf der AI Engineer World’s Fair 2026 zeigte sich: Die Antwort liegt nicht in noch schlaueren Modellen, sondern in der Kunst des Systembaus. KI-Engineering ist erwachsen geworden. Hier sind fünf Trends.

Der Begriff „KI-Ingenieur“ ist drei Jahre alt. Im Juni 2023 prägte swyx den Ausdruck für Entwickler, die nach dem Urknall der großen Sprachmodelle entstanden waren. Anfangs sprach man von „Prompt Engineering“, doch die Disziplin entwickelte sich rasant. Die Weltausstellung 2026 zeigte: Statt über einzelne Modelle zu diskutieren, ging es um Systeme, die Modelle in Produktion bringen. Es geht nicht mehr darum, ob KI Ingenieure ersetzt, sondern wie sie sie verstärken. Das erfordert ein neues Verständnis von Architektur, Kontrolle und Zusammenarbeit.

1. Vom Agenten zum Geschirr: Der Aufstieg des Harness Engineerings

Eine Entwicklung lässt sich an zwei Aufsätzen von Lilian Weng ablesen. Ihr Artikel von 2023 über „LLM-betriebene autonome Agenten“ beschrieb Planung, Gedächtnis und Werkzeuggebrauch. Projekte wie AutoGPT und BabyAGI waren Machbarkeitsstudien. Ihr neuer Aufsatz von 2026, „Harness Engineering for Self-Improvement“, verfolgt einen anderen Ansatz. Das System um das Modell herum sei genauso wichtig: das „Geschirr“, das Arbeitsabläufe, Kontext, Berechtigungen, Evaluation, dauerhaften Zustand und kontinuierliche Verbesserung verwaltet. KI-Engineering hat sich vom Prompten zum Entwickeln zuverlässiger Systeme verlagert.

Diese Verschiebung war auf der Konferenz allgegenwärtig. 2023 drehte sich jede zweite Diskussion um AutoGPT, 2026 war das kaum mehr Thema. Stattdessen ging es um Claude Code, Codex, Gemini CLI, Cursor und Warp – und die Infrastruktur für zuverlässige Codierungsagenten in der Produktion. Der Hype um vollständige Autonomie ist einer nüchternen Erkenntnis gewichen: Komplette Autonomie ist nicht nur unzuverlässig, oft auch nicht wünschenswert. Die Botschaft: Agenten sollen den KI-Ingenieur ergänzen, nicht ersetzen.

2. Codierungsagenten werden zum Standard – aber mit menschlicher Aufsicht

Der größte praktische Wandel seit dem ersten Gipfel ist die tägliche Interaktion mit KI. 2023 bedeutete KI-gestützte Programmierung meist Codevervollständigung. Heute gibt es Werkzeuge wie Claude Code, Codex, Gemini CLI, Cursor und Warp. Diese Codierungsagenten verstehen ein übergeordnetes Ziel, erkunden eine Codebasis, ändern mehrere Dateien, führen Tests aus und iterieren selbstständig. Das ist Alltag vieler Teams.

Mit größerer Autonomie wächst die Notwendigkeit der Kontrolle. In seiner Keynote betonte Thariq Shihipar von Anthropic: Modelle werden gezüchtet, nicht entworfen. Claude werde auf ungleichmäßige Weise klüger. Das bringt das Dilemma auf den Punkt: Wie baut man Systeme, um die Ausgaben unberechenbarer Modelle zu evaluieren? Die Antwort liegt in der Architektur der Schleifen.

3. Loop-Engineering: Die Kunst der Kontrollschleifen

Das Schlagwort der Konferenz war „Loops“. Innere Schleifen, äußere Schleifen, Feedback-Schleifen. Die Frage: Wie viel Kontrolle sollen Agenten haben? Viele Ingenieure setzen Agenten in eine innere Schleife, während der Mensch in der äußeren Schleife bleibt. Roland Gavrilescu von Introspection erklärte „Autoresearch“: Eine innere Schleife interagiert mit Nutzern, eine äußere Schleife studiert und wartet das System. Der Mensch bleibt verantwortlich für Richtung und Entscheidungen.

„Loop Engineering“ fiel mehrfach – die Aufgabe des KI-Ingenieurs, diese Schleifensysteme zu bauen. Peter Steinberger von OpenClaw betonte: Der Agent läuft die innere Ausführungsschleife, er selbst gibt die Richtung vor. In einer Debatte wurde diskutiert, ob vollständig autonome Agenten Schleifen in der Realität managen können. Geoffrey Huntley sagte: „Wir sind heute wie Lokomotivführer. Es ist unsere Aufgabe, die Lokomotive auf den Schienen zu halten.“ Der Ingenieur bleibt der Treiber.

4. Forward Deployed Engineers und die Software-Factory

Eine neue Rolle zeigt, wie diese Zusammenarbeit in Unternehmen Einzug hält: der „Forward Deployed Engineer“ (FDE). Diese Ingenieure arbeiten direkt mit Organisationen zusammen. Natalie Meurer von Sierra erklärte: Die Implementierung von KI erfordert viel Orchestrierung. Unternehmen wollen wissen, wie sie ihr agentisches Ökosystem warten können. Pauline Brunet von Cursor sprach über die Arbeit ihrer FDEs. Ziel: nach Ende des Engagements einen klaren ROI hinterlassen.

Ein weiterer Begriff war „Software Factory“. Bei Cursor bedeutet das langlebige Agenten, die Menschen durch den Entwicklungsprozess begleiten. Organisationen entscheiden, welche Teile automatisiert werden und wo Menschen eingreifen. Zach Lloyd von Warp erklärte: Mit „Oz“ kann man Repositories auswählen, Lebenszyklen automatisieren und menschliche Prüfpunkte festlegen. Nicht jede Änderung muss geprüft werden, aber risikoreiche schon.

5. Context Engineering: Das unsichtbare Rückgrat der KI

Ein oft übersehener Trend ist das „Context Engineering“. Prukalpa Sankar von Atlan zeigte, wie Kontext aus Geschäftssystemen in ein gemeinsames Unternehmenshirn fließt und an Agenten weitergegeben wird. Es geht darum, die richtigen Daten zur richtigen Zeit an das Modell zu liefern. Unternehmen kämpfen mit der Integration ihrer Daten. Ohne gutes Kontext-Management bleiben selbst die besten Modelle stumpf.

Pauline Brunet warnte: Die Unternehmensadoption von KI ist noch auf frühe Anwender konzentriert. Die Herausforderung für FDEs ist, die richtigen Verfechter zu finden. Der kulturelle Wandel braucht Zeit. Eine Erkenntnis aus der World’s Fair 2026: KI-Engineering ist keine Disziplin für isolierte Tüftler mehr. Es ist eine Systemfrage, die verschiedene Experten an einen Tisch bringt.

Wer in der Softwareentwicklung arbeitet, kommt an diesen Trends nicht vorbei. Der Weg vom Prompt Engineering zum Loop Engineering zeigt: KI muss in robuste Systeme eingebettet werden. Entwickler entwerfen Schleifen, bauen Harnesses und geben die Richtung vor. Die Werkzeuge sind da. KI-Engineering wird zur Kernkompetenz der Softwareentwicklung.

Quelle: latent.space