KRÖTZSCHKI-Blog · Ohne Bullshit
Newsletter

Suchergebnisse für: „Claude“

  • Agent-Session-Transkripte sind kostbar: Warum Teams Claude-Code-Sessions wie Logfiles behandeln sollten

    Agent-Session-Transkripte sind kostbar: Warum Teams Claude-Code-Sessions wie Logfiles behandeln sollten

    Wer mit Claude Code arbeitet, hinterlässt bei jeder Sitzung eine Datei mit dem kompletten Gesprächsverlauf, abgelegt in einem versteckten Ordner auf der Platte. Nach 30 Tagen löscht Claude Code sie standardmäßig, und in den meisten Teams fällt das niemandem auf.

    Code kommt in ein Git-Repository, die Transkripte agentischer Coding-Sessions landen im Nichts, obwohl sie belegen, welche Tokens bezahlt wurden und welche Lektionen man sonst teuer nachlernt. So argumentiert Jacek Migdal von Quesma im Blog seines Unternehmens. Quesma bietet selbst ein Werkzeug an, das solche Sessions einsammelt; der Beitrag ist also auch Werbung in eigener Sache, das Werkzeug wird am Ende dieses Textes vorgestellt.

    Bevor es Observability gab, hat man sich per ssh auf den Server gesetzt und nach einem Absturz die Logs durchsucht. Auf dieser Stufe stehen die meisten Unternehmen bei der Arbeit mit Agenten. Sie sammeln keine Sessions aus Claude Code, Codex oder Cursor und lernen deshalb nichts aus dem Datensatz, der am ehesten verrät, wie ihre Entwickler mit Agenten umgehen. Im Folgenden geht es darum, was in so einem Transkript steht, warum die großen Anbieter davon profitieren und warum das Sammeln schwieriger ist als gedacht.

    Was ein Agent-Session-Transkript eigentlich ist

    Ein Transkript ist das Logbuch einer Sitzung. Es hält fest, welche Prompts gestellt wurden, welche Überlegungen der Agent angestellt hat, welche Werkzeuge er aufgerufen hat, welche Ergebnisse zurückkamen und was er am Ende geantwortet hat. Dazu kommen die Subagenten und Workflows, die eine Session ihrerseits gestartet hat. In der Forschung heißt so ein Verlauf Trajektorie.

    Ein Beispiel von Migdals eigenem Rechner: Unter ~/.claude/projects/ liegt ein Arbeitsverzeichnis von rund 295 Megabyte. Darin ein memory/-Ordner mit 37 Notizen, die der Agent über Sitzungen hinweg behält, eine Transkriptdatei mit 4,7 Megabyte und ein Ordner mit 10,4 Megabyte an Material, das die Session erzeugt hat. Dazu 24 Subagenten-Transkripte, zwei Tool-Ausgaben, die zu groß für den direkten Einbau waren, und ein Workflow-Skript samt Journal.

    Diese eine Datei umfasst 933 Turns. Man sieht darin abwechselnd Prompt, Reasoning, Antwort, einen Bash-Aufruf, das Ergebnis, einen weiteren Bash-Aufruf, wieder ein Ergebnis, dann das Lesen einer Quelldatei, erneut Reasoning und schließlich einen Workflow-Schritt, der ein bestimmtes Fehlerbild und die Optionen zur Wiederherstellung prüft. Andere Werkzeuge speichern Vergleichbares in ihren eigenen Formaten. Der Punkt ist überall derselbe: Der Code geht in git, das Transkript ins Nichts.

    Was die Anbieter längst verstanden haben

    Anthropic hat 200.000 eigene Claude-Code-Transkripte ausgewertet, um zu verstehen, wie Entwickler arbeiten, und der eigene Evaluationsleitfaden endet mit der Anweisung, die Transkripte zu lesen. Cursor formuliert offen, der eigene Ansatz nutze Agent-Sessions als Trainingsdaten. Replit nennt Trajektorien einen strategischen Kernvorteil. Diese Sätze fallen nicht nebenbei; sie beschreiben, wo der Wert tatsächlich entsteht.

    Auf Verbrauchertarifen werden Sessions zum Training herangezogen, sofern man nicht aktiv widerspricht. Genau diese Tarife liefern die günstigsten Tokens. Eine Analyse von Quesma zu Claude-Code-Preisen kommt zu dem Ergebnis, dass ein 200-Dollar-Max-Zugang ein Tokenvolumen lieferte, das zu API-Preisen rund 2.986 Dollar entspricht. Klauseln zum Trainingsverzicht und Zero Data Retention liegen auf den Business-Tarifen, wo die Rechnung ein Vielfaches beträgt. Metas Contributor-Stufe verlangt zwölfmal weniger pro Input-Token und lässt sich das mit der Erlaubnis bezahlen, Prompts und Completionen für künftige Modelle zu verwenden.

    Dass diese Daten begehrenswert sind, zeigt die unschöne Seite. Der Bedrohungsbericht von Anthropic vom September 2026 nennt sieben chinesische Labore, die Coding-Sessions durch Claude gespielt, Claude-Code-Nutzer umgeleitet und Transkripte von Proxy-Betreibern gekauft haben. Diese Betreiber speicherten den Austausch zwischen Nutzern und US-Modellen ohne Wissen oder Zustimmung der Betroffenen. Eine gemeinsame Warnung von NSA, CISA und FBI in derselben Woche nannte solche Kampagnen Destillation im industriellen Maßstab.

    Was sich aus Transkripten lernen lässt

    Die einfachste Auswertung ist die Frage nach dem Geld. Was hat ein einzelnes Repository gekostet, was ein Pull Request, was eine bestimmte Art von Arbeit? Wer das weiß, kann Kosten auf Forschung, Betrieb oder Vertrieb verteilen, Budgets prognostizieren und Abonnements passend zuschneiden, statt Lizenzen nach Bauchgefühl zu verteilen.

    Die zweite Frage lautet, was Kosten ohne Wert erzeugt. Ausführliche Dokumentation, zielloses Erkunden, lange Lizenzköpfe und geschwätzige Kommandoausgaben füttern alle den Kontext und beschleunigen, was man Kontextverfall nennt. Ein Team erkennt schnell, welche Dateien oder Gewohnheiten den Kontext zumüllen, ohne je zur Lösung beizutragen.

    Daraus folgen Anweisungen und Skills. In einem von Quesma angeführten Fall lösten Agenten nach einer Änderung an der AGENTS.md 91 Prozent der Aufgaben mit Review-Schritt, ohne Review nur 43 Prozent. Ebenso lässt sich eine Änderung im Nachhinein erklären: Man sieht, wie ein Agent einen Pull Request gebaut, was er geprüft und was das Ganze gekostet hat, inklusive eines gegnerischen Sicherheitsreviews, falls es eines gab.

    Selbst banale Fehlkonfigurationen werden sichtbar. In einem RTK-Benchmark wiederholte ein DeepSeek-Versuch denselben Befehl 339 Mal und lief zwölf Minuten lang in denselben Fehler. Die Aufgabe galt am Ende als bestanden, zum etwa neunfachen Preis, und die Ursache war ein Fehler im Werkzeug selbst, der in der nächsten Version behoben wurde. Teilnehmer eines Hackathons fanden ähnlichen Leerlauf im SWE-chat-Datensatz: Agenten starteten Tests neu, ohne den Code geändert zu haben, oder lasen nach einer Kompaktierung dieselben Dateien erneut.

    Die Intelligenz eines Teams steckt in seinen Vorlieben

    Es gibt kein einziges Maß für Intelligenz. Menschen und Firmen tragen jeweils eigenen Kontext und stilles Wissen mit sich. Ein Investor belohnt Forschung, die jede Alternative abwägt. Ein Spieldesigner belohnt zehn schnell verworfene Ideen mehr als eine polierte. Ein Zahlungsteam belohnt gründliche Tests statt Tempo. Branchenbenchmarks messen die Spitze des Machbaren, nicht den eigenen Anwendungsfall.

    Hier kommen die Sessions ins Spiel, in denen ein Entwickler den Agenten korrigiert oder zurückgerollt hat. Sie sind fertige Evaluationen: genauer und billiger als synthetische Testfälle, und sie erlauben es, entlang von Modellen, Effort-Einstellungen, Skills und Anweisungen zu optimieren. Der eigene Geschmack, in Tests gegossen, wird zum Vorteil. Wer seine Session-Transkripte sammelt, hat diesen Rohstoff bereits im Haus.

    Ein zweiter Grund ist unangenehmer: Manche Systeme verhalten sich fremd. OpenAIs Agenten haben in einem Fall Hugging Face angegriffen, und Claude hat während Evaluierungen echte Organisationen kompromittiert, was erst auffiel, als Anthropic die eigenen Transkripte erneut las. Kleine Modelle scheitern anders: In Tests von Quesma pflanzte ein lokales Modell auf Anfrage in bis zu 95 Prozent der Fälle eine Hintertür ein, unabhängig von der Netzwerkisolation. Egal was schiefgeht, das Transkript hält fest, was gefragt wurde und was passiert ist. Wer nicht auf den nächsten Zwischenfall warten will, sollte diese Dateien aufbewahren und auf frühe Warnzeichen prüfen.

    Warum das Sammeln und Speichern schwer ist

    Es gibt drei Wege an die Daten, und jeder hat einen Haken. Der erste führt über den Anbieter. Dessen Priorität ist, das Modell vor Nachbau durch Wettbewerber zu schützen, und er verbirgt bereits Teile der Session: Anthropics vollständige Denkschritte, OpenAIs Kompaktierung, die Nachrichten von Codex an seine Subagenten. Unabhängige Harnesse spüren schon heute, wie wenig portabel Sessions sind. Offizielle Exporte wie die Compliance-API von Anthropic setzen Enterprise-Preise voraus und bringen viele Einschränkungen mit.

    Der zweite Weg ist ein Proxy dazwischen. Er muss von jedem Werkzeug angesteuert werden, und manche verweigern das. Claude Code verdrahtet seinen API-Endpunkt bei /remote-control fest, weshalb Nutzer des Headroom-Proxys Anthropic um eine Änderung baten. Ein Proxy verpasst außerdem viel: den lokalen Kontext, der einem Prompt seine Bedeutung gibt, und Abrechnungsdaten wie den verbrauchten Anteil am Wochenlimit.

    Der dritte Weg besteht darin, die Dateien von der Platte zu kopieren. Sie bleiben aber nicht ewig. Claude Code löscht sie standardmäßig nach 30 Tagen, und die Aufräumroutine hat schon eine Einstellung von 99.999 Tagen ignoriert und Sessions ohne Vorwarnung entfernt; beide Probleme sind weiterhin offen. Dazu kommt die Streuung: Agentisches Coding hat sich schneller ausgebreitet als jede Richtlinie. Teams mischen Anbieter und Harnesse, Firmenlizenzen und private Abos, Shadow IT ist die Regel, und manche Entwickler betreiben lokale Modelle wie Qwen.

    Ein naives rsync macht die Lage sogar schlechter. Agenten lesen .env-Dateien, fügen Tokens in Befehle ein und geben Zugangsdaten in Tool-Ausgaben aus, und all das landet im Transkript, das Claude Code im Klartext ablegt. Kopiert man solche Dateien auf ein geteiltes Laufwerk, hat man ein Berechtigungsleck gebaut. Die andere Hälfte ist Privatsphäre: Das Gespräch mit einem Agenten fühlt sich privat an. Firmen sollten diese Daten besitzen, sie vor dem Verlassen des Laptops bereinigen und festlegen, wer sie lesen darf und was dabei zu sehen ist.

    Was Quesma als Open Source bereitstellt

    Quesma argumentiert, dass das Sammeln selbst eine Commodity sein sollte. OpenTelemetry hat das für Observability vorgemacht: ein offener, anbieterneutraler Standard zum Einsammeln verteilter Traces. Agent-Sessions brauchen dasselbe, und deshalb hat Quesma den Shipper unter Apache 2.0 veröffentlicht.

    Das Programm ist rund 20 Megabyte groß, in Go geschrieben und wird einmal pro Rechner installiert. Es liest die Session-Dateien, die Claude Code, Codex und Cursor ohnehin schreiben. Es gibt nichts umzukonfigurieren, keinen Proxy und keine Hooks. Der Shipper bereinigt erkannte Zugangsdaten und personenbezogene Daten mit deterministischen regulären Ausdrücken und Entropieprüfungen nach dem Vorbild von gitleaks, verschlüsselt die Dateien mit dem öffentlichen Schlüssel der Organisation und lädt sie in einen eigenen Bucket, etwa bei Amazon S3.

    Der Ablauf bleibt bewusst schlicht: Der Rechner liest die .jsonl-Dateien, ersetzt Fundstücke durch Platzhalter, verschlüsselt und schickt das Ergebnis in den Objektspeicher. Ein Fleet Manager verteilt Einstellungen und Uploads über signierte URLs, sieht aber nie Dateiinhalte und kann Sessions nicht entschlüsseln. Quesma versteht sich als Verwalter, nicht als Eigentümer des Shippers, und will ihn mit wachsender Community in eine offene Governance überführen. Signierte Releases und MDM-Unterstützung sind vorhanden, was den Einsatz in Unternehmen erleichtert. Fertig ist heute die Sammlung, also der Weg vom Laptop bis in den eigenen Bucket. Geplant ist eine quelloffene ETL-Schicht, die Sessions verschiedener Agenten in ein gemeinsames Format bringt, darauf aufbauend eine eigene, nicht quelloffene Analytik, für die Quesma derzeit Pilotkunden sucht.

    Was heißt das konkret? Der praktische Kern ist unspektakulär und trotzdem dringend: Behandelt Agent-Session-Transkripte wie Logfiles oder Repository-Historie, nicht wie Wegwerfmaterial. Richtet die Sammlung ein, bevor die Löschfrist greift, bereinigt die Daten lokal, verschlüsselt sie und behaltet den Schlüssel selbst. Wer heute damit anfängt, hat in einem halben Jahr Kostenverläufe, funktionierende Eval-Sets und eine Antwort auf die Frage, wie die eigene Mannschaft mit Agenten arbeitet.

    Quelle: quesma.com

  • OpenRig: Wie ein Multi-Agenten-Harness Claude Code und Codex zu einem Team verbindet

    OpenRig: Wie ein Multi-Agenten-Harness Claude Code und Codex zu einem Team verbindet

    Wer mehrere Coding-Agenten parallel laufen lässt, etwa Claude Code und Codex in getrennten Terminals, verliert schnell den Überblick: Welcher Agent hat welche Aufgabe begonnen, wer sollte sie prüfen, und welcher Kontext gehört wozu? Nach einem Neustart ist dieser Zusammenhang oft weg. Hier setzt OpenRig an, ein Open-Source-Projekt auf GitHub, mit dem sich aus Claude Code, Codex und Pi ein eigenes Netzwerk von Agenten aufbauen lässt.

    Der Autor von OpenRig formuliert den Unterschied in einem Satz: Ein Harness umschließt ein Modell, ein Rig umschließt deine Harnesses. Das beschreibt, worum es geht. Du startest nicht mehr einzelne Coding-Agenten, sondern eine Mannschaft, die als System funktioniert. Wer schon länger mit KI-Coding-Agenten arbeitet, kennt das Problem: Ein einzelner Agent ist mächtig, aber sobald mehrere parallel laufen, entsteht Chaos.

    Was OpenRig von einem einzelnen Agenten unterscheidet

    Ein KI-Coding-Agent wie Claude Code oder Codex ist ein Werkzeug, das Anweisungen versteht und Code verändert. Er arbeitet in einer Sitzung, in einem Verzeichnis, mit einem Kontext. Für eine einzelne Aufgabe reicht das. Sobald aber ein Agent implementiert, ein zweiter prüft und ein dritter die Infrastruktur anpasst, brauchst du eine übergeordnete Ebene, die weiß, wer was tut. Diese Ebene ist OpenRig.

    Der Autor beschreibt sein System als Schicht über den Harnesses, nicht als Ersatz. Claude Code und Codex laufen weiter wie gewohnt, nur unter der Regie eines Daemons, der ihre Sitzungen kennt, ihre Rollen verwaltet und ihre Kommunikation weiterleitet. Statt loser Terminals entsteht ein beständiges Team, das einen Neustart übersteht und sich gegenseitig Nachrichten schicken kann.

    Die Rollenverteilung ist schlicht. In der Einsteiger-Anleitung steht ein Zweier-Team im Mittelpunkt: ein „Owner“, der eine Aufgabe umsetzt, und ein „Checker“, der die Änderung überprüft. Du sprichst mit dem Owner, der Owner koordiniert den Checker, am Ende bekommst du ein Ergebnis samt Review. Ein nüchternes Modell für ein Feld, in dem sonst gern von autonomen Agentenschwärmen die Rede ist.

    Das Agenten-Team in YAML definieren

    Die Topologie eines Teams wird nicht im Terminal zusammengeklickt, sondern in einer Datei beschrieben. OpenRig nennt dieses Format RigSpec und baut darauf Konzepte wie Pods, Edges und Continuity-Policies auf. Pods sind Gruppen zusammengehöriger Plätze (im Projektjargon „Seats“), Edges beschreiben, wie diese Plätze miteinander verbunden sind und wer wem schreiben darf. Continuity-Policies legen fest, wie ein Team einen Neustart übersteht.

    Wer schon CI-Pipelines oder Kubernetes-Manifeste geschrieben hat, erkennt das Muster: Zustand wird deklarativ beschrieben, das Werkzeug kümmert sich um die Ausführung. Ein Agententeam, das man per YAML definiert, lässt sich versionieren, teilen und reproduzieren. Das fehlt, solange jeder Agent als handgestartete Terminal-Sitzung existiert. Der Start läuft dann mit einem Befehl, rig up, der die nötigen tmux-Sitzungen, Harnesses und Startdateien anlegt und prüft, ob alles bereit ist.

    Das ist nicht nur ein Startskript. OpenRig erkennt bestehende Claude-Code- und Codex-Sitzungen in tmux und übernimmt sie in ein verwaltetes Rig. Man muss also nicht bei null anfangen. Auch der umgekehrte Weg ist vorgesehen: rig down –snapshot friert die aktuelle Topologie ein, rig up <name> holt sie wieder hervor.

    Die TUI als Kontrollzentrum

    Ohne eine Übersicht wäre ein Team aus mehreren Agenten kaum zu überblicken. OpenRig liefert deshalb eine Terminal-Oberfläche, die dieselben Rigs einmal als Graph und einmal als Tabelle zeigt. In der Tabelle stehen die einzelnen Plätze mit Laufzeit, Modell, Kontext und Zustand. Wer will, öffnet einen bestimmten Platz und sieht im Detail, was gerade passiert. Unspektakulär, im Alltag aber entscheidend.

    Zur Kommunikation zwischen den Agenten gibt es drei Befehle, die sich leicht merken lassen: rig send schickt eine Nachricht an einen bestimmten Platz, rig broadcast an mehrere, und rig chatroom öffnet einen gemeinsamen Raum. Wer selbst in einem Terminal tippt und nicht durch automatische Nachrichten unterbrochen werden will, kann mit rig seat set-typing-guard einen Platz schützen. Automatische Nachrichten werden dann zurückgehalten, statt mitten in die eigene Eingabe zu platzen.

    Das Dashboard lässt sich geteilt oder unabhängig öffnen. Ein geteiltes Dashboard verschwindet nicht, wenn man das Fenster schließt. Ein Detail, das darüber entscheidet, ob man ein Werkzeug ständig neu startet oder im Hintergrund laufen lässt.

    Was OpenRig auf deiner Maschine verändert

    Die README enthält einen eigenen Abschnitt: „What OpenRig changes on your machine“. Den sollte man lesen, bevor man irgendetwas installiert. OpenRig schreibt Konfiguration in Vertrauensdateien, legt Hooks an und erweitert Dateien wie ~/.tmux.conf, ~/.claude.json und die Codex-Konfiguration unter ~/.codex/config.toml.

    Konkret: Beim Start eines Rigs werden Workspace-Trust-Einstellungen gesetzt, Codex-Hooks aktiviert und Vertrauens-Hashes für bestimmte Befehle vorab eingetragen. Claude Code bekommt einen Statusline-Befehl und ausgewählte Activity-Hooks in die lokale Settings-Datei geschrieben. Die Aktivitäts-Relays senden Ereignistyp, Sitzungskennung und Zeitstempel an den eigenen Daemon, ausdrücklich ohne Prompt-Text und ohne Tool-Argumente. Wer Datenschutz ernst nimmt, sollte diese Liste lesen. Provider-Dateien und Instanz-Zustand sind getrennt, aber ein geänderter OPENRIG_HOME-Pfad isoliert die Provider-Konfiguration nicht automatisch.

    Vor dem ersten Start sollte man die betreffenden Dateien sichern. Manche Schreibroutinen behandeln unlesbare Einstellungsdateien als leere Objekte, und eine Garantie zur Wiederherstellung gibt es nicht. Der Befehl rig setup –dry-run zeigt den geplanten Eingriff an, ohne ihn auszuführen, deckt aber nicht jeden späteren Starteffekt ab.

    Berechtigungen: Der Punkt, an dem es ernst wird

    Ein Multi-Agenten-System für Coding-Agenten darf Dateien ändern, Befehle ausführen und im Grunde alles tun, wozu ein Agent eben in der Lage ist. OpenRig löst das nicht dadurch, dass es pauschal alles erlaubt. Der Autor beschreibt mehrere Stufen: Die Standardeinstellung für Codex ist ein Sandbox-Modus mit Schreibzugriff auf den Workspace, Claude Code startet mit --permission-mode acceptEdits. Ein vollständiger Bypass ist möglich, aber ausdrücklich nicht die Voreinstellung.

    Für einzelne Plätze lässt sich mit rig seat set-permissions ein auditiertes Modell wählen, das beim nächsten Start greift. Eine solche Auswahl verändert den laufenden Prozess nicht. Wer denkt, ein Befehl schalte sofort schärfere Rechte frei, täuscht sich. Gewünschte Einstellung und zuletzt verwendete Startargumente werden getrennt angezeigt, und keine der beiden Angaben beweist, dass die native Durchsetzung greift.

    In einem Umfeld, in dem Agenten gern als magische Helfer dargestellt werden, sagt der Autor klar, was sein Werkzeug kontrolliert und was nicht. Ein Multi-Agenten-Harness ist kein Sicherheitskonzept. Es ist eine Verwaltungsschicht, die dir den Überblick erleichtert und dich zwingt, dich mit Berechtigungen auseinanderzusetzen.

    Für wen sich der Einstieg lohnt

    OpenRig läuft auf macOS und Linux, benötigt Node.js 22 oder 24 und tmux. Auf Apple-Silicon-Macs empfiehlt der Autor Node.js 22, nativer Windows-Support fehlt bislang, WSL2 ist ungetestet. Die Installation erfolgt global über npm mit @openrig/cli, alternativ mit Bun. Danach folgt der erwähnte Trockenlauf, bevor etwas verändert wird.

    Wer nur gelegentlich einen einzelnen Coding-Agenten nutzt, braucht das nicht. Wer aber regelmäßig mehrere KI-Coding-Agenten parallel laufen lässt, kennt das Problem der auseinanderdriftenden Terminals. OpenRig macht aus verstreuten Sitzungen ein adressierbares Team, in dem du den Überblick behältst, in dem Aufgaben nachvollziehbar ankommen und in dem ein Neustart nicht bedeutet, alles neu aufzusetzen.

    Der Autor beschreibt den Einstieg klein: ein Repository, eine nützliche Änderung, ein Owner, ein Checker, ein überprüftes Ergebnis. Die Vorstellung, man definiere heute ein Agenten-Team in YAML und morgen erledige es die halbe Codebasis, hält der Praxis selten stand. Ein Rig aufzusetzen heißt, sich Gedanken zu machen: Wer prüft wen, welche Rechte bekommt welcher Platz, was passiert beim nächsten Reboot. Diese Fragen sind wichtiger als jeder zusätzliche Agent.

    Quelle: github.com

  • Claude-Schreibstil nachgemessen: Was Opus 5.5 wirklich besser macht

    Claude-Schreibstil nachgemessen: Was Opus 5.5 wirklich besser macht

    „We fixed the writing“ – mit diesem Satz kommentierte Sholto Douglas von Anthropic den Start von Opus 5.5. Sein Kollege Tom Brown brachte dasselbe in vier Wörter: „we fixed the accent.“ Ein Akzent ist ein gutes Bild dafür, und ein verdächtiges: Akzente verschwinden nicht per Ankündigung. Man kann höchstens zählen, wie oft einer noch durchbricht. Genau das hat ein Entwickler bei Arize gemacht und die Ankündigung in einen kompletten Eval-Lauf übersetzt.

    In der offiziellen Mitteilung heißt es, man habe „major improvements to the way Opus 5.5 writes and communicates“ erzielt, eines der häufigsten Feedback-Themen zu Opus 5, und das Modell sei „less likely to use jargon or idiosyncratic phrases“. Das Fachmagazin The Decoder machte daraus die Schlagzeile, Anthropic verspreche weniger „Claudish“. Solche Sätze sind keine Meinung, sondern eine Behauptung, die man testen kann. Wer regelmäßig mit Claude schreibt, ist vom Ergebnis direkt betroffen.

    Claudismen: ein Akzent, den man nicht per Beschluss loswird

    Die Rede ist von Sätzen wie diesen: Etwas „isn’t just a tool, it’s a mindset“, ein Detail „is doing a lot of work“, und man solle kurz innehalten und das wirken lassen. Menschen schreiben selten so. Claude schon – und alle, die Claudes Ausgabe unverändert in einen LinkedIn-Post kopieren, ebenfalls. Der Autor des Tests arbeitet bei Arize, einem Anbieter von Evaluierungs-Werkzeugen. Seine erste Reaktion auf die Ankündigung war keine Zustimmung, sondern der Satz, den man in der Branche kennen sollte: Zeig mir den Eval.

    Bauchgefühl zählt nicht, egal ob es das eigene ist oder das eines Anbieters. Also baute er ein Projekt namens claude-compare und arbeitete denselben Loop ab, den man für jede Änderung an einem Agenten nutzen würde: einen Datensatz bauen, Experimente darüber laufen lassen, die Ausgabe von Hand annotieren, daraus einen Evaluator bauen und ihn laufen lassen. Das ist mehr Arbeit als eine Stichprobe mit drei Ausgaben. Anders kommt man aber nicht an ein belastbares Ergebnis.

    Der Versuchsaufbau: 20 eingefrorene Briefings, ein identischer Prompt

    Ein Datensatz ist die feste Menge von Eingaben, gegen die getestet wird. Jedes Experiment läuft über dieselben Beispiele, damit eine veränderte Punktzahl auf die getestete Änderung zurückgeht und nicht auf andere Eingaben. Für einen Schreibtest sind die Eingaben Schreibaufgaben: 20 Recherche-Briefings, jedes mit Notizen für einen Blogpost, damit genug Langtext zum Prüfen entsteht. Die Themen decken fünf Genres ab – Meinung, technische Erklärung, Tutorial-Einstieg, Nachrichtenanalyse, Produktankündigung – und fünf Domänen: KI, Reisen, Kochen, Spiele, Bücher.

    Ein Datensatz aus lauter KI-Themen hätte nur gezeigt, wie Claude über KI schreibt. Zwei Eigenschaften machen diese Sammlung belastbar. Sie ist eingefroren: Opus 5 hat jedes Thema einmal per Websuche recherchiert, die Briefings sind versioniert und per Hash gesperrt, und das schreibende Modell bekommt weder Werkzeuge noch Netzzugang. Und die Eingaben tragen den Stil nicht, den man messen will – sie bestehen aus Stichpunkten, damit Opus 5’ Eigenheiten nicht schon im Prompt stecken. Am Briefing hängt der ganze Test.

    Dann kommt das Experiment, also ein Durchlauf der Aufgabe über den gesamten Datensatz. Wer zwei Modelle vergleichen will, ändert zuerst nur das Modell und nagelt alles andere fest. Beide bekamen denselben Prompt, und die Effort-Stufe wurde auf medium fixiert, weil Opus 5 standardmäßig auf high läuft und Opus 5.5 auf medium – mit den Voreinstellungen hätte man zwei verschiedene Dinge gemessen. Zusätzlich prüfte die Testumgebung bei jeder Antwort, welches Modell tatsächlich diente. Weil Modellausgaben von Lauf zu Lauf schwanken, lief jedes Modell zweimal: vier Experimente, 80 Posts, rund 110.000 Wörter.

    Die Annotation: Claudismen sind keine Phrasen, sondern rhetorische Moves

    Annotationen sind menschliche Labels auf den Ausgaben, also die Grundwahrheit, an der sich später der Evaluator messen muss. Wer den Evaluator vor der Annotation baut, weiß nicht, was er eigentlich misst. Der Autor legte alle 40 Opus-5-Posts in ein einziges Textdokument und las sie komplett – 53.000 Wörter – und machte an jede Wendung, die ihn zusammenzucken ließ, einen Kommentar mit dem Wort Claudism. Am Ende standen 153 Markierungen in 38 der 40 Texte.

    Dann kam die Überraschung. Er hatte eine handschriftliche Liste der berühmten Claudismen: „load-bearing“, „delve“, „crucially“, „genuinely“ und so weiter. Diese Liste traf ganze neun der 153 Fundstellen. „Load-bearing“, die Phrase, über die sich alle lustig machen, kommt in 53.000 Wörtern Opus-5-Text dreimal vor. Was tatsächlich auffiel, waren rhetorische Bewegungen, nicht Wörter.

    Die größte Gruppe war die salience flag: etwa 48 Stellen, an denen der Text behauptet, etwas sei wichtig, statt zu zeigen, warum – „The interaction matters“, „a fact worth internalising“, „deserves a moment“. Danach folgten contrast reframes (etwa 30), also Umdeutungen der Form „It’s a topology, not a genre“, verdict intensifiers wie „the honest answer“ (rund 25), signposts, die eine Erkenntnis anmoderieren statt sie zu liefern (rund 20), stock metaphors (rund 10) und gotcha framing wie „the trap is“ (rund 7). Der Rest fiel in eine Sammelkategorie. Claudismen erkennen und vermeiden heißt also nicht, eine Wortliste zu verbieten. Man muss die Muster erkennen, nicht die Wörter.

    Vom Span-Judge zum Messwert

    Der erste Evaluator war ein LLM-Richter, der jedem Text eine Note von 1 bis 5 gab, wie sehr er nach Claude klingt. Schnell gebaut, kaum prüfbar: Wenn ein Text eine 4 bekommt, welche Sätze machen ihn zur 4? Eine Einzelnote lässt sich nicht gegen 153 menschliche Markierungen auflegen. Deshalb blieb die Variante, die jede gefundene Stelle als wörtliches Zitat zurückgibt, im selben Format wie die Annotationen. So kann man Zitat für Zitat gegen die eigenen Markierungen legen und die Trefferquote direkt messen.

    Auch die Kategorien stammen aus den Annotationen: salience flag, contrast reframe, verdict intensifier, signpost, gotcha framing und stock metaphor. Die Annotationen dienen zugleich als Testfälle – alle drei „load-bearing“-Sätze müssen gefunden werden, sonst gilt der Lauf als gescheitert. Drei weitere Entscheidungen sind auf fast jeden Evaluator übertragbar: Em Dashes brauchen kein Sprachmodell, das übernimmt ein reiner Code-Evaluator. Kein Modell darf die eigene Familie benoten; als Richter diente deshalb OpenAIs gpt-6-luna. Und weil Opus 5.5 rund acht Prozent länger schreibt, werden die Werte auf die Textlänge normalisiert: gezählt wird pro 1.000 Wörter.

    Das Ergebnis: Em Dashes fast bei null, Claudismen halbiert

    Der Em Dash ist tatsächlich verschwunden. Opus 5 setzt 12,9 Em Dashes pro 1.000 Wörter, Opus 5.5 verwendet zwei in seinen gesamten 57.000 Wörtern Ausgabe, also 0,05 pro 1.000 Wörter. Das sind 99,6 Prozent weniger. Hier zählt ein Code-Evaluator, da steckt kein Richterurteil und kein Spielraum drin. Brodie Robertson kommentierte das mit dem Satz, die Em Dashes seien gelöscht, er wiederhole, die Em Dashes seien gelöscht.

    Bei den übrigen Claudismen ist das Bild gemischt. Der Span-Judge fand 4,79 Claudismen pro 1.000 Wörter in Opus 5 und 2,38 in Opus 5.5 – ein Rückgang um die Hälfte, und jede einzelne Kategorie ging zurück. Verdict intensifiers fielen um 65 Prozent, stock metaphors um 70, contrast reframes um 56, salience flags um 44, signposts um 33. Nur das gotcha framing bewegte sich kaum, von 0,16 auf 0,13 – bei acht gegen sieben Vorkommen ist das zu dünn für eine Aussage. Der Abstand hält in jedem getesteten Genre und jeder Domäne.

    Für den Vergleich Opus 5 gegen Opus 5.5 heißt das: Die Ankündigung stimmt in der Richtung, aber nicht im Ausmaß. Salience flags sind in beiden Modellen der häufigste Claudismus, die Grundbewegung bleibt also erhalten, nur leiser. Wer den Stil verbessern will, sollte dort anfangen: bei Sätzen, die Wichtigkeit behaupten, statt sie zu belegen.

    Neue Ticks, getauscht statt abgelegt – und was „fixed“ konkret bedeutet

    Opus 5.5 hat sich außerdem neue Gewohnheiten zugelegt. Eine einfache Auszählung ergab etwa zweieinhalbmal so viele fett gesetzte Aufzählungseinstiege wie bei Opus 5, 35 Prozent mehr Dreierlisten und acht Prozent mehr Text. Ein Teil der alten Tics wurde also nicht abgelegt, sondern eingetauscht. Detail am Rande: Anthropics eigener Prompting-Leitfaden für Claude Fable 5.1 warnt vor „mannered prose“ und führt ausgerechnet „this point earns its keep“ als Beispiel an. Opus 5.5 schrieb trotzdem, eine Küchenmaschine „earns its counter space“ und eine Brattechnik „earns its place“.

    Der Akzent ist also leiser geworden, aber er ist nicht weg. „Fixed“ ist zu stark, „halbiert“ trifft es besser – und halbiert ist nicht null. Für alle, die mit Claude arbeiten, heißt das zwei Dinge. Erstens sinkt die Aufräumarbeit, wenn Claude-Texte weiterverwendet werden. Ein Filter gegen Em Dashes und das Entfernen von Wichtigkeitsfloskeln bleiben trotzdem sinnvoll. Zweitens zeigt der Aufbau, wie sich KI-Textqualität mit Evals messen lässt: eingefrorene Eingaben, ein Test pro Modell, Handannotation als Grundwahrheit, ein Evaluator, der Zitate statt Noten liefert. Ein Verbot einzelner Wörter erwischt neun von 153 Fällen. Wer die Muster misst, findet den Rest.

    Quelle: arize.com

  • Claude Opus 5.5 in Claude und Claude Code: Was der offizielle Leitfaden für die Praxis empfiehlt

    Claude Opus 5.5 in Claude und Claude Code: Was der offizielle Leitfaden für die Praxis empfiehlt

    Der offizielle Leitfaden für die erste Sitzung mit Claude Opus 5.5 nennt drei Handgriffe: die ganze Aufgabe in einer Nachricht übergeben, Aufforderungen zum gründlichen Nachdenken aus den Prompts streichen und am Ende eines langen Laufs zuerst lesen, was das Modell von der nutzenden Person braucht. Diese drei Punkte sind eine komprimierte Arbeitsanweisung, keine Marketingformel. Wer sie befolgt, arbeitet an wenigen Stellen anders – dort aber deutlich.

    Claude Opus 5.5 arbeitet deutlich länger eigenständig als sein Vorgänger, gibt offen Auskunft über seine Schritte und denkt vor jeder Antwort nach. Am besten lässt sich das mit einer Fachfirma vergleichen, die ein Gebäude saniert: Sie erhält den kompletten Auftrag, kennt die Abnahmebedingung, ruft nur an, wenn eine Entscheidung ansteht, führt auf der Baustelle eine Checkliste und übergibt am Ende einen Bericht. Diese fünf Punkte strukturieren den Leitfaden – und diesen Text.

    Die Ziellinie nennen, statt Zwischenschritte zu diktieren

    Die wichtigste Empfehlung: die gesamte Aufgabe in einer einzigen Nachricht übergeben. Statt einzelne Schritte vorzugeben, beschreibt man, wie das Ergebnis aussehen soll – die Ziellinie. Der Leitfaden nennt als Beispiel einen Umbau im Zahlungsverkehr: Jeder Endpunkt soll den neuen Client nutzen, der alte Client soll verschwinden, die Testsuite soll durchlaufen. Damit weiß das Modell, wann es fertig ist, und muss nicht raten.

    In Claude Code könnte dieser Auftrag so aussehen: Migriere die Payment-Endpunkte vom alten Client auf den neuen. Fertig heißt: Jeder Endpunkt nutzt den neuen Client, der alte Client ist gelöscht, und die Testsuite läuft durch. Melde dich nur, wenn ein Test aus einem Grund fehlschlägt, den du nicht erklären kannst. Der letzte Satz macht den Unterschied. Er verschiebt die Rückfragen von ständig auf nur dann, wenn es wirklich nötig ist.

    Der Grund liegt in der Ausdauer des Modells. Opus 5.5 arbeitet laut Leitfaden länger an mehrteiligen Aufgaben als Opus 5. Am meisten bringt das dort, wo eine Änderung durch ein großes Repository getragen werden muss, bis die Tests grün sind. Frühe Tester ließen es stundenlang an Programmieraufgaben arbeiten, ohne ständig einzugreifen. Wer den Auftrag in kleine Häppchen zerlegt, nimmt dem Modell diesen Vorteil.

    Eine zweite Eigenheit betrifft Gestaltungsaufträge. Ohne Vorgaben greift Opus 5.5 auf wenige Standardmuster zurück. Eine allgemeine Anweisung wie „vermeide ein generisches Aussehen“ tauscht laut Leitfaden meist nur ein Standardmuster gegen ein anderes. Hilfreicher ist eine konkrete Verbotsliste: kein cremefarbener oder gebrochen weißer Hintergrund, keine kursiven Akzentwörter in Überschriften, keine nummerierten Abschnittslabels im Stil „01 / 02 / 03“, keine Monospace-Labels, keine pillenförmigen Buttons. Danach sieht man sich an, was das Modell stattdessen gewählt hat, und ergänzt die Liste, wenn es wieder nicht passt.

    „Denk gründlich nach“ streichen und das Nachdenken dem Modell überlassen

    Claude Opus 5.5 denkt vor jeder Antwort nach und entscheidet selbst, wie viel Aufwand das braucht. Zeilen wie „denk gründlich nach“ oder „gehe Schritt für Schritt vor“ gehören deshalb gestrichen – nicht nur aus einzelnen Prompts, sondern auch aus gespeicherten Anweisungen. In Tests in einer Chat-Anwendung begannen die Antworten ohne eine solche Zeile früher, ohne dass die Qualität erkennbar litt. Man bittet also nicht mehr ums Denken – man bekommt es ohnehin.

    Für eine schnelle Auskunft zu einer einfachen Frage sagt man das besser direkt, etwa mit „Antworte direkt“. Wer in Claude Code steuern will, wie aufwendig nachgedacht wird, ändert nicht den Prompt, sondern den Aufwandsgrad – das ist der dafür vorgesehene Hebel. Prompt-Floskeln und Effort-Einstellung sind zwei verschiedene Werkzeuge, und der Leitfaden hält sie auseinander.

    Wenn dir mitten in einem Lauf etwas einfällt, musst du nicht neu starten. In Claude Code tippst du die Nachricht und drückst Enter, während Claude arbeitet, zum Beispiel: Behalte die alten Endpunktnamen zusätzlich als Alias bei. Der Leitfaden betont, dass Läufe länger dauern und ein Neustart dadurch mehr kostet als früher. Eine einzelne nachgeschobene Anweisung ist deshalb der günstigere Weg, solange die Grundrichtung stimmt.

    Lange Läufe steuern: Stopps regeln, Subagenten einteilen, Checkliste auslagern

    Opus 5.5 berichtet während der Arbeit, hält aber manchmal an: mit einer Zusammenfassung, die den nächsten Schritt nur nennt, ohne ihn zu gehen, mit dem Angebot fortzufahren oder mit einer Liste von Optionen, die die Arbeit gar nicht blockieren. Solche Stopps lassen sich benennen, und das Modell folgt diesen Anweisungen. Der Leitfaden schlägt dafür eine kurze Regel in der CLAUDE.md vor: Wenn ein Schritt meine Eingabe nicht braucht, mach weiter. Statusnotizen gehören in dieselbe Nachricht wie die nächste Aktion. Halte nur an, wenn du ohne mich nicht weitermachen kannst oder bevor etwas Destruktives passiert: Daten löschen, Force-Push oder Änderungen außerhalb dieses Repositorys. Die letzte Zeile sorgt dafür, dass die eigene Kontrolle erhalten bleibt; Berechtigungsabfragen für destruktive Befehle sollten zusätzlich aktiv bleiben.

    Antwortet man auf ein „Soll ich fortfahren?“ mit „weiter“, läuft die Aufgabe weiter. Passiert das häufig, hilft die Regel aus der CLAUDE.md. Wer lieber im Pair-Programming arbeitet, dreht die Vorgabe um und verlangt einen einzeiligen Plan vorab plus kurze Zusammenfassung am Ende. Opus 5.5 folgt laut Leitfaden beiden Varianten; man muss sich nur entscheiden.

    Für Audits, Migrationen oder Reviews über eine große Codebasis empfiehlt der Leitfaden, die Arbeit auf Subagenten zu verteilen und jedes Ergebnis prüfen zu lassen. Ein passender Auftrag lautet: Prüfe jeden Service in services/ auf den Retry-Bug aus dem verlinkten Issue. Gib jeden Service an einen eigenen Subagenten. Wenn ein Subagent Bericht erstattet, prüfe seine Belege, bevor du sie akzeptierst. Schließe mit einer Tabelle ab: Service, betroffen ja oder nein, Belege. Frühe Tester ließen Opus 5.5 auf diese Weise parallele Subagenten koordinieren, mit wenig Aufsicht.

    Für sehr lange Läufe rät der Leitfaden, die Aufgabenliste in eine Datei auszulagern: Führe eine Checkliste in TASKS.md. Hake jeden Punkt ab, wenn er erledigt ist, und ergänze alles Neue, das du findest. Warum das hilft: Ein langer Lauf füllt das Kontextfenster, und Claude Code fasst ältere Turns irgendwann zusammen. Eine Liste in einer Datei übersteht diese Komprimierung und zeigt auf einen Blick, was erledigt ist und was noch aussteht. Man liest also die Datei, nicht den Scrollback.

    Ergebnisse prüfen, bevor du sie übernimmst

    Am Ende eines langen Laufs liest man zuerst, was das Modell von dir will: eine offen gelassene Entscheidung, eine Freigabe für eine Änderung. Erst danach den Rest der Zusammenfassung. Opus 5.5 berichtet klarer über seine Arbeit als Opus 5 und benennt in einfacher Sprache, was es getan hat, was es gefunden hat und was es braucht. Wer das Format ändern will, schreibt es in die CLAUDE.md, etwa: Beende jeden Lauf mit drei Überschriften: Blocked on me, Changed, Found.

    Bevor ein Mensch den Diff liest, kann Opus 5.5 ihn oder einen Pull Request prüfen. Der passende Auftrag lautet: Prüfe den Diff dieses Branches gegen main. Liste nur Probleme auf, wegen derer du den Merge blockieren würdest. Nenne für jedes die Datei und Zeile, warum es falsch ist und wie man zeigt, dass es fehlschlägt. Ein früher Tester berichtete, Opus 5.5 habe selbst mit niedrigstem Aufwand mehr Fehler gefunden als Opus 5 mit hohem Aufwand, bei weniger Fehlalarmen. Außerdem erklärt es seine Änderungen in klarer Sprache, was Pull-Request-Beschreibungen leichter prüfbar macht.

    Für Recherche und Analyse lohnt eine zusätzliche Anweisung: Markiere alles, was du nicht bestätigen konntest, und sag, wo du gesucht hast. Ein ehrliches „Das konnte ich nicht finden“ ist wertvoll, und wenn man danach fragt, findet man es auch leichter im Text. Der Hinweis funktioniert in einem Recherchebericht genauso wie in Claude Code.

    Arbeiten in den Claude-Apps: Bilder, lange Dokumente, fertige Dateien

    Zuerst der Blick auf die Modellauswahl: Dort sollte Claude Opus 5.5 stehen. Für Diagramme, Screenshots und Folien gilt dann die einfache Regel, das Material anzuhängen statt Zahlen abzutippen. Opus 5.5 liest Charts, Diagramme und Screenshots genauer als Opus 5, ohne dass es dafür zusätzlicher Schritte bedarf. Es versteht auch Bedeutung, die von der Position im Bild abhängt: welche Kästen ein Pfeil verbindet, was sich zwischen zwei Versionen eines Diagramms geändert hat oder wann ein Termin in einem Kalender-Screenshot beginnt und endet. Eine konkrete Frage wie „Welche dieser Services rufen die Billing-API direkt auf?“ nutzt das am besten aus.

    Lange Dokumente lassen sich gezielt auf Widersprüche prüfen: Prüfe dieses Deck auf alles, was sich widerspricht: Zahlen, Daten, Namen. Zitiere jedes Problem und nenn die Stelle. Laut Leitfaden fiel dem Modell in einem langen Planungsthread ein Datum auf, das auf den falschen Wochentag fiel, und in einer Präsentation ein Diagramm, das nicht zu den Zahlen passte. Wer eine Tabelle oder ein Dokument braucht, fragt nach der Datei und nicht nach einer Gliederung; die erzeugten Dateien brauchen vor dem Teilen weniger Nacharbeit als bei Opus 5. Ein Beispiel: Mach daraus eine Tabelle, die ich teilen kann: eine Zeile pro Anbieter, mit Spalten für Kosten, Vertragsende und Verantwortliche.

    In langen Chats kann es vorkommen, dass Opus 5.5 eine frühere Antwort noch einmal durchgeht, während es über eine kurze Rückfrage nachdenkt. Das bremst die Antwort. Dagegen hilft in den Projektanweisungen der Satz: Was du einmal beantwortet hast, gilt als erledigt. Konzentriere dich auf meine aktuelle Frage und geh nicht auf eine frühere Antwort zurück, außer ich frage danach oder weise auf ein Problem hin. In Projekten für lange Analysen lässt man diese Anweisung besser weg, weil dort ein späterer Schritt durchaus einen Fehler in einem früheren aufdecken kann.

    Markierte Nachrichten: Schutzmechanismen und der Wechsel auf ein älteres Modell

    Claude Opus 5.5 ist das erste Opus-Modell, das mit Bio- und Cyber-Schutzmechanismen auf dem Niveau von Fable startet. In den Claude-Apps und in Claude Code wandern die meisten markierten Nachrichten zu einem älteren Modell, und die Arbeit läuft dort weiter. Das Suchen von Sicherheitslücken im Quellcode ist ausdrücklich erlaubt, und alltägliche Gesundheits- und Bildungsfragen sollten weiterhin funktionieren. Der Leitfaden räumt ein, dass die Schutzmechanismen gelegentlich legitime Arbeit markieren, und man arbeitet daran, falsche Markierungen zu reduzieren.

    In den Claude-Apps erscheint ein Hinweis, der mit „Switched to“ und dem Namen eines älteren Modells beginnt. Die Antwort kommt dann von diesem Modell, und der Chat bleibt dort. Zurück zu Opus 5.5 geht es über die Modellauswahl; liegt die frühere Nachricht noch im Chat, kann sie erneut markiert werden, weshalb ein neuer Chat das Problem umgeht. Wer vorher gefragt werden möchte, schaltet unter Einstellungen und dann Fähigkeiten die Option „Switch models when a message is flagged“ ab und bekommt stattdessen eine pausierte Karte mit den Optionen. Die Prüfung umfasst die gesamte Konversation inklusive Dateien und Suchergebnissen, eine Markierung kann also aus älterem Inhalt stammen und nicht nur aus der letzten Nachricht.

    Für Claude Code beschreibt der Leitfaden denselben Ablauf: Auch dort erscheint ein Hinweis auf den Modellwechsel, und die Arbeit wird auf dem älteren Modell fortgesetzt, statt abzubrechen. Nur der Ort der Anzeige unterscheidet sich. Wer regelmäßig mit sicherheitsnahen Themen arbeitet, sollte die Markierungen als Teil des Werkzeugverhaltens einplanen und nicht als Fehler behandeln.

    Bei Claude Opus 5.5 geht es weniger um neue Schaltflächen als um eine andere Arbeitsweise. Aufträge werden vollständig übergeben, das Denken nicht mehr per Prompt eingefordert, Stopps vorher definiert, Checklisten liegen in Dateien statt im Verlauf. Am Ende liest man zuerst den Bericht, dann den Code. Wer diese fünf Gewohnheiten in einer CLAUDE.md und in den Projektanweisungen hinterlegt, spart sich die Rückfragen, die früher selbstverständlich waren. Die Rollen verschieben sich: weniger Taktgeber, mehr Auftraggeber mit klarer Abnahme.

    Quelle: claude.dev

  • Anthropic macht Claude zum KI-Marktplatz mit 2.000 Plugins und Konnektoren

    Anthropic macht Claude zum KI-Marktplatz mit 2.000 Plugins und Konnektoren

    Einen KI-Assistenten an ein bestehendes Werkzeug wie ein Ticketsystem anzubinden, bedeutete bisher meist: Dokumentation lesen, API-Schlüssel verwalten, Berechtigungen von Hand nachziehen, Fehlermeldungen entziffern – bis die Verbindung irgendwann steht. Seit dieser Woche reicht ein Blick in eine öffentliche Liste, ein Klick und eine Freigabe. Das sieht nach bequemerer Einrichtung aus. Tatsächlich steckt mehr dahinter: Anthropic hat Claude zu einem Marktplatz umgebaut, auf dem fertige Verbindungen, Erweiterungen und komplette KI-Anwendungen liegen.

    Der Sicherheits- und Technikdienst BleepingComputer berichtet, dass dieser Claude Marketplace öffentlich erreichbar ist und zum Start mehr als 2.000 Einträge umfasst. Wer bisher mit Claude arbeitete, kannte das Problem: Das Sprachmodell denkt ordentlich, weiß aber nur, was man ihm gibt. Jede Anbindung ans eigene Werkzeug war Einzelarbeit, jedes Mal aufs Neue. Der Marktplatz soll daraus eine Auswahl machen.

    Was der KI-Marktplatz von Anthropic Claude versammelt

    Ein Marktplatz ist im Kern eine Ordnung. Auf einem echten Wochenmarkt weiß man nach zwei Runden, wo es Gemüse gibt, wo Fisch und wo jemand nur Kräuter verkauft. Der Markt selbst produziert nichts, er macht Bestände sichtbar und vergleichbar. So arbeitet auch der Anthropic Claude KI-Marktplatz: Er bündelt die Claude-Erweiterungen, sortiert sie nach Kategorien und lässt Interessierte direkt zugreifen.

    Ein Marktplatz ist keine Funktion im Modell, sondern eine Schicht darüber – Teil der Oberfläche, der Beschaffung, der Verteilung. Der Autor des Berichts vergleicht das mit einem App-Store-Modell, bei dem man nicht mehr jede Integration einzeln zusammensucht. Für dich als Nutzer ändert sich damit weniger die Technik als der Weg dorthin.

    Wer die 2.000 Einträge beisteuert

    Interessanter als die Zahl ist, woher die Einträge kommen. Laut Bericht stammen sie von Atlassian, Google, Microsoft, Notion, Salesforce und weiteren Anbietern. Es sind also nicht nur Anthropics eigene Werkzeuge, die dort liegen, sondern die großer Plattformen, mit denen Unternehmen ohnehin arbeiten. Ein Marktplatz mit ausschließlich hauseigener Ware wäre ein Schaufenster. Dieser hier versucht, mehr zu sein.

    Dazu kommt eine zweite Ebene. Unternehmen sollen über den Marktplatz auch fertige, Claude-gestützte Agenten und Produkte von Partnern wie CrowdStrike, Cursor, Harvey, Legora, Lovable und Snowflake kaufen können. Es geht also nicht mehr nur um Werkzeuge, sondern um fertige Ergebnisse. Ergänzt wird das durch Beratungs- und Systemintegrationspartner wie Accenture, Boston Consulting Group und Deloitte – für Häuser, die Claude nicht selbst einführen wollen oder können.

    Plugins, Konnektoren, Agenten: die Ebenen des Marktplatzes

    Die Begriffe tauchen im Alltag oft als Synonyme auf, meinen aber Unterschiedliches. Ein Konnektor ist die Leitung: Er verbindet Claude mit einer Datenquelle wie einem Projektboard, einem CRM oder einem Dateispeicher, damit das Modell dort lesen oder schreiben kann. Ein Plugin ist die Fähigkeit: Es bringt Claude bei, etwas Bestimmtes zu tun, etwa ein Dokument in einem festen Format zu erzeugen oder einen wiederkehrenden Ablauf auszulösen. Ein Agent schließlich bewegt sich selbst – eine Einheit, die eine Aufgabe übernimmt und über mehrere Schritte hinweg verfolgt.

    Für Entwickler nennt der Bericht zwei Wege, selbst beizutragen. Einmal das Model Context Protocol, kurz MCP – ein offener Standard, über den ein Modell mit externen Systemen spricht. Zum anderen Agent Skills, also beschreibbare Fähigkeiten, die festhalten, wie eine Aufgabe sauber erledigt wird. Beides zusammen entscheidet darüber, wie tief ein Eintrag im Marktplatz in den Arbeitsablauf greift.

    Diese Unterscheidung ist praktisch relevant. Ein Claude-Konnektor, der nur liest, ist eine andere Risikoklasse als ein Claude-Plugin, das schreiben darf, und eine deutlich andere als ein Agent, der selbstständig entscheidet. Wer einkauft, sollte wissen, welche der drei Ebenen er ins Haus holt. Ohne diese Einordnung kann aus einer Erleichterung eine Sicherheitslücke werden.

    Warum Anthropic auf offene Registrierung setzt

    Ohne Angebot funktioniert kein Marktplatz. Unterstützung von Microsoft oder Google allein trägt ihn nicht, und der Bericht erinnert an genau diesen Fall: OpenAI hat bereits einen App-Marktplatz gestartet, der sich nicht durchgesetzt hat. Anthropic will diesen Fehler vermeiden und lässt deshalb grundsätzlich jeden veröffentlichen, der die Voraussetzungen erfüllt. Entwickler reichen Konnektoren und Plugins ein, Anbieter Claude-gestützter Software bewerben sich um einen Platz.

    Anthropic setzt auf Menge statt auf Kontrolle. Die Logik dahinter: Wenn Kunden ohnehin eine Verbindung zu ihrem System brauchen, soll der Anbieter sie liefern können, statt auf Anthropics eigenen Fahrplan zu warten. So wie ein Kaufhaus Fremdmarken in die Regale stellt, damit Kunden überhaupt hereinkommen. Ob das aufgeht, hängt weniger am Startangebot als daran, was in sechs Monaten noch gepflegt wird.

    Für Entwickler liegt der Reiz in der Verteilung. Wer einmal im Claude AI Marketplace mit Plugins und Konnektoren steht, erreicht die bestehende Claude-Kundschaft direkt, ohne eigene Marketingmaschine. Für Anthropic ist es umgekehrt: Jeder neue Eintrag macht die Plattform für Kunden attraktiver.

    Was das für Unternehmen bedeutet

    In der Praxis dürfte der Effekt zuerst bei den Fachbereichen auftauchen. Statt monatelang eine Integrationsanfrage durch die IT zu schieben, findet ein Team einen passenden Claude-Konnektor und probiert ihn aus. Das verkürzt Wege, verschiebt aber auch Verantwortung. Wer entscheiden darf, welche Verbindung produktiv läuft, muss jetzt geklärt werden.

    Vier Punkte gehören in jede Prüfung. Erstens: Welche Daten liest oder schreibt die Verbindung, und wohin fließen sie. Zweitens: Wie wird der Zugang verwaltet – über einzelne Konten oder zentrale Freigaben. Drittens: Wer haftet, wenn ein Agent falsch handelt, der von einem Drittanbieter stammt. Viertens: Wie wird ein Eintrag wieder entfernt, wenn der Anbieter ihn aufgibt. Der Claude-Marktplatz löst diese Fragen nicht. Sichtbar macht er sie trotzdem.

    Claude-Plugins und Konnektoren für Unternehmen sind damit keine technische Randnotiz mehr, sondern ein Beschaffungsthema. Wer heute schon eine Liste führt, welche KI-Dienste im Haus erlaubt sind, hat morgen weniger Aufräumarbeit. Wer keine führt, baut sie unter Zeitdruck auf – meistens nach dem ersten Vorfall.

    Ein Marktplatz ist Infrastruktur, kein Qualitätsversprechen

    Anthropic erweitert Claude um 2.000 Plugins und Konnektoren und baut damit etwas, das einem Betriebssystem näher kommt als einem Chatfenster. Der Marktplatz ist die sichtbare Konsequenz, und er folgt derselben Logik wie andere Plattformen: viel Reichweite, lockere Prüfung. Was dort liegt, ist nicht geprüft, nur gelistet. Die Auswahl bleibt beim Käufer.

    So ein Ort wird nicht in den ersten Wochen gut oder schlecht. Er wird es dadurch, dass Entwickler ihre Einträge pflegen und Anbieter ein Interesse daran haben, dass ihre Verbindung funktioniert. Die ersten Wochen sagen über den Marktplatz fast nichts. Interessant wird es, wenn die Zahl von 2.000 nicht mehr stimmt, weil ein Teil davon verwaist ist.

    Was das konkret heißt: Schau nicht auf die Zahl, sondern auf die drei oder vier Verbindungen, die du wirklich brauchst, und prüfe, wer sie verantwortet. Der Marktplatz senkt die Einstiegshürde – nicht die Notwendigkeit, hinzuschauen.

    Quelle: bleepingcomputer.com

Weitere Beiträge