Kategorie: Erklärer

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

Kennt ihr das? Ein KI-Assistent wie ChatGPT oder Claude schreibt kluge Texte, erstellt Zusammenfassungen, schmiedet Pläne. Aber bittet ihr ihn, eine E-Mail zu senden, einen Termin einzutragen oder eine Zeile im CRM zu aktualisieren – und er kann es nicht. Die KI denkt, aber handelt nicht. Sie spricht über Dinge, führt sie aber nicht aus. Viele KI-Werkzeuge bleiben dadurch im Arbeitsalltag halb nützlich. Genau hier setzt Zapier mit seinem neuen Angebot an, das MCP heißt. Es schließt die Lücke zwischen KI und Aktion – ohne dass ihr einen Befehl in der Kommandozeile eingeben müsst.

KI ist ein hochintelligenter Assistent, der in einem Raum voller Werkzeuge sitzt, aber keine Hände hat, um sie zu benutzen. Zapier MCP fungiert als Brücke, als Arm, der dem Assistenten die Werkzeuge reicht. Zapier selbst ist bekannt als das Schweizer Taschenmesser der Automatisierung: Es verbindet über 9.000 Apps miteinander, sodass Daten fließen – etwa von einer E-Mail direkt in eine Google-Tabelle. Mit MCP wird diese Verbindung auf KI-Sprachmodelle ausgeweitet. Ihr müsst nicht programmieren. Wenn ihr schon einmal einen Zap eingerichtet habt, könnt ihr MCP nutzen. Der Setup-Prozess führt euch Schritt für Schritt durch die Verbindung eures KI-Clients – Claude von Anthropic, ChatGPT von OpenAI, Cursor oder andere – mit euren Zapier-Konten. Die Verbindungen zu euren Apps sind automatisch da, sobald ihr sie in Zapier konfiguriert habt. Keine manuelle OAuth-Einrichtung, kein JSON-Gefrickel.

Was kann man damit anfangen? Drei Szenarien zeigen, wie MCP den Arbeitsalltag verändert. Ihr seid Führungskraft und müsst jeden Morgen mehrere Slack-Kanäle durchforsten. Mit MCP sagt ihr eurer KI: „Fass mir heute Morgen die wichtigsten Nachrichten aus allen Slack-Kanälen zusammen.“ Die KI greift auf Slack zu, liest die relevanten Threads und liefert eine Zusammenfassung in zwei Minuten. Ihr seid Vertriebsmitarbeiter und habt in einer Stunde ein Kundengespräch. Statt selbst E-Mails, CRM-Einträge und Chat-Verläufe zu durchsuchen, sagt ihr: „Bereite mir ein Briefing für das Meeting mit Müller GmbH vor.“ Die KI holt Daten aus Salesforce, Gmail und Teams und erstellt ein übersichtliches Dokument. Ein Executive Assistant könnte per Sprachbefehl einen Termin für mehrere Personen buchen – die KI prüft die Kalender, findet eine freie Zeit und trägt den Termin ein. Kein Hin und Her mehr.

Die technische Umsetzung ist einfach. Nach der Verbindung eures KI-Clients mit Zapier MCP erscheinen eure vorhandenen App-Integrationen automatisch. Ihr müsst nicht jede App einzeln neu autorisieren. Sagt ihr der KI „Sende eine E-Mail an Max Mustermann mit dem Betreff ‚Projektupdate‘ und füge die Tabelle aus Google Sheets ‚Status‘ an“, führt die KI die Aktion über Zapier aus – und ihr seht das Ergebnis bestätigt. Die KI muss nicht wissen, wie die API von Google Sheets funktioniert. Zapier MCP übersetzt den natürlichsprachlichen Befehl in die nötigen Schritte und führt sie aus. Das System basiert auf dem MCP-Protokoll, einem offenen Standard von Anthropic, der auch mit anderen KI-Modellen funktioniert. Zapier hat diesen Standard mit seiner App-Bibliothek kombiniert. So entsteht eine Plattform, die mit jedem KI-Assistenten zusammenarbeitet – egal ob ihr heute Claude, morgen ChatGPT oder übermorgen einen neuen Anbieter nutzt. Die Verbindung bleibt gleich.

Ein wichtiger Punkt ist die Sicherheit. Zapier MCP baut auf der gleichen Infrastruktur auf, die das Unternehmen seit über 13 Jahren für Automatisierungen verwendet. Eure Zugangsdaten werden nicht an die KI weitergegeben. Stattdessen autorisiert ihr, welche Apps die KI in welchem Umfang nutzen darf – etwa nur lesend oder auch schreibend. Ihr könnt Aktionen blocken oder erlauben und habt ein vollständiges Historien-Log. Für Unternehmen bietet Zapier Governance-Features: IT-Abteilungen können zentral steuern, welche KI-Tools auf welche Daten zugreifen dürfen. Das ist relevant, wenn Teams unterschiedliche KI-Assistenten verwenden. Statt jede Integration einzeln zu verwalten, gibt es einen zentralen Hebel. Zapier gibt an, SOC 2 Type II zertifiziert zu sein. Die Kontrolle bleibt bei euch – die KI kann nur das tun, was ihr explizit erlaubt.

Zu den Kosten: MCP ist kein separates Produkt mit eigener Preisliste. Es ist in allen Zapier-Plänen enthalten. Jeder Tool-Aufruf über MCP verbraucht zwei Tasks aus eurem vorhandenen Task-Kontingent – dem gleichen Budget, das auch eure Zaps nutzen. Habt ihr bereits einen Zapier-Account, könnt ihr MCP sofort testen, ohne neuen Vertrag oder Beschaffungsprozess. Das ist ein Vorteil gegenüber vielen Konkurrenzangeboten, die teure Enterprise-Lizenzen verlangen oder separate Abrechnung nutzen. Für Einsteiger empfiehlt Zapier, mit Claude zu beginnen, weil die Einrichtung dort besonders reibungslos ist. Aber auch ChatGPT oder Cursor sind möglich.

Zapier MCP löst ein zentrales Problem der aktuellen KI-Landschaft: KI kann analysieren und generieren, aber sie handelt nicht. Mit MCP wird sie zur Hand. Ihr könnt eure KI bitten, einen Lead in Salesforce anzulegen, eine Notiz in Notion zu erstellen oder eine Bestellung in Shopify auszulösen. Die Zahl der möglichen Aktionen ist groß, weil Zapier über 30.000 Aktionen in über 9.000 Apps bereitstellt. Entwickler können auf das MCP-Protokoll aufbauen und eigene Erweiterungen programmieren – Zapier stellt eine technische Dokumentation und ein SDK zur Verfügung. Ihr müsst kein Entwickler sein, um davon zu profitieren. Die Komplexität verschwindet im Hintergrund. Was bleibt, ist ein KI-Assistent, der nicht nur redet, sondern auch anpackt.

Natürlich gibt es Grenzen. Die KI kann nur auf Apps zugreifen, die ihr mit Zapier verbunden habt. Sie führt nur Aktionen aus, die ihr autorisiert habt. Das ist gut für die Sicherheit, bedeutet aber, dass ihr euer App-Ökosystem bewusst aufbauen müsst. Wer noch nie einen Zapier-Account hatte, muss zunächst die grundlegenden Verbindungen herstellen. Das ist einmalige Arbeit. Danach könnt ihr eurer KI beliebige Arbeitsaufträge erteilen – und sie wird sie umsetzen, solange die Aktion in eurer App-Landschaft existiert. Die Frage ist nicht mehr, ob die KI kann, sondern ob ihr sie richtig bittet.

Zapier MCP ist ein Schritt in eine Richtung, in der KI nicht mehr nur Gesprächspartner ist, sondern ein aktiver Teil eures digitalen Arbeitsplatzes. Es löst das Problem der KI, die nicht handeln kann. Die Integration ist einfach, die Kosten sind transparent, die Kontrollmöglichkeiten sind umfassend. Für alle, die mit KI experimentieren und wünschen, dass sie praktische Arbeit abnimmt, ist MCP einen Blick wert. Es ist ein Werkzeug, das genau dort ansetzt, wo die meisten KI-Tools heute noch scheitern: an der Schnittstelle zwischen Gedanke und Tat.

Quelle: zapier.com

Stellen Sie sich vor, Sie mieten eine Wohnung, und die Miete wird jeden Monat günstiger – bis sie fast nichts mehr kostet. Gleichzeitig können Sie die Wohnung kaufen, ohne den Vermieter um Erlaubnis zu bitten. Genau das passiert gerade mit Künstlicher Intelligenz. Der neueste Report von Mozilla, verfasst von CTO Raffi Krikorian, zeichnet ein klares Bild: Open-Source-KI hat die geschlossenen Modelle nicht nur eingeholt, sondern in der Breite überholt. Die Zukunft gehört offenen Modellen, aber der Weg dorthin ist noch nicht geebnet.

Die Lücke schließt sich – und öffnet sich wieder

Krikorian erinnert an die Anfänge des Webs, als eine Firma die Tür zur digitalen Welt kontrollieren wollte. Die Open-Source-Community sorgte damals dafür, dass niemand allein den Zugang besitzt. Heute spielt sich ein ähnliches Drama in der KI-Welt ab. Die Kennzahlen des Reports: Die sogenannte „Capability Gap“ zwischen offenen und geschlossenen Modellen ist auf wenige Prozentpunkte geschrumpft. Vor zwei Jahren betrug sie noch über acht Prozent. Im August 2024 lag sie bei 0,5 Prozent – praktisch gleichauf. DeepSeek-R1 zog zeitweise sogar an den besten US-Modellen vorbei. Aktuell hat sich der Abstand auf 3,3 Prozent vergrößert, weil geschlossene Modelle bei Reasoning und langen Kontexten die Nase vorn haben. Aber das ist ein Durchschnitt. Beim Programmieren, bei der Anweisungsbefolgung und bei allgemeinem Wissen sind offene Modelle gleich gut oder besser. Nicht mehr die Frage ist, ob Open Source gut genug ist, sondern welches Modell zu Ihrer Aufgabe passt.

Der Preisverfall: 50-mal günstiger in drei Jahren

Ein weiterer Befund: Die Kosten für Inferenz sind in 36 Monaten um das 50-Fache gefallen. Was früher 20 Dollar pro Million Tokens kostete – etwa die Leistung von GPT-4 –, liegt heute bei 40 Cent. Das ist schneller als der Preisverfall von PC-Rechenleistung oder Internetbandbreiten in den Dotcom-Jahren. Krikorian vergleicht die Entwicklung mit dem Mooreschen Gesetz, nur dass die KI-Kurve noch steiler ist. Offene Modelle profitieren: Auf der Plattform OpenRouter fließen inzwischen die meisten Tokens durch offene Modelle. Die fünf volumenstärksten Modelle sind allesamt Open Weights – darunter DeepSeek, Xiaomi, Tencent und MiniMax. Geschlossene Modelle wie Claude von Anthropic folgen erst auf den Plätzen sechs bis neun. Das Verhältnis wöchentlicher Tokens zwischen chinesischen offenen und US-amerikanischen geschlossenen Modellen beträgt mehr als drei zu eins.

Adoption hoch, Produktion niedrig – die operative Lücke

Trotz dieser Erfolge zeigt der Mozilla-Bericht eine Schwachstelle: die operative Lücke. 79 Prozent der Entwickler, die KI-Funktionen in ihre Anwendungen einbauen, nutzen offene Modelle. Das ist mehr als bei geschlossenen (71 Prozent). Die Hälfte der Teams kombiniert beide Welten. Doch der Weg von der Entwicklung in die Produktion ist holprig. Nur 51 Prozent der Open-Source-Teams bringen ihre Modelle produktiv zum Laufen – gegenüber 63 Prozent bei geschlossenen. Das liegt nicht an der Modellqualität, sondern an fehlenden Werkzeugen für Betrieb und Vertrauen. Krikorian nennt die größten Hürden: Integration in bestehende Systeme, Wartung, Dokumentation und Deployment-Komplexität. Diese Herausforderungen sind in allen Regionen ähnlich. In Südamerika und Westeuropa nutzen Entwickler sogar häufiger geschlossene Modelle, weil der Aufwand für offene Modelle noch zu hoch ist.

Unternehmensgröße spielt eine Rolle – aber nicht die erwartete

Interessant: Die operative Lücke wird mit der Unternehmensgröße nicht kleiner. Bei kleinen Firmen (2–50 Mitarbeiter) schaffen 54 Prozent der Open-Source-Teams den Produktivbetrieb, bei großen Unternehmen (über 1.000 Mitarbeiter) gerade mal 57 Prozent. Bei geschlossenen Modellen steigt die Quote von 54 auf 73 Prozent. Große Firmen können sich durchkaufen – sie zahlen für Managed Services, die den Betrieb vereinfachen. Open Source hingegen wartet auf Werkzeuge, die niemand fertiggestellt hat.

Das Geschäftsmodell hinter der Offenheit

Der Report macht deutlich: Open-Source-KI ist kein Hobbyprojekt, sondern ein Milliardengeschäft. Die Liste der Finanzierungsrunden liest sich wie ein Who’s who der Tech-Szene. DeepSeek aus China sammelte 7,4 Milliarden Dollar bei einer Bewertung von über 50 Milliarden. Mistral AI aus Frankreich wuchs innerhalb von zwölf Monaten von 20 auf 400 Millionen Dollar Jahresumsatz. Databricks erreicht eine Run-Rate von 5,4 Milliarden Dollar. Daneben gibt es etablierte Erlösmodelle: Hosted Inference, Enterprise-Plattformen, On-Premises-Lizenzen, Fine-Tuning-Dienste und Tooling für KI-Agenten. Investoren wie Nvidia, Salesforce, Google und Tencent stecken Milliarden in den offenen Stapel. Das ist kein soziales Projekt – sondern Marktwirtschaft mit einem anderen Eigentumsmodell.

Der offene Stapel: Stark in der Leistung, schwach im Betrieb

Mozilla hat den gesamten Open-Source-AI-Stack analysiert – neun Schichten mit 48 Komponenten, basierend auf 1.361 Projekten. Das Urteil: Die Leistung ist stark (Bewertung 4 von 5), aber die betriebliche Reife ist schwach, besonders bei Standardisierung und Enterprise-Reife. Diese Kältezone zieht sich durch alle Schichten. Krikorian spricht von einer „wiederkehrenden kalten Kante“. Die Community hat hervorragende Modelle gebaut, aber die Werkzeuge, sie zuverlässig in Unternehmen zu betreiben, fehlen. Wer Open Source in der Produktion einsetzen will, muss viel Eigenarbeit investieren oder auf kommerzielle Anbieter wie Together AI oder Fireworks AI zurückgreifen.

Was das für dich bedeutet

Wenn du selbst KI-Anwendungen entwickelst oder einsetzt, ist die Botschaft klar: Du musst dich nicht mehr zwischen Leistung und Kosten entscheiden. Offene Modelle sind billig, leistungsstark und oft besser als geschlossene. Aber du musst den Betrieb organisieren. Die Werkzeuge dafür entstehen gerade – Plattformen wie Hugging Face, LangChain oder Modal bauen die Brücke. In ein bis zwei Jahren wird die operative Lücke wahrscheinlich geschrumpft sein, so wie zuvor die Leistungslücke. Mozilla ruft dazu auf, in offene Standards zu investieren und die Abhängigkeit von einzelnen Anbietern zu vermeiden. Die Geschichte des Webs lehrt uns: Offenheit gewinnt am Ende – aber nur, wenn wir sie aktiv gestalten. Teste offene Modelle, plane Zeit für Deployment und Tooling ein, und sei bereit, deine eigene Infrastruktur zu betreiben. Oder nutze einen Dienst, der das für dich erledigt. Die Wahl ist da – und sie wird immer leichter.

Quelle: stateofopensource.ai