OpenRouter vergleicht gehostete Code-Ausführung von vier KI-Anbietern

Was serverseitige Code-Ausführung bedeutet

Ein Modell führt selbst nie etwas aus. Wenn es ein Tool aufruft, gibt es eine Anfrage aus, die das Tool und die Argumente benennt, und eine andere Instanz muss sie ausführen. Bei einem clientseitigen Tool ist das die Anwendung oder das Agenten-Framework des Entwicklers, das den Aufruf ausführt und das Ergebnis in einer Folgeanfrage zurückschickt.

Bei einem serverseitigen Tool führt der Anbieter den Aufruf auf seiner eigenen Infrastruktur aus und gibt das Ergebnis in derselben Anfrage an das Modell zurück. Laut OpenRouter fügt der Entwickler das Tool der Anfrage hinzu, das Modell entscheidet, wann es etwas ausführen muss, und der Anbieter führt die Befehle in einem isolierten Linux-Container aus, der ein eigenes Dateisystem, ein Zeitlimit und standardmäßig keinen Netzwerkzugriff hat.

Das Modell kann einen Befehl ausführen, die Ausgabe lesen und entscheiden, ob es einen weiteren Befehl startet, und das so lange wiederholen, bis es antwortet. OpenRouter begrenzt diese Schleife über das Feld max_tool_calls. In der Referenz zu den Server-Tools liegen Standardwert und Maximum jeweils bei 30.

Wie sich die vier Anbieter unterscheiden

Laut OpenRouter unterscheiden sich die Anbieter vor allem darin, für welche Modelle sie Code ausführen.

• OpenAI: ein Shell-Tool in der Responses API, das in einem von OpenAI verwalteten Container läuft. Die dokumentierte Laufzeitumgebung ist Debian 12 mit /mnt/data als Standard-Arbeitsverzeichnis. Befehle laufen ohne sudo, interaktive TTY-Sitzungen werden nicht unterstützt. Zu den vorinstallierten Sprachen gehören Python 3.11, Node.js 22.16, Java 17, PHP 8.2, Ruby 3.1 und Go 1.23. Ausgehender Netzwerkzugriff ist standardmäßig deaktiviert und lässt sich über eine Allowlist aktivieren, die ein Organisationsadmin festlegt.
• Anthropic: ein Code-Execution-Tool, das Python und Bash in der Messages API ausführt. Die dokumentierte Umgebung ist ein Linux-x86_64-Container mit Python 3.11, 5 GiB RAM, 5 GiB Arbeitsspeicherplatz und einer CPU. Der Internetzugang ist deaktiviert, sodass Claude während eines Laufs keine Pakete installieren kann. Container laufen 30 Tage nach der Erstellung ab und werden nach etwa 5 Minuten Inaktivität als Checkpoint gesichert.
• Google: ein Code-Execution-Tool für Gemini-Modelle, das ausschließlich Python generieren und ausführen kann. Laut Dokumentation beträgt die maximale Laufzeit 30 Sekunden, und Nutzer können keine eigenen Bibliotheken installieren.

Anthropic bietet drei Tool-Versionen an. Laut dem Artikel unterstützt code_execution_20250825 Bash-Befehle und Dateioperationen, während code_execution_20260120 einen Python-Interpreter-Zustand hinzufügt, der zwischen Anfragen erhalten bleibt. Diese Version ist für Claude Haiku 4.5 nicht verfügbar.

Die eigene Sandbox von OpenRouter für beliebige Modelle

Die drei genannten Tools funktionieren jeweils nur mit den Modellen eines Unternehmens. OpenRouter zufolge laufen seine Tools mit jedem Modell in der Responses und der Messages API, weil die Sandbox auf der Routing-Ebene läuft und nicht innerhalb eines einzelnen Modellanbieters.

Das Unternehmen liefert zwei Tools aus. Das Tool openrouter:shell orientiert sich an der Form der gehosteten Shell von OpenAI und funktioniert sowohl in der Responses als auch in der Messages API. Das Tool openrouter:bash orientiert sich am Bash-Tool von Anthropic und funktioniert nur in der Messages API. Beide befinden sich in der Beta, die API kann sich also noch ändern.

Die Ausführung in der Sandbox läuft ausschließlich über den globalen Endpunkt openrouter.ai. Regionale Endpunkte bieten das Shell-Tool nicht an, und Chat Completions lehnt beide Tools mit einem 400-Fehler ab, der die unterstützenden APIs nennt.

Entwickler setzen das Feld engine auf openrouter, um Befehle in der Sandbox von OpenRouter auszuführen. Der Standardwert ist auto. Bei openrouter:shell behält auto die native gehostete Shell eines Anbieters bei, sofern es eine gibt, und leitet andernfalls an die Sandbox von OpenRouter weiter. Bei openrouter:bash gibt auto den Tool-Aufruf an die Anwendung zurück, die ihn clientseitig ausführt, auf den Servern von OpenRouter wird nichts ausgeführt.

Kosten, Grenzen und wann sich eine eigene Sandbox lohnt

OpenRouter beschreibt seine Sandbox als isolierten Container, der auf das Konto und den Workspace des Nutzers beschränkt ist, mit standardmäßig deaktiviertem ausgehendem Netzwerkzugriff und Limits für Laufzeit und Ausgabegröße pro Befehl. Die Sandbox-Zeit wird mit 0,0001 $ pro Sekunde abgerechnet, bei einem neuen oder ruhenden Container mit einer Mindestdauer von 30 Sekunden.

Das Unternehmen sieht openrouter:shell für Aufgaben vor, die aus einer Handvoll kurzer Befehle pro Anfrage bestehen. Für ein eigenes Basis-Image, GPU-Aufgaben oder Sitzungen, die stundenlang laufen, sei weiterhin eine vom Entwickler betriebene Sandbox-Plattform wie E2B oder Modal oder ein selbst verwalteter Docker-Container die richtige Wahl. Wer eine eigene Sandbox betreibt, ist auch für die Sicherheitsgrenze verantwortlich, etwa dafür, den Code von Datenbanken und dem Internet fernzuhalten.

Für Teams, die Agenten bauen, legt der Vergleich nahe, dass die Wahl vor allem davon abhängt, welche Modelle sie nutzen und wie lange der Code laufen muss. Anbieterspezifische Tools eignen sich für eine einzelne Modellfamilie, während die Tools von OpenRouter mehrere Modelle über eine einheitliche Schnittstelle abdecken sollen.