Self-hosted Claude Managed Agents: Der Server gehört dir, und die stillen Fehler auch

Am 12. November hat Anthropic Self-hosted Claude Managed Agents gestartet. Bisher konntest du die Sandboxes auf eigene Maschinen verlegen und den Rest bei Anthropic lassen. Jetzt kann der ganze Dienst umziehen: die API, der Agent-Loop und der Speicher für Agents, Sessions und Session-Verlauf. Der Server schickt Modellaufrufe standardmäßig an die Claude API, alternativ an Amazon Bedrock, Google Cloud, Microsoft Foundry oder ein Gateway, das du selbst betreibst.

Ich habe es nicht betrieben. Den Download gibt es auf Anfrage über das Account-Team, also stützt sich dieser Text auf die Dokumentation mit Stand 13. November. Zuerst lesen solltest du die Seite „Differences from the hosted service“, und ihre besten Zeilen sind die, die mit „no error“ enden.

Was ist Self-hosted Claude Managed Agents?

Es ist dieselbe Managed Agents API, nur ausgeliefert von einem Programm, das du betreibst: cma-server. Das SDK und die ant CLI funktionieren damit unverändert. Ein Deployment besteht aus einem oder mehreren Servern, PostgreSQL 16 oder neuer und Workern, die den Server pollen und die Shell- und Datei-Tools des Agents in deinen Sandboxes ausführen.

Zwei Zeilen aus der Übersicht solltest du vor allem anderen kennen. Der Server startet auch ohne Datenbank; dann hält er alles im Arbeitsspeicher, und ein Neustart löscht es. Und das bash-Tool ist eine echte Shell mit den Rechten des Workers. Der Worker isoliert sie nicht, die Isolation ist also genau der Container oder die VM, in die du den Worker steckst.

Welche Fehler in Self-hosted Claude Managed Agents melden nichts?

Die Differences-Seite nennt sie. In jedem dieser Fälle gelingt dein Aufruf oder bleibt still, aber die Arbeit wurde nicht so erledigt, wie du sie angefordert hast:

• Kein Worker pollt das Environment. Modell-Turns laufen trotzdem, und der erste Tool-Call „waits, with no error, until a worker runs it.“ Dasselbe Warten folgt, wenn dein Worker per Webhook starten sollte: Der Server schickt keinen.
• Die Web-Tools sind eingeschaltet, aber der Provider bietet eines nicht an. web_search funktioniert unter anthropic, vertex und foundry, web_fetch nur unter anthropic und foundry. Unter den anderen lässt sich der Agent speichern und starten und listet das Tool weiterhin, aber dem Modell wird es nie angeboten.
• Ein Bild oder Dokument wird per URL geschickt. Der Server nimmt den Block an, und das Modell sieht ihn nie.
• Dein Git-Host lehnt einen Push ab. Das Log des Servers sagt trotzdem ok.
• Ein Safety-Classifier lehnt eine Anfrage unter der Claude API ab. Der serverseitige Fallback ist standardmäßig aktiv, also antwortet ein anderes Claude-Modell, „possibly a less capable one“. Anthropic wählt es aus, kein Event meldet den Wechsel, und nur die Modell-ID in der Session zeigt ihn. inference.model_fallback: false schaltet das ab.

Ein weiterer Fall kommt nah heran: Ein Custom-Tool-Ergebnis, das zu groß für das Kontextfenster ist, bekommt ein 200, und der Fehler kommt danach, als session.error, der die Session beendet. Jeder dieser Fälle ist dokumentiert. Keiner fällt auf, solange du nicht danach suchst. Über dasselbe Muster in Claude Code habe ich geschrieben, wo abgelehnte Arbeit mit einem Success-Subtype endet: Ein sauberer Exit ist nicht dasselbe wie erledigte Arbeit.

Welche Features des gehosteten Dienstes fehlen in Self-hosted Claude Managed Agents?

Dreams, Webhooks, Scheduled Deployments, die Files API, mcp_oauth-Vault-Credentials und die vorgefertigten Skills für docx, pdf, pptx und xlsx fehlen alle. Geplante Läufe gehen an deinen eigenen Cron, Dateien landen im Verzeichnis des Workers, Bilder gehen als base64, und ein OAuth-Token wird zu einem statischen, das du von Hand rotierst. Für Dreams gibt es keinen Ersatz.

Am stärksten schrumpft die Orchestrierung. Dynamic Workflows, der Advisor und Agents, die das Modell selbst definiert, liefern 400; der Server akzeptiert nur den Typ coordinator mit 1 bis 20 gelisteten Agents. Ein Agent, der multiagent_20261001 setzt, den Typ aus meinem Guide zu Dynamic Workflows, wird hier also abgelehnt, und die Workflows lassen sich nicht übernehmen. Auch sonst wird nichts übernommen: Agents, Skills, Vault-Credentials und Memory Stores werden neu angelegt, und die Allowlists für MCP- und Git-Hosts starten leer.

Was verlässt mit Self-hosted Claude Managed Agents dein Netzwerk?

Jeder Modellaufruf trägt die bisherige Konversation zum Provider, einschließlich Tool-Inputs und -Ergebnissen. Unter der Claude API gehen drei Header mit: die IDs von Session, Agent und Environment. Die IDs enthalten keine Namen oder Inhalte, aber jede kodiert den Zeitpunkt, zu dem dein Server sie erzeugt hat, und „No setting turns them off.“

Bei der Aufbewahrung ändert sich tatsächlich etwas. Das gehostete Managed Agents fällt nicht unter Zero Data Retention, weil Anthropic die Transkripte speichert, bis du sie löschst. Beim Self-Hosting speicherst du sie. Die Modellaufrufe fallen unter deinen Vertrag mit dem Provider, der sie bedient; ist das die Claude API, gilt für sie eine bestehende ZDR-Vereinbarung wie für andere Messages-API-Aufrufe.

Self-hosted Claude Managed Agents oder Self-hosted Sandboxes: Was passt?

Die Docs ziehen die Grenze bei zwei Anforderungen: Agents, Sessions und Verlauf liegen auf deiner Infrastruktur, oder Modellaufrufe gehen an Bedrock, Google Cloud, Foundry oder dein eigenes Gateway. Brauchst du keins von beiden, halten Self-hosted Sandboxes die Tools in deinem Netzwerk, während Anthropic den Dienst betreibt, mit eigenen Einschränkungen (zum Beispiel keine Session-Ressourcen vom Typ file oder github_repository).

Meine Lesart: Das volle Self-Hosting bringt dir die Hoheit über die Transkripte und über die Wahl des Providers. Der Preis: Du betreibst jetzt den Dienst selbst, mit einer Datenbank, die gesichert werden muss, einem Server, der gepatcht werden muss, und den Fällen oben, in denen der Dienst nichts meldet.

Was solltest du vor der ersten Session mit Self-hosted Claude Managed Agents prüfen?

Die stillen Fälle, und zwar absichtlich. Stopp den Worker und schau zu, wie die Session an einem Tool-Call hängt. Schalte die Web-Tools ein, stell den Provider auf Bedrock und bitte den Agent um eine Suche. Schick ein Bild per URL. Erlaube einen Branch auf dem Server, schütze ihn auf dem Host, pushe darauf und vergleiche die beiden Logs. Das ist ein Vorschlag, ungetestet, aber jeder Schritt stammt aus einer Zeile der Docs.

Nach meiner Lesart würde ich einen Default ändern und einen Alarm hinzufügen. Setz inference.model_fallback: false oder protokolliere die Modell-ID jeder Session, denn ein Modellwechsel, den niemand festhält, macht jeden späteren Vergleich von Läufen fragwürdig. Und lass dich alarmieren, wenn eine Session, die arbeiten sollte, ein paar Minuten lang kein Event erzeugt hat. Der eigene Rat der Docs zum Push ist die allgemeine Regel: Prüf das Ergebnis auf dem System, das es hält, nicht im Log des Systems, das es geschickt hat.