Passa al contenuto principale

OpenAI Agents API vs Claude Managed Agents: il loop agentico hosted, a confronto

Avanzato
What you'll learn
  • Mappare i due stack sulle stesse quattro primitive — agent, environment, session, events — e sapere dove ogni vendor ha messo le manopole
  • Scrivere la chiamata minima di creazione sessione su entrambi i lati e sapere quali campi appartengono all'agente e quali alla sessione
  • Confrontare ciò che differisce nella pratica: modalità di permesso, dove vivono i segreti, budget rigidi, policy di rete, residenza dei dati, la bolletta della sandbox
  • Capire cosa fanno davvero la 'compaction automatica' e il 'tool search' al tuo contesto e alla tua cache, e perché lo stream SSE su entrambi i lati ha bisogno di una strategia di riconnessione
  • Scegliere un runtime per carico di lavoro: Agents API, Managed Agents, il tuo loop sulla Responses/Messages API, oppure Agents SDK / Claude Agent SDK

Per due anni il "loop agentico" — chiama il modello, esegui il tool, aggiungi il risultato, ripeti, compatta quando è pieno — è stato qualcosa che ogni team ricostruiva da zero. Anthropic lo ha spostato lato server l'8 aprile 2026 con Managed Agents. Il 10 settembre 2026 OpenAI ha fatto lo stesso con la beta pubblica della Agents API, che è, per sua stessa definizione, l'harness di Codex dietro una singola chiamata API. Se hai usato la beta multi-agente della Responses API di luglio, questo è il livello successivo: non "il modello lancia subagenti dentro una richiesta" ma "OpenAI tiene vivo l'intero agente per ore, con un filesystem".

I due prodotti ora si assomigliano in modo impressionante. Questa pagina li mette fianco a fianco, con le vere forme delle richieste, e dedica gran parte dello spazio ai punti in cui differiscono — perché sono quelli che decidono se al tuo agente si può affidare una credenziale di produzione.

Stesse quattro primitive, due vocabolari​

ConcettoOpenAI Agents APIClaude Managed Agents
La definizioneagent (model, instructions, tools, server MCP, multi_agent) — inline su ogni sessioneOggetto Agent, persistito e versionato via POST /v1/agents; le sessioni lo referenziano per id
Dove girano i toolenvironment — openai_hosted o self_hostedOggetto Environment — cloud o self_hosted
La cosa in esecuzionesession — durevole, riprendibile, ore o giorniSession — durevole, streamma eventi, fissata a una versione dell'agente
Il filoevents + items; stream o webhookevents; stream SSE su /v1/sessions/{id}/events/stream
Gate della betaheader OpenAI-Beta: agents=v1header managed-agents-2026-04-01
Worker self-hostedcodex exec-server si connette in uscita via WebSocket con una executor key ristrettaEnvironmentWorker.run() oppure ant beta:worker poll con una environment key

★ L'unica differenza strutturale che plasma tutto il resto: OpenAI mette la definizione dell'agente inline sulla sessione; Anthropic ne fa un oggetto di prima classe, versionato. Sul lato Anthropic, se ti ritrovi a passare model, system o tools a sessions.create(), l'hai capito al contrario — quelli vivono su agents.create(), e le sessioni in esecuzione restano fissate alla versione con cui sono partite. Sul lato OpenAI non c'è nessun registro di agenti da tenere in ordine, ma non c'è nemmeno niente che ti dica quali delle tue 400 sessioni in esecuzione girano sulle istruzioni della settimana scorsa.

La chiamata minima su ciascun lato​

OpenAI, Python, sandbox hosted, streaming:

from openai import OpenAI

with OpenAI() as client:
    with client.beta.agents.sessions.create(
        agent={
            "model": "gpt-6-astra",
            "instructions": "Write clean code, run it, and report the actual output.",
            "tools": [{"type": "web_search"}],
            "multi_agent": {"enabled": True, "max_concurrent_subagents": 3},
        },
        environment={
            "type": "openai_hosted",
            "packages": {"python": ["pandas==2.2.3"]},
            "network_policy": {"access": "restricted", "allowed_domains": ["pypi.org", "files.pythonhosted.org"]},
        },
        input="Create tree.py that prints a readable tree of /workspace, run it, paste the output.",
        stream=True,
    ) as events:
        for event in events:
            print(event.to_json(indent=None), flush=True)

Anthropic, due chiamate perché l'agente è un oggetto a sé:

import anthropic

client = anthropic.Anthropic()

agent = client.beta.agents.create(
    model="claude-fable-5-1",
    system="Write clean code, run it, and report the actual output.",
    tools=[{
        "type": "agent_toolset_20260401",
        "configs": [{"name": "web_fetch", "allowed_domains": ["pypi.org"]}],
    }],
    permission_policy={"mode": "auto"},
)

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id="env_...",
    budget={"type": "limit", "max_list_cost": {"amount": "500", "currency": "USD"}},
)
# then stream GET /v1/sessions/{id}/events/stream and send user events

Entrambi ti risparmiano il loop, la compaction, la logica di retry e il provisioning della sandbox. Entrambi ti fatturano i token più quello che costa la sandbox. Ora le differenze.

Dove differiscono​

1. Permessi: OpenAI non ne ha a livello API (per ora); Anthropic ha tre modalità​

Managed Agents include una permission policy per agente e per toolset MCP con tre modalità: always_allow (default per i tool propri dell'agente), always_ask (default per i toolset MCP — la sessione si mette in pausa a ogni chiamata finché un client non invia un user.tool_confirmation) e, dal 10 settembre 2026, auto. In auto il server classifica ogni singola chiamata — il tool, l'input di quella chiamata e la sessione fin lì — in esegui, nega o pending_approval. Due chiamate allo stesso tool possono essere giudicate diversamente, ogni evento porta un campo evaluated_permission, e un client non può scavalcare un diniego (una conferma per una chiamata negata restituisce 400).

La Agents API non ha ancora un equivalente. Le tue leve sono la lista dei tool, la policy di rete e l'auth dei server MCP. Se una chiamata deve essere approvata da un umano, lo costruisci nel tuo event loop — oppure usi l'Agents SDK, che è dove la documentazione di OpenAI rimanda per le "approvals".

2. Segreti: vault vs variabili d'ambiente​

La risposta di Anthropic a "come fa l'agente a chiamare un server MCP autenticato" sono i vault: le voci mcp_servers dell'agente dichiarano solo {type, name, url}; le credenziali (mcp_oauth con refresh automatico, static_bearer oppure environment_variable) vivono in un vault agganciato alla creazione della sessione e vengono sostituite in uscita, così il modello non le vede mai.

La sandbox hosted di OpenAI accetta una mappa env di variabili stringa e rifiuta alcuni nomi riservati (PATH, CODEX_*, OPENAI_API_KEY). Tutto il resto che ci metti è leggibile dal codice che l'agente esegue. Va bene per un token di build che ruoti ogni ora; è il posto sbagliato per il refresh token OAuth di un cliente. Per gli environment self-hosted, la restricted key dell'executor può solo connettere environment — non può chiamare il resto dell'API anche se trapela — che è il design giusto, e vale la pena copiarlo.

3. Budget rigidi vs il tuo contatore​

Managed Agents accetta un budget in dollari sulla sessione; quando viene raggiunto la sessione si mette in pausa con budget_reached e accetta solo eventi di settle finché non alzi o rimuovi il tetto. Anche i deployment (sessioni schedulate) accettano budget. Vedi Budget di sessione.

La Agents API non ha un tetto di spesa per sessione nella documentazione di lancio. Hai gli eventi in streaming con l'usage, hai il tempo container, e il tetto lo imposti tu. Su un loop impazzito la differenza è tra "in pausa a 5 $" e "notato in fattura".

4. Policy di rete: entrambi ce l'hanno, a livelli diversi​

La sandbox hosted di OpenAI ha una network_policy con tre stati — enabled (default, a meno che non erediti da un template), disabled e restricted con una lista allowed_domains di 1-100 hostname esatti: niente wildcard, niente porte, niente path, e i target dei redirect e i sottodomini hanno bisogno ciascuno della propria voce. Due gotcha dalla documentazione: i server MCP stdio al momento richiedono enabled, e un environment_template_id salvato cambia il default in "nessuna rete".

Anthropic restringe invece a livello di tool — allowed_domains / blocked_domains / max_content_tokens sulle config dei tool web_search e web_fetch, non sull'environment — e l'egress del tool Bash segue il networking dell'environment. Vedi Restrizioni di dominio per la matrice completa. Se la lezione di GemStuffer è "imponi l'egress nella rete, non nel prompt", la policy restricted di OpenAI è l'implementazione più letterale; quella di Anthropic è più facile da ragionare tool per tool.

5. Residenza e retention dei dati​

La beta della Agents API è solo USA per la residenza dei dati e non supporta Zero Data Retention — e, esplicitamente, usare una sandbox self-hosted non rende una sessione idonea alla ZDR. Managed Agents ti permette di fissare dove gira l'inferenza via model.inference_geo sull'agente o per sessione. Per un carico di lavoro regolamentato questo oggi è decisivo, non una sfumatura.

6. Quanto costa la sandbox​

La sandbox hosted di OpenAI viene fatturata a tariffe container standard, separatamente dai token — al minuto con un minimo di cinque minuti, da circa 0,03 $ per 20 minuti per un container da 1 GB a 1,92 $ per 64 GB (grosso modo da 0,09 $ a 5,76 $ l'ora), secondo i report del giorno di lancio. Le sandbox inattive vengono eliminate dopo un'ora senza attività o keep-alive; quel timeout non è configurabile. I file sotto /workspace/outputs vengono pubblicati come artefatti immutabili al completamento di un turno e sopravvivono alla sandbox. L'environment cloud di Anthropic è un container per sessione, fatturato come compute in aggiunta ai token; controlla la pagina prezzi corrente piuttosto che questo paragrafo.

La prima cosa che uno sviluppatore ha scritto sotto il thread di annuncio di OpenAI è stato un avvertimento a calcolare il costo dei container prima di avviare sandbox in un loop. Prendilo alla lettera: un fan-out di sei subagenti su un'immagine da 16 GB sono sei container.

Le due funzionalità su cui tutti fanno domande​

Compaction automatica. Entrambi i runtime riassumono il contesto precedente man mano che la sessione si avvicina al limite, così una sessione può girare per ore senza che tu scriva il riassuntore. Quello che nessuno dei due farà per te è conservare le cose giuste: se un fatto conta oltre la compaction, scrivilo in un file nel workspace (OpenAI) o in un memory store (Anthropic) invece di fidarti del riassunto. I pattern di harness in Harness per agenti a lunga durata si applicano invariati.

Tool search e programmatic tool calling (OpenAI). Il tool search carica le definizioni dei tool su richiesta invece di infilare ogni schema nel prompt — il che mantiene stabile il prefisso in cache quando hai decine di tool MCP. Il programmatic tool calling, abilitato con {"type": "programmatic_tool_calling"}, permette al modello di scrivere codice che chiama più tool, cicla e filtra i risultati prima che qualcosa torni nel contesto. L'equivalente di Anthropic è il toolset Bash-più-file: il modello scrive semplicemente lo script. Stesso effetto, meno cerimonia, meno struttura.

Subagenti. OpenAI: multi_agent.enabled con max_concurrent_subagents che di default è 6, escluso il coordinatore; i subagenti hanno il proprio contesto, ereditano tool MCP, credenziali e file, ma non possono usare function tool, e gli eventi di coordinamento possono omettere il contenuto dei messaggi — non vedrai le trascrizioni complete dei subagenti nello stream. Anthropic: Managed Agents non espone una manopola simmetrica; componi sessioni, oppure usi i subagenti del Claude Agent SDK lato client. La pagina sul multi-agente nativo ha la matematica dei costi che si applica ancora.

Sei gotcha dalla documentazione, su entrambi i lati​

Guided walkthrough1 of 6
  1. OpenAI: se lo stream si disconnette, recupera la sessione e i suoi item salvati prima di riprovare — un turno completato non significa che ogni tool sia riuscito; cerca agent.session.turn.completed. Anthropic: lo stream SSE non ha replay; a una caduta, GET /v1/sessions/{id}/events, deduplica per event id, poi riconnetti.

Quale runtime per quale lavoro​

La documentazione di OpenAI ora divide la scelta in tre — Agents API quando OpenAI deve gestire l'agente e salvarne i progressi, Agents SDK quando ti serve controllo su deployment, storage e approvazioni nella tua app, Responses API per l'interazione diretta con il modello — e la divisione di Anthropic è Managed Agents vs Claude Agent SDK vs Messages API grezza. Mappato sui carichi di lavoro:

Carico di lavoroScegliPerché
Task lungo di coding / dati in una sandbox usa-e-getta, da minuti a ore, nessun segreto del clienteUno dei due runtime hostedÈ ciò per cui entrambi sono stati costruiti; scegli in base al modello e all'ecosistema in cui vivono già i tuoi server MCP
L'agente tocca un server MCP autenticato di un clienteManaged AgentsI vault tengono la credenziale fuori dalla sandbox; i permessi auto filtrano le chiamate rischiose senza mettere tutto in pausa
Deve girare dentro la tua VPC con il tuo computeUna delle due modalità self-hostedStessa forma: un worker in uscita con una key ristretta. OpenAI ha nove sandbox partner già integrate (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel)
Dati regolamentati, residenza EU o ZDR richiestaManaged Agents, o il tuo loopLa beta della Agents API è solo USA e non idonea alla ZDR
Fan-out di ricerca ampio, molte letture indipendentiAgents API con multi_agentSubagenti nativi con un tetto di concorrenza; più economico da scrivere dell'orchestrazione lato client
Approvazione umana su azioni specificheManaged Agents auto / always_ask, oppure l'Agents SDKLa Agents API oggi non ha una primitiva di approvazione a livello API
Devi vedere e rigiocare tutto ciò che l'agente ha fattoIl tuo loop su Responses / MessagesEntrambi i runtime hosted riassumono o omettono parti della trascrizione

Mettiti alla prova​

Check yourself

0/6
  1. Su quale lato la definizione dell'agente è un oggetto persistito e versionato che le sessioni referenziano per id?
  2. Cosa fa la modalità di permesso 'auto' di Managed Agents?
  3. Imposti network_policy.access a 'restricted' su una sandbox hosted OpenAI con allowed_domains: ['github.com']. Cosa succede quando l'agente fa fetch di api.github.com?
  4. Quale di queste affermazioni è vera per la beta della Agents API al lancio?
  5. Qual è il default di max_concurrent_subagents nella Agents API, e cosa non possono fare i subagenti?
  6. Dove dovrebbe vivere il refresh token OAuth di un cliente perché il modello non lo veda mai?

Fonti e approfondimenti​

Prossimi passi​