claude CLI che possiede una shell, una directory di lavoro e file di sessione su disco. Ospitarlo non è come ospitare un wrapper API senza stato. Ogni agente in esecuzione è un processo di lunga durata legato allo stato locale, il che influenza il modo in cui allochi risorse, persisti sessioni e scala tra tenant.
Questa pagina copre l’auto-hosting sulla tua infrastruttura. Per Dockerfile distribuibili e manifesti Kubernetes, consulta il hosting cookbook.
Se non hai bisogno di controllo dell’infrastruttura, isolamento personalizzato o del tuo piano dati, considera invece gli Managed Agents: un’API REST ospitata dove Anthropic esegue l’agente e la sandbox, quindi la tua applicazione invia eventi e riceve i risultati in streaming senza infrastruttura di hosting da gestire.
Il modello subprocess
Ogni decisione di hosting su questa pagina deriva da come l’SDK esegue l’agente. Quando il vostro codice chiamaquery(), l’SDK genera un processo claude CLI separato e comunica con esso tramite stdio. Quel subprocess possiede la shell, la directory di lavoro e i transcript della sessione JSONL su disco locale.
cwd distinto nelle opzioni della chiamata query() di ogni sessione:
await di livello superiore, quindi salvateli come file .mts o impostate "type": "module" in package.json.
Stato che risiede su disco locale
Tre tipi di stato agente risiedono nel filesystem del container per impostazione predefinita. Nessuno di essi sopravvive a un riavvio del container, a una riduzione della scala o a uno spostamento su un nodo diverso.
Per persistere i transcript tra host, configurate un adattatore
SessionStore. I file di memoria e altri artefatti della directory di lavoro necessitano della loro propria strategia di archiviazione, come un volume montato o una sincronizzazione di object-store.
Per informazioni su come sessioni, ripresa e fork funzionano a livello API, consultate Sessions.
Scegliere un modello di sessione
Questi quattro modelli coprono il ciclo di vita della sessione: quanto tempo vive un container rispetto alle sessioni che serve. Per dove il container viene eseguito, il manuale di hosting contiene codice distribuibile per Docker locale, Modal e Kubernetes. Scegliere un modello di sessione qui e una destinazione di distribuzione dal manuale.Sessioni effimere
Creare un container per ogni attività dell’utente e distruggerlo quando l’attività si completa. Ideale per attività una tantum. L’utente può ancora interagire con l’IA mentre l’attività si sta completando, ma una volta completata il container viene distrutto. I carichi di lavoro di esempio includono l’indagine e la correzione di bug, l’estrazione di fatture e ricevute, la traduzione di documenti e la trasformazione di media. Il container esegue un punto di ingresso una tantum che legge l’attività dalla variabile di ambienteTASK_PROMPT, chiama l’SDK ed esce.
subtype è success quando l’attività si completa entro il limite di turni. Se l’attività raggiunge il limite di 20 turni, il subtype del messaggio di risultato è error_max_turns e la chiamata query() genera un errore dopo averlo restituito, quindi avvolgere il ciclo in un blocco try se il container deve uscire correttamente. Vedere Gestire il risultato per i sottotipi di errore.
Sessioni a lunga durata
Eseguire istanze di container persistenti, spesso ospitando più processi SDK per container, per servire il lavoro in corso. Ideale per agenti che intraprendono azioni autonome, servono contenuti o gestiscono flussi di messaggi ad alto volume. I carichi di lavoro di esempio includono un agente di posta che triage e risponde alla posta in arrivo, un generatore di siti che ospita un sito modificabile per utente attraverso le porte del container e un chatbot che gestisce il traffico continuo da una piattaforma come Slack. Il container espone un endpoint HTTP o WebSocket e mappa ogni sessione attiva a una query di lunga durata e al sottoprocesso dietro di essa. In TypeScript, utilizzarestreamInput() per aggiungere turni a una sessione attiva e startup() per pre-riscaldare i sottoprocessi prima del traffico in arrivo. In Python, utilizzare ClaudeSDKClient per mantenere una sessione aperta tra i turni. Dimensionare il container in modo che possa contenere il numero massimo di sessioni simultanee in memoria.
Sessioni ibride
Container effimeri che si idratano da unSessionStore all’avvio e persistono gli aggiornamenti indietro. Ideale per sessioni che si estendono su molte interazioni ma rimangono inattive tra di esse. Il container si spegne durante i periodi di inattività e si riaccende quando l’utente ritorna.
I carichi di lavoro di esempio includono un gestore di progetti personali con check-in intermittenti, ricerca approfondita che si interrompe e riprende nel corso di ore e un agente di supporto clienti che carica la cronologia dei ticket tra le interazioni.
Regolare il timeout di inattività del provider in base alla frequenza con cui ci si aspetta che gli utenti ritornino. Lo spegnimento di un container senza un SessionStore configurato perde la trascrizione con esso, quindi lo store è richiesto per questo modello, non facoltativo.
Il modello si basa sulla ripresa di una sessione per ID con uno store condiviso allegato:
Container multi-agente
Eseguire più sottoprocessi SDK all’interno di un container. Ideale per agenti che devono collaborare strettamente, ad esempio simulazioni multi-agente in cui gli agenti interagiscono tra loro in un ambiente condiviso. Assegnare a ogni agente la propria directory di lavoro in modo che non sovrascrivano i file l’uno dell’altro e isolare il caricamento delle impostazioni in modo che i fileCLAUDE.md per agente non si diffondano tra gli agenti. Vedere Isolamento multi-tenant per le opzioni specifiche.
Provisioning del container
Sandboxing basato su container
Esegui l’SDK all’interno di un container sandbox per l’isolamento dei processi, i limiti delle risorse, il controllo della rete e un filesystem effimero. Domande a cui rispondere quando si sceglie un provider:- Chi gestisce la sandbox: un provider sandbox-as-a-service gestisce l’infrastruttura per te, mentre le opzioni self-hosted ti forniscono il software da eseguire sulla tua infrastruttura.
- Latenza di cold-start: quanto tempo passa da “crea una sandbox” a “pronto ad accettare la prima richiesta”. I modelli effimeri necessitano di avvii inferiori al secondo. I modelli a lunga durata tollerano di più.
- Archiviazione persistente: se il provider offre volumi durevoli o solo disco effimero. Il modello ibrido necessita di archiviazione durevole da qualche parte, sia nella sandbox che accanto ad essa.
- Modello di prezzo: fatturazione al secondo, per richiesta o a tariffa oraria fissa. La tariffazione al secondo si adatta bene ai carichi di lavoro effimeri bursty. La tariffa oraria si adatta bene alle sessioni a lunga durata.
- Networking: supporto per regole di egress personalizzate, proxy in uscita e peering VPC privato per ambienti regolamentati.
Dipendenze di runtime
Il container necessita del runtime del linguaggio del tuo SDK:- Python 3.10+ per l’SDK Python, o Node.js 18+ per l’SDK TypeScript
- Sia gli SDK TypeScript che Python includono un binario Claude Code nativo per la maggior parte delle installazioni, e la CLI generata non necessita di un’installazione separata di Node.js. Vedi la nota di installazione della guida rapida per le installazioni che necessitano di un’installazione separata di Claude Code nativo.
Risorse
1 GiB di RAM, 5 GiB di disco e 1 CPU per agente è un punto di partenza ragionevole per un’istanza appena avviata. L’utilizzo della memoria cresce con la durata della sessione e l’attività degli strumenti, quindi dimensiona in base alle lunghezze di sessione e alla concorrenza di cui hai effettivamente bisogno piuttosto che alla baseline inattiva. Vedi Scaling and concurrency per scoprire come calcolare gli agenti per host.Rete
L’SDK necessita di HTTPS in uscita versoapi.anthropic.com, o verso l’endpoint regionale del tuo provider quando eseguito su Amazon Bedrock o sulla piattaforma agente di Google Cloud. Se i tuoi agenti utilizzano MCP servers o strumenti esterni, necessitano anche di accesso in uscita a quegli endpoint. Per la produzione, instrada il traffico in uscita attraverso un proxy di egress che applica allowlist di domini, inietta credenziali e registra le richieste. Vedi Secure Deployment per il modello completo.
Per il traffico in ingresso, esponi una porta HTTP o WebSocket sul container. La tua applicazione gestisce le richieste dei client su quella porta e chiama l’SDK internamente; il sottoprocesso stesso non ascolta sulla rete.
Gestire i problemi di produzione
Affrontate queste decisioni prima di distribuire un agente self-hosted.Persistenza della sessione e dello stato
Il disco locale predefinito viene perso al riavvio, al ridimensionamento o al trasferimento a un nodo diverso. Per qualsiasi sessione che un utente si aspetta di riprendere, eseguire il mirroring della trascrizione su un archivio durevole con un adattatoreSessionStore. Vedere Reference implementations per gli adattatori S3, Redis e Postgres e una suite di conformità per il vostro.
Tre cose da sapere su come si comporta SessionStore:
- Solo trascrizioni:
SessionStoreesegue il mirroring delle trascrizioni, non dei file di memoriaCLAUDE.mdo di altri artefatti della directory di lavoro. Montate un volume condiviso o sincronizzate quelli separatamente. - Mirroring, non sostituzione: il subprocess scrive prima su disco locale e l’SDK invia una copia di ogni batch all’archivio. La trascrizione locale di una sessione nuova sopravvive all’esecuzione; un’esecuzione ripresa dall’archivio elimina la sua copia locale alla fine, quindi l’archivio contiene l’unica copia durevole. Vedere Dual-write architecture.
- Messaggi
mirror_error: quando l’SDK non riesce a consegnare un batch all’archivio, scarta il batch, emette un messaggio{ type: "system", subtype: "mirror_error" }e continua la query. Avvertite su questi se la durabilità dell’archivio è importante. Vedere Mirror writes are best-effort per il comportamento di retry e timeout.
Osservabilità
Gli agenti Agent SDK sono processi di lunga durata che generano chiamate di strumenti su molti round-trip API. Senza telemetria non potete vedere quali strumenti sono stati eseguiti, quanto tempo hanno impiegato o dove una sessione si è bloccata. L’SDK eredita la configurazione OpenTelemetry dall’ambiente. Impostate le variabili di ambiente OTEL a livello di container o orchestrator in modo che ogni chiamataquery() esporti span, metriche ed eventi di log al vostro collector. L’esempio seguente abilita l’esportazione OTLP per tutti e tre i segnali. CLAUDE_CODE_ENHANCED_TELEMETRY_BETA è richiesto solo per le tracce; omettetelo se esportate solo metriche e log.
.env
Autenticazione e segreti
Tre problemi di autenticazione sono importanti al momento dell’hosting:- Anthropic API: il subprocess legge
ANTHROPIC_API_KEYdal suo ambiente. Forniscilo dal vostro gestore di segreti, oppure impostaANTHROPIC_BASE_URLper instradare le chiamate del modello attraverso un proxy che inietta la chiave al di fuori del container. Vedere Credential management per il modello proxy e Setup in the SDK quickstart per i metodi di autenticazione supportati. - In entrata: mettete l’autenticazione a un gateway davanti al container dell’agente. L’agente dovrebbe ricevere richieste pre-autenticate e non dovrebbe essere il componente che convalida i token dell’utente.
- Strumenti in uscita: mantenete le credenziali degli strumenti fuori dall’ambiente dell’agente. Instradare le chiamate in uscita attraverso un proxy che inietta le chiavi API dopo che la richiesta esce dal container. L’agente effettua la chiamata; il proxy aggiunge la credenziale.
Scaling e concorrenza
Ogni sessione viene eseguita nel suo proprio subprocess, quindi la concorrenza su un host è limitata da quanti subprocess la sua RAM può contenere. Dimensionate ogni host con questa formula:sessionId. Una sessione fissata continua a colpire lo stesso container, e quindi lo stesso subprocess in esecuzione, fino a quando non viene rimossa o il container non si riavvia.
Costo
Il costo dei token Anthropic in genere domina il costo dell’infrastruttura del container di un ordine di grandezza o più. Un container minimamente provisioning funziona approssimativamente a $0.05 all’ora, mentre una singola sessione di agente lungo può spendere dollari in token. Vedere Cost tracking per la contabilità dei token per sessione.Isolamento multi-tenant
Il comportamento predefinito dell’SDK legge le impostazioni e i file di memoriaCLAUDE.md dal filesystem. In un container condiviso che serve più tenant, questi file possono far trapelare il contesto di un tenant nella sessione di un altro tenant.
Per isolare i tenant all’interno di un container condiviso:
- Passate
settingSources: []in TypeScript osetting_sources=[]in Python per saltare le impostazioni utente, progetto e locali. - Impostate
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1inenv. Auto memory a~/.claude/projects/<project>/memory/si carica nel prompt di sistema indipendentemente dasettingSources. Vedere What settingSources does not control per gli altri input che si caricano incondizionatamente. - Puntate
CLAUDE_CONFIG_DIRa una directory per tenant in modo che i tenant non condividano la configurazione globale~/.claude.json. Quando ogni directory di configurazione serve una directory di lavoro e non condividete unSessionStoretra i tenant, potete anche impostareCLAUDE_CODE_PROJECT_DIR_NAMEinenvper mantenere i percorsi delle trascrizioni sotto di esso brevi. Richiede Agent SDK TypeScript v0.3.234 o successivo, oppure Agent SDK Python v0.2.140 o successivo. - Utilizzate una directory di lavoro per tenant. Passate
cwdesplicitamente su ogni chiamataquery(). - Applicate regole di egress per tenant al vostro proxy, come IP in uscita distinti, credenziali o allowlist di domini, in modo che un tenant compromesso non possa esfiltare dati tramite la politica in uscita di un altro tenant.
tenantDir e configDir in modo che ogni tenant ottenga un percorso che nessun altro tenant possa leggere. In TypeScript, env sostituisce l’ambiente del subprocess, quindi diffondete ...process.env per mantenere le variabili ereditate come PATH e ANTHROPIC_API_KEY. In Python, env viene unito sopra l’ambiente ereditato.
Limitazioni note
Pianificate questi aspetti nella progettazione della vostra distribuzione.Risolvere i problemi di distribuzione
Utilizza questa sezione quando un agente che funziona sulla tua macchina non riesce in un servizio distribuito. Ogni elemento sottostante nomina un errore e collega la voce che lo copre:- CLI non trovata all’avvio del servizio: in Python, un contenitore o un gestore di servizi esegue la tua applicazione con un
PATHdiverso dalla tua shell, quindi un’installazione che funziona localmente non è visibile al processo. In TypeScript, la compilazione dell’immagine ha saltato le dipendenze opzionali dell’SDK, oppurepathToClaudeCodeExecutablepunta a un file che non esiste nell’immagine. Vedi Claude Code non trovato. - CLI presente nell’immagine ma non si avvia: Claude Code non può avviarsi da un binario che non corrisponde all’architettura del contenitore o a libc, oppure da un file che ha perso il permesso di esecuzione nella compilazione dell’immagine. Vedi Impossibile avviare Claude Code.
- Il processo Claude Code esce durante l’esecuzione: l’errore che la tua applicazione riceve dipende dal linguaggio dell’SDK e dal fatto che la CLI abbia segnalato un risultato di errore per primo. Le voci sotto Uscita del processo CLI coprono ogni messaggio.
Passaggi successivi
- Hosting cookbook: procedura dettagliata del notebook con codice distribuibile per Docker, Modal e Kubernetes.
- Session storage: mantieni i transcript tra gli host con un adattatore
SessionStore. - Observability: esporta tracce OTEL, metriche e log al tuo collector.
- Secure deployment: controlli di rete, gestione delle credenziali e indurimento dell’isolamento.
- Cost tracking: contabilità dei token e dei costi per sessione.