claude CLI-Subprocess, der eine Shell, ein Arbeitsverzeichnis und Sitzungsdateien auf der Festplatte besitzt. Das Hosting unterscheidet sich vom Hosting eines zustandslosen API-Wrappers. Jeder laufende Agent ist ein langlebiger Prozess, der an lokalen Zustand gebunden ist, was beeinflusst, wie Sie Ressourcen zuordnen, Sitzungen persistieren und über Mandanten skalieren.
Diese Seite behandelt das Self-Hosting auf Ihrer eigenen Infrastruktur: verstehen Sie das Subprocess-Modell, wählen Sie ein Sitzungsmuster, stellen Sie den Container bereit und behandeln Sie Produktionsbedenken wie Persistenz, Observability, Authentifizierung und Multi-Tenant-Isolation. Für bereitstellbare Dockerfiles und Kubernetes-Manifeste siehe das Hosting-Cookbook.
Wenn Sie keine Infrastrukturkontrolle, benutzerdefinierte Isolation oder Ihre eigene Datenebene benötigen, erwägen Sie stattdessen Managed Agents: eine gehostete REST-API, bei der Anthropic den Agent und die Sandbox ausführt, sodass Ihre Anwendung Ereignisse sendet und Ergebnisse zurückstreamt, ohne dass Sie eine Hosting-Infrastruktur betreiben müssen.
Für Sicherheitshärtung über grundlegendes Sandboxing hinaus, einschließlich Netzwerkkontrollen, Verwaltung von Anmeldedaten und Isolationsoptionen, siehe Sichere Bereitstellung.
Das Subprocess-Modell
Jede Hosting-Entscheidung auf dieser Seite folgt aus der Art und Weise, wie das SDK den Agent ausführt. Wenn Ihr Codequery() aufruft, spawnt das SDK einen separaten claude CLI-Prozess und kommuniziert mit ihm über stdio. Dieser Subprocess besitzt die Shell, das Arbeitsverzeichnis und die JSONL-Sitzungstranskripte auf der lokalen Festplatte.
cwd bei jedem query()-Aufruf, wenn Sitzungen separate Dateisysteme benötigen:
Status, der auf der lokalen Festplatte gespeichert ist
Drei Arten von Agent-Status befinden sich standardmäßig im Dateisystem des Containers. Keine von ihnen überlebt einen Container-Neustart, ein Scale-Down oder einen Wechsel zu einem anderen Knoten.| Status | Standardort |
|---|---|
| Sitzungstranskripte | ~/.claude/projects/, oder das Verzeichnis projects/ unter CLAUDE_CONFIG_DIR, falls gesetzt |
CLAUDE.md Speicherdateien | ~/.claude/CLAUDE.md für die Benutzerebene und das Arbeitsverzeichnis der Sitzung für die Projektebene |
| Arbeitsverzeichnis-Artefakte | Das Arbeitsverzeichnis der Sitzung |
SessionStore-Adapter. Speicherdateien und andere Arbeitsverzeichnis-Artefakte benötigen ihre eigene Speicherstrategie, wie z. B. ein bereitgestelltes Volume oder eine Objektspeicher-Synchronisierung.
Informationen dazu, wie Sitzungen, Wiederaufnahme und Forking auf API-Ebene funktionieren, finden Sie unter Sitzungen.
Wählen Sie ein Sitzungsmuster
Diese vier Muster decken den Sitzungslebenszyklus ab: wie lange ein Container im Verhältnis zu den Sitzungen, die er bedient, existiert. Für den Ort, an dem der Container ausgeführt wird, hat das Hosting-Kochbuch bereitstellbaren Code für lokales Docker, Modal und Kubernetes. Wählen Sie hier ein Sitzungsmuster und ein Bereitstellungsziel aus dem Kochbuch.Ephemere Sitzungen
Erstellen Sie einen Container für jede Benutzeraufgabe und zerstören Sie ihn, wenn die Aufgabe abgeschlossen ist. Am besten für einmalige Aufgaben. Der Benutzer kann möglicherweise noch mit der KI interagieren, während die Aufgabe abgeschlossen wird, aber nach Abschluss wird der Container zerstört. Beispielworkloads umfassen Fehleruntersuchung und -behebung, Rechnungs- und Belegextraktion, Dokumentenübersetzung und Medientransformation. Der Container führt einen einmaligen Einstiegspunkt aus, der das SDK aufruft und beendet wird. Das folgende Beispiel zeigt eine minimale TypeScript-Version. Speichern Sie es alsentrypoint.mts oder setzen Sie "type": "module" in package.json, damit await auf oberster Ebene verfügbar ist.
Langfristige Sitzungen
Führen Sie persistente Container-Instanzen aus, die häufig mehrere SDK-Prozesse pro Container hosten, um laufende Arbeiten zu bedienen. Am besten für Agenten, die autonome Maßnahmen ergreifen, Inhalte bereitstellen oder hochvolumige Nachrichtenströme verarbeiten. Beispielworkloads umfassen einen E-Mail-Agenten, der eingehende Post sortiert und beantwortet, einen Website-Builder, der eine pro Benutzer bearbeitbare Website über Container-Ports hostet, und einen Chatbot, der kontinuierlichen Datenverkehr von einer Plattform wie Slack verarbeitet. Der Container stellt einen HTTP- oder WebSocket-Endpunkt bereit und ordnet jede aktive Sitzung einer langlebigen Abfrage und dem dahinter liegenden Unterprozess zu. In TypeScript verwenden SiestreamInput(), um Züge zu einer aktiven Sitzung hinzuzufügen, und startup(), um Unterprozesse vor eingehendem Datenverkehr vorzuwärmen. In Python verwenden Sie ClaudeSDKClient, um eine Sitzung über Züge hinweg offen zu halten. Dimensionieren Sie den Container so, dass er die maximale Anzahl gleichzeitiger Sitzungen im Speicher halten kann.
Hybrid-Sitzungen
Ephemere Container, die beim Start aus einemSessionStore rehydriert werden und Updates zurück persistieren. Am besten für Sitzungen, die viele Interaktionen umfassen, aber zwischen ihnen untätig sind. Der Container wird während Leerlaufperioden heruntergefahren und wieder hochgefahren, wenn der Benutzer zurückkehrt.
Beispielworkloads umfassen einen persönlichen Projektmanager mit gelegentlichen Check-ins, tiefe Recherche, die über Stunden pausiert und fortgesetzt wird, und einen Kundenservice-Agenten, der die Tickethistorie über Interaktionen hinweg lädt.
Stimmen Sie das Leerlauf-Timeout Ihres Anbieters darauf ab, wie häufig Sie erwarten, dass Benutzer zurückkehren. Das Herunterfahren eines Containers ohne konfiguriertes SessionStore verliert das Transkript damit, daher ist der Store für dieses Muster erforderlich, nicht optional.
Das Muster basiert auf der Wiederaufnahme einer Sitzung nach ID mit einem angehängten gemeinsamen Store:
SessionStore-Schnittstelle und Referenzadapter.
Multi-Agent-Container
Führen Sie mehrere SDK-Unterprozesse in einem Container aus. Am besten für Agenten, die eng zusammenarbeiten müssen, beispielsweise Multi-Agent-Simulationen, bei denen die Agenten in einer gemeinsamen Umgebung miteinander interagieren. Geben Sie jedem Agenten sein eigenes Arbeitsverzeichnis, damit sie die Dateien des anderen nicht überschreiben, und isolieren Sie das Einstellungsladen, damit pro-AgentCLAUDE.md-Dateien nicht über Agenten hinweg durchsickern. Siehe Multi-Tenant-Isolation für die spezifischen Optionen.
Container bereitstellen
Container-basiertes Sandboxing
Führen Sie das SDK in einem sandboxierten Container aus, um Prozessisolation, Ressourcenlimits, Netzwerkkontrolle und ein kurzlebiges Dateisystem zu erreichen. Mehrere Anbieter spezialisieren sich auf sandboxierte Container-Umgebungen, die zum Modell des Agent SDK passen. Fragen, die Sie bei der Wahl eines Anbieters beantworten sollten:- Wer betreibt die Sandbox: Ein Sandbox-as-a-Service-Anbieter betreibt die Infrastruktur für Sie, während selbst gehostete Optionen Ihnen Software zur Verfügung stellen, die Sie auf Ihren eigenen Systemen ausführen können.
- Cold-Start-Latenz: Wie lange dauert es von „Sandbox erstellen” bis „bereit, die erste Anfrage zu akzeptieren”. Kurzlebige Muster benötigen Sub-Sekunden-Starts. Langfristige Muster tolerieren mehr.
- Persistenter Speicher: Ob der Anbieter dauerhafte Volumes oder nur kurzlebige Festplatte anbietet. Das Hybrid-Muster benötigt dauerhaften Speicher irgendwo, ob in der Sandbox oder daneben.
- Preismodell: Pro-Sekunde, Pro-Anfrage oder pauschale stündliche Abrechnung. Pro-Sekunde-Preisgestaltung eignet sich für bursty kurzlebige Workloads. Stündlich eignet sich für langfristige Sitzungen.
- Netzwerk: Unterstützung für benutzerdefinierte Egress-Regeln, ausgehende Proxys und privates VPC-Peering für regulierte Umgebungen.
- Modal Sandbox, mit einer Demo-Implementierung
- Cloudflare Sandboxes
- Daytona
- E2B
- Fly Machines
- Vercel Sandbox
Laufzeit-Abhängigkeiten
Der Container benötigt nur die Laufzeit Ihres SDK:- Python 3.10+ für das Python SDK oder Node.js 18+ für das TypeScript SDK
- Beide SDK-Pakete enthalten eine native Claude Code-Binärdatei für die Host-Plattform, daher ist keine separate Claude Code- oder Node.js-Installation für die erzeugte CLI erforderlich
Ressourcen
1 GiB RAM, 5 GiB Festplatte und 1 CPU pro Agent ist ein angemessener Ausgangspunkt für eine neu gestartete Instanz. Der Speicherverbrauch wächst mit der Sitzungsdauer und der Tool-Aktivität, daher sollten Sie für die Sitzungslängen und Parallelität dimensionieren, die Sie tatsächlich benötigen, anstatt für die untätige Baseline. Siehe Skalierung und Parallelität, um zu erfahren, wie Sie Agents pro Host berechnen.Netzwerk
Das SDK benötigt ausgehende HTTPS zuapi.anthropic.com oder zu Ihrem regionalen Endpunkt des Anbieters, wenn Sie auf Bedrock oder Vertex ausführen. Wenn Ihre Agents MCP-Server oder externe Tools verwenden, benötigen sie auch ausgehenden Zugriff auf diese Endpunkte. Für die Produktion leiten Sie ausgehenden Datenverkehr durch einen Egress-Proxy, der Domain-Allowlists durchsetzt, Anmeldeinformationen injiziert und Anfragen protokolliert. Siehe Sichere Bereitstellung für das vollständige Muster.
Für eingehenden Datenverkehr stellen Sie einen HTTP- oder WebSocket-Port auf dem Container bereit. Ihre Anwendung verarbeitet Client-Anfragen auf diesem Port und ruft das SDK intern auf; der Unterprozess selbst lauscht nicht im Netzwerk.
Produktionsbedenken behandeln
Arbeiten Sie diese Entscheidungen durch, bevor Sie einen selbstgehosteten Agenten bereitstellen.Sitzungs- und Zustandspersistenz
Der standardmäßige lokale Datenträger geht bei Neustart, Herunterskalierung oder Verschiebung auf einen anderen Knoten verloren. Für jede Sitzung, die ein Benutzer fortsetzen möchte, spiegeln Sie das Transkript mit einemSessionStore-Adapter auf dauerhaften Speicher. Siehe Referenzimplementierungen für S3-, Redis- und Postgres-Adapter sowie eine Konformitätssuite für Ihre eigenen.
Drei Dinge, die Sie über das Verhalten von SessionStore wissen sollten:
- Nur Transkripte:
SessionStorespiegelt Transkripte, nichtCLAUDE.md-Speicherdateien oder andere Arbeitsverzeichnis-Artefakte. Mounten Sie ein gemeinsames Volume oder synchronisieren Sie diese separat. - Spiegelung, keine Ersetzung: Der Unterprozess schreibt zuerst auf die lokale Festplatte, und der Store erhält eine Kopie jedes Batches. Lokale Schreibvorgänge bleiben maßgeblich.
mirror_error-Meldungen: Wenn der Store ablehnt oder eine Zeitüberschreitung auftritt, gibt das SDK eine{ type: "system", subtype: "mirror_error" }-Meldung aus und setzt die Abfrage ohne Wiederholung fort. Warnen Sie vor diesen, wenn die Store-Dauerhaftigkeit wichtig ist.
Observability
Agent SDK-Agenten sind langlebige Prozesse, die Werkzeugaufrufe über viele API-Roundtrips hinweg spawnen. Ohne Telemetrie können Sie nicht sehen, welche Werkzeuge ausgeführt wurden, wie lange sie dauerten oder wo eine Sitzung stecken blieb. Das SDK erbt die OpenTelemetry-Konfiguration aus der Umgebung. Legen Sie die OTEL-Umgebungsvariablen auf Container- oder Orchestrator-Ebene fest, damit jederquery()-Aufruf Spans, Metriken und Log-Ereignisse an Ihren Collector exportiert. Das folgende Beispiel aktiviert OTLP-Export für alle drei Signale. CLAUDE_CODE_ENHANCED_TELEMETRY_BETA ist nur für Traces erforderlich; lassen Sie es weg, wenn Sie nur Metriken und Logs exportieren.
".env'
Authentifizierung und Geheimnisse
Drei Authentifizierungsbedenken sind zum Zeitpunkt des Hostings wichtig:- Anthropic API: Der Unterprozess liest
ANTHROPIC_API_KEYaus seiner Umgebung. Stellen Sie es von Ihrem Secret Manager bereit, oder setzen SieANTHROPIC_BASE_URL, um Modellaufrufe durch einen Proxy zu leiten, der den Schlüssel außerhalb des Containers injiziert. Siehe Credential Management für das Proxy-Muster und SDK-Übersicht für unterstützte Authentifizierungsmethoden. - Eingehend: Setzen Sie Authentifizierung an einem Gateway vor dem Agent-Container. Der Agent sollte vorauthentifizierte Anfragen erhalten und sollte nicht die Komponente sein, die Benutzer-Token validiert.
- Ausgehende Werkzeuge: Halten Sie Werkzeug-Anmeldedaten aus der Agent-Umgebung. Leiten Sie ausgehende Aufrufe durch einen Proxy, der API-Schlüssel injiziert, nachdem die Anfrage den Container verlässt. Der Agent tätigt den Aufruf; der Proxy fügt die Anmeldedaten hinzu.
Skalierung und Parallelität
Jede Sitzung läuft in ihrem eigenen Unterprozess, daher ist die Parallelität auf einem Host durch die Anzahl der Unterprozesse begrenzt, die sein RAM halten kann. Dimensionieren Sie jeden Host mit dieser Formel:sessionId an einen Container. Eine angeheftete Sitzung trifft immer wieder auf denselben Container und daher auf denselben laufenden Unterprozess, bis er entfernt oder der Container neu gestartet wird.
Große Fanouts von gleichzeitigen Subagenten aus einer einzelnen Sitzung können API-Ratenlimits treffen. Teilen Sie die Arbeit in kleinere Batches auf, anstatt eine breite Verteilung auszugeben.
Kosten
Die Anthropic-Token-Kosten dominieren typischerweise die Container-Infrastrukturkosten um eine Größenordnung oder mehr. Ein minimal bereitgestellter Container läuft ungefähr $0,05 pro Stunde, während eine einzelne lange Agent-Sitzung Dollar in Token ausgeben kann. Siehe Kostenverfolgung für Token-Buchhaltung pro Sitzung.Multi-Tenant-Isolation
Das standardmäßige SDK-Verhalten liest Einstellungen undCLAUDE.md-Speicherdateien aus dem Dateisystem. In einem gemeinsamen Container, der mehrere Mandanten bedient, können diese Dateien den Kontext eines Mandanten in die Sitzung eines anderen Mandanten durchsickern lassen.
Um Mandanten in einem gemeinsamen Container zu isolieren:
- Übergeben Sie
settingSources: []in TypeScript odersetting_sources=[]in Python, damit keine Dateisystem-Einstellungen geladen werden. - Setzen Sie
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1inenv. Auto Memory bei~/.claude/projects/<project>/memory/wird unabhängig vonsettingSourcesin den System-Prompt geladen. Siehe Was settingSources nicht steuert für die anderen Eingaben, die bedingungslos geladen werden. - Zeigen Sie
CLAUDE_CONFIG_DIRauf ein mandantenspezifisches Verzeichnis, damit Mandanten die globale Konfiguration~/.claude.jsonnicht teilen. - Verwenden Sie ein mandantenspezifisches Arbeitsverzeichnis. Übergeben Sie
cwdexplizit bei jedemquery()-Aufruf. - Wenden Sie mandantenspezifische Egress-Regeln bei Ihrem Proxy an, wie z. B. unterschiedliche ausgehende IPs, Anmeldedaten oder Domain-Allowlists, damit ein kompromittierter Mandant keine Daten über die ausgehende Richtlinie eines anderen Mandanten exfiltrieren kann.
tenantDir und configDir so, dass jeder Mandant einen Pfad erhält, den kein anderer Mandant lesen kann. In TypeScript ersetzt env die Unterprozess-Umgebung, daher verteilen Sie ...process.env, um geerbte Variablen wie PATH und ANTHROPIC_API_KEY zu behalten. In Python wird env auf die geerbte Umgebung zusammengeführt.
Bekannte Einschränkungen
Berücksichtigen Sie diese in Ihrem Bereitstellungsdesign.| Einschränkung | Was zu tun ist |
|---|---|
| Kein Sitzungs-Timeout auf oberster Ebene | Eine Sitzung läuft nicht automatisch ab. Legen Sie maxTurns in Options fest, um zu begrenzen, wie viele Tool-Use-Rundläufe der Agent durchführt, bevor er stoppt. |
| Speicherwachstum über lange Sitzungen | Begrenzen Sie die Sitzungslänge oder recyceln Sie Subprozesse regelmäßig. Siehe Skalierung und Parallelität. |
| Große parallele Subagent-Ausfächerungen können Ratenlimits treffen | Teilen Sie die Arbeit in kleinere Batches auf, anstatt eine breite Verteilung auszugeben. |
| Keine Wanduhr-Frist pro Subagent | Begrenzen Sie jeden Subagent mit maxTurns in seiner AgentDefinition. Nur für Hintergrund-Subagenten setzt CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS einen Stall-Watchdog, der aktiviert wird, wenn ein run_in_background-Subagent keine Ausgabe mehr produziert; dies ist keine Gesamtlaufzeit-Frist. |
Nächste Schritte
- Hosting-Cookbook: Notebook-Anleitung mit bereitstellbarem Code für Docker, Modal und Kubernetes.
- Sitzungsspeicher: Persistieren Sie Transkripte über Hosts hinweg mit einem
SessionStore-Adapter. - Observability: Exportieren Sie OTEL-Traces, Metriken und Protokolle zu Ihrem Collector.
- Sichere Bereitstellung: Netzwerkkontrollen, Verwaltung von Anmeldedaten und Isolationshärtung.
- Kostenverfolgung: Token- und Kostenabrechnung pro Sitzung.