Die LLM-Flüsterer: Effiziente KI-Agenten durch Code

In der modernen KI-Entwicklung steckt eine köstliche Ironie. Seit Jahren trainieren wir große Sprachmodelle mit jedem Fetzen Code, den die Menschheit je geschrieben hat (Stack-Overflow-Antworten, GitHub-Repositories, Programmierlehrbücher, Dokumentation), und bringen ihnen fließend Python, JavaScript, TypeScript und Dutzende andere Sprachen bei. Und wenn es dann darum geht, diese Modelle tatsächlich als Agenten zu nutzen, die mit externen Tools arbeiten, verlangen wir etwas völlig Unnatürliches von ihnen: perfekt formatierte JSON-Objekte in XML-Tags, die Funktionsnamen und Parameter in einem starren Schema angeben, das sie im Training kaum gesehen haben.

Das ist, als würde man einen Konzertpianisten engagieren und ihn bitten, sich zu verständigen, indem er Morsecode auf die Tasten klopft.

Diesen Herbst haben sowohl Cloudflare als auch Anthropic technische Blogposts veröffentlicht, die zum selben radikalen Schluss kommen: Wir machen das verkehrt herum. Statt LLMs in die synthetische Sprache des Function Calling zu zwingen, sollte man sie einfach echten Code schreiben lassen. Der Leistungsgewinn ist dramatisch: Anthropic berichtet, dass der eigene Testfall von 150.000 Token auf 2.000 gesunken ist, ein Minus von 98,7 %.

Die eigentliche Geschichte handelt aber von mehr als Effizienz. Sie handelt von den operativen Trade-offs, die entstehen, wenn man von strukturierten Funktionsaufrufen dazu übergeht, beliebigen von Agenten erzeugten Code auszuführen. Die Vorteile sind real. Die neuen Fehlerarten, die Angriffsflächen und die betriebliche Komplexität, die man sich einhandelt, wenn man nicht vertrauenswürdigen Code im großen Maßstab ausführt, sind es ebenfalls.

Das Unbehagen an der MCP-Explosion

Um zu verstehen, warum das wichtig ist, müssen Sie das Model Context Protocol kennen, Anthropics offenen Standard für die Anbindung von KI-Agenten an externe Systeme, vorgestellt im November 2024. Stellen Sie es sich als USB-C für KI vor: ein universeller Adapter, mit dem jeder Agent ohne eigenen Integrationscode mit jedem Tool sprechen kann.

Die Verbreitung ging schnell. Die Community hat Tausende MCP-Server gebaut, und wie Anthropic in seinem Blogpost vom 4. November 2025 anmerkt: „Entwickler bauen routinemäßig Agenten mit Zugriff auf Hunderte oder Tausende Tools über Dutzende MCP-Server hinweg.“

Daraus entstanden sofort zwei Probleme, die jeder bestens kennt, der schon einmal KI-Agenten für den Produktivbetrieb gebaut hat:

Problem eins: das fettleibige Kontextfenster. Klassische MCP-Implementierungen laden jede Tool-Definition vorab. Eine einfache Tool-Beschreibung könnte so aussehen:

gdrive.getDocument
Description: Retrieves a document from Google Drive
Parameters:
  documentId (required, string): The ID of the document
  fields (optional, string): Specific fields to return
Returns: Document object with title, body, metadata, permissions...

Multiplizieren Sie das mit 500 Tools auf 20 MCP-Servern, und laut Anthropic sind Sie dabei, „Hunderttausende Token zu verarbeiten, bevor Sie eine Anfrage gelesen haben“. Zur Einordnung: Claudes erweitertes Kontextfenster umfasst 200K Token. Sie könnten also die Hälfte davon allein dafür ausgeben, die verfügbaren Tools zu beschreiben.

Problem zwei: die Zwischenergebnis-Steuer. Ein gängiger Workflow: ein Besprechungstranskript aus Google Drive herunterladen und dann an einen Salesforce-Lead anhängen. Bei klassischem Tool Calling fließt dieses Transkript zweimal durch das Modell:

TOOL CALL: gdrive.getDocument(documentId: "abc123")
→ Returns full 10,000-word transcript
[Model reads entire transcript into context]
TOOL CALL: salesforce.updateRecord(
  objectType: "Lead",
  data: { "Notes": [entire 10,000-word transcript] }
)
[Model writes entire transcript again]

Anthropic erklärt dazu: „Jedes Zwischenergebnis muss durch das Modell. In diesem Beispiel fließt das vollständige Gesprächstranskript zweimal hindurch. Bei einem 2-stündigen Vertriebsgespräch kann das bedeuten, dass zusätzlich 50.000 Token verarbeitet werden.“

Code Mode: die Offenbarung von Cloudflare

Cloudflares Ansatz „Code Mode“, veröffentlicht am 26. September 2025, trifft den Kern des Problems mit der für das Unternehmen typischen Direktheit. Die Erkenntnis: LLMs sind mit riesigen Mengen echten Codes trainiert, Tool-Calling-Formate dagegen sind synthetische Konstrukte, die in den Trainingsdaten kaum vorkommen. Das Modell spricht fließend JavaScript, stottert aber in Function-Call-JSON. Das Team formuliert es so: „LLMs können Code, der MCP aufruft, besser schreiben, als MCP direkt aufzurufen.“

Also haben sie den Spieß komplett umgedreht. Statt Tools als aufrufbare Funktionen bereitzustellen, erzeugt Cloudflares Agents SDK aus den MCP-Schemas TypeScript-Interfaces und lässt Claude echten Code schreiben:

import * as gdrive from './servers/google-drive';

import * as salesforce from './servers/salesforce';

const transcript = (awaitgdrive.getDocument({ documentId: 'abc123' })).content;

await salesforce.updateRecord({ objectType: 'SalesMeeting',recordId: '00Q5f000001abcXYZ', data: { Notes: transcript } });

Das ist Code, den das Modell im Training in einer Million Varianten gesehen hat. Für ein LLM, das mit GitHub als Lektüre aufgewachsen ist, ist das natürliche Sprache. Bei der Ausführungsumgebung spielt Cloudflare sein Infrastruktur-Können aus. Jedes Stück vom Agenten erzeugter Code läuft in einem V8-Isolate, denselben leichtgewichtigen JavaScript-Sandboxes, auf denen Cloudflare Workers läuft. Das sind keine Container, sondern etwas weitaus Eleganteres. Ein Isolate startet in Millisekunden und braucht nur wenige Megabyte Speicher. Das geht so schnell, dass Cloudflare für jede Codeausführung ein frisches Isolate erzeugt und es sofort wieder verwirft. Es gibt keine Wiederverwendung und kein Vorwärmen, nur sofort verfügbare Sandboxes. Besonders clever ist das Sicherheitsmodell. Das Isolate hat keinerlei Netzwerkzugriff: `fetch()` und `connect()` werfen standardmäßig Fehler. Statt dem Code beliebige HTTP-Aufrufe zu erlauben (ein Sicherheitsalbtraum), nutzt Cloudflare „Bindings“, also Live-JavaScript-Objekte mit direktem Zugriff auf bestimmte MCP-Server. Der Agenten-Code kann `gdrive.getDocument()` aufrufen, aber er kann weder beim Server eines Angreifers nach Hause telefonieren noch Daten über Seitenkanäle abfließen lassen.

Anthropics Sicht: dieselbe Erkenntnis, anderer Blickwinkel

Anthropics Engineering-Team hat erst diese Woche seine eigene Untersuchung zur Codeausführung mit MCP veröffentlicht und kommt aus einer anderen Perspektive im Kern zum selben Schluss. Der Post dreht sich weniger um Infrastruktur und mehr um Muster: wie man codebasierten Tool-Zugriff so strukturiert, dass er möglichst effizient wird. Das Paradebeispiel: Statt alle Tool-Definitionen in den Kontext zu laden, präsentiert man sie als Dateisystemstruktur, die der Agent erkunden kann:

servers/
├── google-drive/
│ ├── getDocument.ts
│ ├── listFiles.ts
│ └── index.ts
├── salesforce/
│ ├── updateRecord.ts
│ ├── query.ts
│ └── index.ts
└── slack/
├── postMessage.ts
└── index.ts

Braucht der Agent ein Tool, bewegt er sich durch das Dateisystem wie ein Entwickler: Er listet Verzeichnisse auf und liest die relevanten Dateien. In ihren Worten: „Modelle können sehr gut in Dateisystemen navigieren. Stellt man Tools als Code in einem Dateisystem dar, können Modelle Tool-Definitionen bei Bedarf lesen, statt sie alle vorab zu lesen.“

Das Ergebnis? Die erwähnten 98,7 % weniger Token im Testfall, von 150.000 auf 2.000 bei komplexen Workflows.

Anthropics Post geht aber weiter und untersucht Folgen, die Cloudflares stärker produktorientierter Text nur andeutet:

Datenfilterung in der Ausführungsumgebung. Statt 10.000 Tabellenzeilen durch den Kontext des Modells zu ziehen, schreibt der Agent Code, der lokal filtert:

const allRows = await gdrive.getSheet({ sheetId: 'abc123' });
const pendingOrders = allRows.filter(row => 
  row["Status"] === 'pending'
);
console.log(`Found ${pendingOrders.length} pending orders`);
console.log(pendingOrders.slice(0, 5)); // Only log first 5

Anthropic merkt dazu an: „Der Agent sieht fünf Zeilen statt 10.000. Ähnliche Muster funktionieren für Aggregationen, Joins über mehrere Datenquellen oder das Extrahieren bestimmter Felder, und all das, ohne das Kontextfenster aufzublähen.“

Datenschutzfreundliche Abläufe. Hier wird es wirklich interessant. Mit Codeausführung müssen Zwischendaten gar nie in den Kontext des Modells gelangen. Anthropic beschreibt ein Muster, bei dem der Ausführungs-Harness sensible Daten automatisch tokenisiert:

// Agent writes this code:
const sheet = await gdrive.getSheet({ sheetId: 'abc123' });
for (const row of sheet.rows) {
  await salesforce.updateRecord({
    data: { Email: row.email, Phone: row.phone }
  });
}
// But the model only sees tokenized data:
[
  { email: '[EMAIL_1]', phone: '[PHONE_1]' },
  { email: '[EMAIL_2]', phone: '[PHONE_2]' },
  ...
]

Echte E-Mail-Adressen und Telefonnummern fließen von Google Sheets zu Salesforce, aber nie durch das Modell. „Die echten E-Mail-Adressen, Telefonnummern und Namen fließen von Google Sheets zu Salesforce, aber nie durch das Modell“, erklären sie. Das ist mehr als Effizienz: Es ist ein völlig anderes Sicherheitsmodell für den Umgang mit PII.

Skills, die aufeinander aufbauen. Hat ein Agent einmal funktionierenden Code für eine Aufgabe entwickelt, kann er diese Implementierung als wiederverwendbare Funktion speichern. Mit der Zeit baut sich der Agent eine Bibliothek von Fähigkeiten auf höherer Ebene auf, im Grunde entsteht so seine eigene Standardbibliothek domänenspezifischer Operationen.

Die Trade-offs: was die Blogposts Ihnen nicht sagen

Beide Posts argumentieren überzeugend für Codeausführung, aber geschrieben haben sie Teams, die Produkte ausliefern. Sehen wir uns an, was dabei unter den Tisch fällt.

Dimension	Klassisches Tool Calling	Codeausführung
Token-Kosten (komplexer Workflow)	150.000	2.000
Infrastrukturbedarf	Keiner (nur LLM-API)	Sandbox-Runtime, Monitoring
Cold-Start-Latenz	~0 ms Overhead	Einige zehn Millisekunden (Sandbox)
Debugging-Komplexität	Mittel (Tool-Aufrufe prüfen)	Hoch (erzeugten Code prüfen)
Angriffsfläche	Modell → API	Modell → Code → Sandbox → API
Fehlerarten	Fehlerhaftes JSON, falsche Parameter	Logikfehler, Endlosschleifen, Ressourcenerschöpfung
Betriebsaufwand	Gering	Hoch (Sandbox-Wartung, Skill-Bibliothek)
Am besten für	Einfache Workflows, wenige Tools	Komplexe Workflows, viele Tools

Der Debugging-Albtraum. Macht ein Agent einen falschen Tool-Aufruf, sehen Sie genau, was schiefgelaufen ist: {"tool": "updateRecord", "params": {"recordId": null}}. Aha, er hat vergessen, die ID zu übergeben. Schreibt ein Agent dagegen Code, der kompiliert, aber einen subtilen Logikfehler enthält, wird Debugging zur Archäologie. Der Code sieht richtig aus. Er läuft ohne Fehler. Aber er tut still und leise das Falsche.

Nehmen Sie diesen vom Agenten erzeugten Code:

const leads = await salesforce.query({

  query: 'SELECT Id FROM Lead' 
});
for (const lead of leads) {
  await crm.updateStatus(lead.Id, 'contacted');
}

Sieht gut aus, oder? Nur dass er updateStatus in einer Schleife aufruft und 1.000 API-Aufrufe nacheinander absetzt, statt eine Batch-Operation zu verwenden. Der Agent hat das Problem gelöst, aber auf die ineffizienteste Art überhaupt. Klassisches Tool Calling mit ordentlichen Batch-Operationen in den Tool-Definitionen hätte das verhindert.

Das Sicherheitsparadox. Sandboxing bringt Sicherheit, aber Codeausführung öffnet neue Angriffsvektoren. Ein Agent könnte Code schreiben, der bösartige Operationen absichtlich in komplexer Logik versteckt:

// Innocent-looking data processing
const results = data.map(item => {
  const processed = transform(item);
  // Buried 50 lines deep: exfiltrate data
  if (processed.value > threshold) {
    // Oops, logs go to external service
    logger.debug(JSON.stringify(processed));
  }
  return processed;
});

Bei Tool Calling prüfen Sie die Tools. Bei Codeausführung müssen Sie den Code und die Ausführungsumgebung prüfen. Die statische Analyse von LLM-erzeugtem Code ist noch ein ungelöstes Problem.

Die betriebliche Last. Cloudflare hat V8-Isolates, weil es Cloudflare ist: Das Unternehmen hat Jahre in den Aufbau dieser Infrastruktur gesteckt. Auf alle anderen kommt Folgendes zu:

Aufbau und Wartung einer Sandbox-Runtime (Docker, Firecracker, gVisor oder Sandboxing auf Betriebssystemebene)
Ressourcenlimits und Monitoring, um außer Kontrolle geratenen Code zu verhindern
Versionsverwaltung für die Skill-Bibliothek, während Ihr Agent immer mehr Code ansammelt
Logging und Observability für die Codeausführung (was lief, warum, worauf griff es zu)

Anthropics eigene Arbeit am Sandboxing von Claude Code zeigt, dass dort Linux bubblewrap und macOS Sandbox zum Einsatz kommen, also Primitive auf Betriebssystemebene, die sorgfältig konfiguriert werden müssen. Anthropic hat diese Arbeit als Open Source veröffentlicht, was anerkennenswert ist, aber schlüsselfertig ist die Übernahme nicht.

Wann Codeausführung überdimensioniert ist

Das ist entscheidend: Codeausführung ist nicht immer die richtige Antwort.

Wenn Ihr Agent für einfache Workflows nur 3 bis 5 Tools nutzt, übersteigt der Aufwand für die Codeausführung wahrscheinlich den Nutzen. Ein Kundendienst-Bot, der Bestellungen nachschlägt und vorgefertigte Antworten verschickt? Klassisches Tool Calling ist einfacher, lässt sich besser prüfen und hat weniger bewegliche Teile.

Codeausführung ist sinnvoll, wenn:

Sie Dutzende MCP-Server mit Hunderten Tools anbinden
Workflows komplexe mehrstufige Operationen mit Datentransformation umfassen
Zwischenergebnisse groß sind (Dokumente, Datensätze, Abfrageergebnisse)
Sie datenschutzfreundliche Datenverarbeitung brauchen (PII-Tokenisierung)
Ihre betriebliche Reife auch eine sichere Sandbox-Infrastruktur umfasst

Codeausführung ist wahrscheinlich überdimensioniert, wenn:

Sie eine Handvoll einfacher Tools haben
Workflows kurz und linear sind
alle Daten klein genug sind, um bequem in den Kontext zu passen
Ihrem Team Sandbox-Infrastruktur oder Sicherheits-Know-how fehlt
das Deployment on-premises mit begrenzten Rechenressourcen läuft

Die Kosten-Nutzen-Rechnung ändert sich mit dem Maßstab. Bei 100 Agenten-Aufrufen pro Tag mit 5 Tools ist klassisches Tool Calling in Ordnung. Bei 100.000 Aufrufen pro Tag mit 200 Tools verbrennen Sie Zehntausende Dollar an unnötigen Token-Kosten, genug, um den Aufbau einer Sandbox-Infrastruktur zu rechtfertigen.

Warum das funktioniert: Die Trainingsdaten verraten alles

Der tiefere Grund, warum Codegenerierung funktioniert, liegt in der Art, wie diese Modelle trainiert wurden. Wer sich die Common-Crawl-Snapshots, GitHub-Dumps und Code-Repositories ansieht, aus denen die Trainingsdaten von LLMs bestehen, findet Milliarden Zeilen Produktionscode. Funktionsaufrufe, Fehlerbehandlung, Schleifen, Datentransformationen: das ganze Spektrum an Softwaremustern, geschrieben von Menschen, die echte Probleme lösen wollten.

Was Sie dort kaum finden: synthetische Tool-Calling-Formate. In XML-Tags verpackte JSON-Funktionsbeschreibungen sind ein Artefakt des LLM-Deployments, nicht der Trainingsdaten. Sie sind eine nachträgliche Konvention, die Forscher und Ingenieure erfunden haben, um Modelle nützlicher zu machen, aber die Modelle haben bei weitem nicht genug Beispiele gesehen, um sie wirklich fließend zu beherrschen.

Das erklärt, warum Tool Calling so fragil bleibt. Modelle halluzinieren Funktionsnamen, bringen Parametertypen durcheinander und tun sich schwer mit komplexen Tool-Kompositionen. Sie erzeugen Text in einem Format, auf das sie nie richtig trainiert wurden.

Code zu schreiben, der API-Aufrufe aneinanderreiht, ist dagegen ihre Muttersprache.

Konvergente Evolution in Echtzeit

Bemerkenswert ist, wie unabhängig voneinander Cloudflare und Anthropic innerhalb weniger Wochen im Wesentlichen zum selben Schluss gekommen sind. Cloudflare veröffentlichte am 26. September 2025, Anthropic am 4. November 2025. Die Posts verweisen aufeinander, aber das waren klar parallele Entdeckungen, getrieben vom selben Druck: Agenten skalieren, die Zahl der Tools explodiert, und der alte Ansatz bricht in dieser Größenordnung zusammen.

Cloudflare räumt das in seinem Post direkt ein und merkt an, dass Anthropic „ähnliche Erkenntnisse veröffentlicht hat und die Codeausführung mit MCP als ‘Code Mode’ bezeichnet. Die Kernerkenntnis ist dieselbe: LLMs sind geschickt darin, Code zu schreiben, und Entwickler sollten diese Stärke nutzen.“

Das erinnert an andere Momente der Computergeschichte, in denen Infrastrukturgrenzen ein Umdenken in der Architektur erzwangen. Der Wechsel von CGI-Skripten zu FastCGI und WSGI, als der Webverkehr wuchs. Die Container-Revolution, als VMs zu schwergewichtig wurden. Der Aufstieg von GraphQL, als REST-APIs unhandlich wurden. In jedem dieser Fälle funktionierte der alte Ansatz im Kleinen gut, aber unter Druck traten grundlegende Grenzen zutage.

Diesen Phasenübergang erleben wir gerade in Echtzeit bei KI-Agenten.

Wie es weitergeht

Wie schnell sich Codeausführung mit MCP durchsetzt, ist noch offen. Die Effizienzgewinne sind überzeugend, aber die betriebliche Komplexität ist real. Damit der Ansatz breiter genutzt wird, muss Folgendes passieren:

Standardisierte Sandbox-Runtimes. Im Moment baut sich jeder, der das umsetzt, seine eigene. Wir brauchen das Äquivalent von Docker für die Ausführung von Agenten-Code: eine Standard-Runtime, die Sandboxing, Ressourcenlimits und Monitoring mit vernünftigen Voreinstellungen erledigt. Anthropics Open-Source-Arbeit ist ein Anfang, aber es braucht Werkzeuge im gesamten Ökosystem. Sandbox-as-a-Service-Angebote werden vermutlich entstehen.

Bessere Debugging-Tools. Wenn Agenten Code schreiben, brauchen Entwickler Tools, um zu verstehen, was dieser Code tut, warum er erzeugt wurde und wo er schiefging. Denken Sie an Execution Traces, Code-Annotationen vom Modell („Ich schreibe diese Schleife, um alle Leads zu verarbeiten“) und statische Analysetools, die auf die Codemuster von LLMs abgestimmt sind.

Observability-Frameworks. Standardisiertes Logging, Tracing und Monitoring, eigens für von Agenten geschriebenen Code. Welche Tools hat er genutzt? Welche Daten sind wohin geflossen? Wie sah der Ausführungspfad aus? Das sind mehr als Debugging-Tools: Für den Einsatz in Unternehmen sind es Audit- und Compliance-Anforderungen.

Klarere Sicherheitsmodelle. Unternehmen brauchen Vertrauen in die Sicherheitsgrenzen, bevor sie das einführen. Das heißt: formale Verifikation der Sandbox-Eigenschaften, Audit-Logging jeder Codeausführung und klare Regeln dafür, was Code darf und was nicht. Das von Anthropic beschriebene Muster „PII tokenisieren“ ist elegant, muss aber standardisiert und von unabhängiger Seite geprüft werden.

Agenten-Frameworks mit allem Drum und Dran. LangChain, AutoGPT und ähnliche Frameworks müssen sichere Ausführungsumgebungen mitliefern oder zumindest klare Integrationswege bieten. Das Ökosystem wird sich vermutlich in „leichtgewichtige“ Frameworks (nur Tool Calling) und „Full-Stack“-Frameworks (inklusive Codeausführung) aufteilen, ähnlich wie sich Web-Frameworks in reine Templating-Lösungen und vollständiges MVC aufgeteilt haben.

Analyse der Wirtschaftlichkeit. Die Token-Ersparnis ist dramatisch, aber Sie tauschen Rechenleistung gegen Infrastrukturkosten. Ab welchem Maßstab wird eine Sandbox-Runtime billiger, als Token zu verbrennen? Bei hochfrequenten Agenten, die komplexe Workflows im großen Maßstab abwickeln, wahrscheinlich sofort. Bei selten genutzten Assistenten mit einfachen Workflows vielleicht nie.

Codegenerierungs-Bibliotheken für Skills. Wenn Agenten immer mehr wiederverwendbare Code-Snippets und Skills ansammeln, brauchen wir Mechanismen für Versionierung, Tests und Verteilung: im Grunde Paketmanager für Agenten-Skills.

Wenn ich schätzen müsste (und das ist fundierte Spekulation, keine Prognose), werden viele Agenten-Plattformen mit hohem Volumen innerhalb von 18 bis 24 Monaten Codeausführung einführen. Für kleinere Deployments und einfachere Anwendungsfälle bleibt klassisches Tool Calling die pragmatische Wahl, bis die Werkzeuge ausgereift sind und Sandbox-Infrastruktur zur Massenware geworden ist. Die Druckpunkte, die Cloudflare und Anthropic zu diesem Ansatz getrieben haben (Tool-Überlastung, Token-Kosten, Workflow-Komplexität), treffen nicht alle gleich stark und nicht alle sofort.

Die Meta-Lektion

Ohne die technischen Details bleibt eine allgemeinere Lektion für die Arbeit mit KI-Systemen: Verstehen Sie, was Ihr Werkzeug wirklich gut kann, und bauen Sie auf diesen Stärken auf.

LLMs sind im Grunde Textvorhersage-Maschinen, trainiert mit von Menschen erzeugten Inhalten. Sie glänzen bei Aufgaben, die dem Text ähneln, mit dem sie trainiert wurden. Verlangen wir von ihnen synthetische Formate ohne Entsprechung in ihren Trainingsdaten, arbeiten wir gegen die Natur des Systems.

Die Revolution besteht nicht darin, Modellen Neues beizubringen, sondern darin zu erkennen, was sie schon gut können, und die Infrastruktur um diese Stärken herum zu bauen. Bei Code Mode und Codeausführung mit MCP geht es nicht darum, Fähigkeiten hinzuzufügen, sondern künstliche Beschränkungen zu entfernen.

Aber, und das ist entscheidend, wer Beschränkungen entfernt, übernimmt neue Verantwortung. Anthropic merkt dazu in seinem Post an: „Die Ausführung von Agenten-Code erfordert eine sichere Ausführungsumgebung mit angemessenem Sandboxing, Ressourcenlimits und Monitoring. Diese Infrastrukturanforderungen bringen Betriebsaufwand und Sicherheitsfragen mit sich, die bei direkten Tool-Aufrufen entfallen.“

Sie rufen nicht mehr bloß APIs auf, Sie führen beliebigen Code aus, den ein probabilistisches Modell erzeugt hat. Das ist mächtig. Es ist auch riskant. Die technischen Herausforderungen sind real: Sandboxing, Debugging, Sicherheit, Betriebsaufwand.

Ob Codeausführung in einem abstrakten Sinn „besser“ ist als Tool Calling, ist nicht die Frage. Die Frage lautet: Rechtfertigen für Ihren konkreten Anwendungsfall, in Ihrem konkreten Maßstab und bei Ihrer konkreten betrieblichen Reife die Token-Ersparnis und die besseren Workflows die Komplexität der Infrastruktur?

Für Cloudflare und Anthropic, die in riesigem Maßstab mit Infrastruktur-Teams von Weltklasse arbeiten, lautet die Antwort klar Ja. Für alle anderen hängt die Rechnung vom Maßstab, von den technischen Kapazitäten und davon ab, wie viele Tools Sie orchestrieren wollen.

Die Branche lernt gerade wieder, dass es keine Wundermittel gibt, nur Trade-offs.

Aus dem Englischen übersetzt: zum Originalbeitrag