Iniciar una sesión

Una sesión es una instancia de agente dentro de un entorno. Cada sesión hace referencia a un agente y a un entorno (ambos creados por separado), y mantiene el historial de conversación a lo largo de múltiples interacciones. Las sesiones siguen un ciclo de vida de dos pasos: primero crea la sesión, luego envía un evento de usuario para iniciar el trabajo. También puedes combinar ambos pasos en una sola llamada con initial_events.



Crear una sesión

Una sesión requiere un ID de agent y un ID de environment. Los agentes son recursos versionados; pasar el ID de agent como una cadena crea la sesión con la versión más reciente del agente.

ant beta:sessions create \
  --agent "$AGENT_ID" \
  --environment-id "$ENVIRONMENT_ID"

Para fijar una sesión a una versión específica del agente, pasa un objeto. Esto te permite controlar exactamente qué versión se ejecuta y escalonar los despliegues de nuevas versiones de forma independiente.

ant beta:sessions create <<YAML
agent:
  type: agent
  id: $AGENT_ID
  version: 1
environment_id: $ENVIRONMENT_ID
YAML



Inicializar la sesión con eventos iniciales

Puedes crear una sesión e iniciar su trabajo en una sola llamada. initial_events es un arreglo opcional de eventos iniciales para enviar a la sesión en el momento de su creación, procesados en orden. Admite eventos user.message y user.define_outcome, y acepta un máximo de 50 eventos. Una lista no vacía inicia el bucle del agente en la misma llamada: la sesión se crea directamente en el estado running, sin ninguna solicitud adicional.

El siguiente ejemplo crea una sesión con un único user.message en initial_events:

SEEDED_SESSION_ID=$(ant beta:sessions create \
  --transform id --raw-output <<YAML
agent: $AGENT_ID
environment_id: $ENVIRONMENT_ID
initial_events:
  - type: user.message
    content:
      - type: text
        text: List the files in the working directory.
YAML
)

# initial_events no se devuelven en la respuesta de creación; lista los eventos
# de la sesión para ver el mensaje sembrado.
echo "Seeded event: $(ant beta:sessions:events list \
  --session-id "$SEEDED_SESSION_ID" \
  --format raw \
  --transform 'data.#(type=="user.message").content.0.text' --raw-output)"

No se acepta ningún otro tipo de evento. Los eventos que responden a un turno del agente (user.tool_confirmation, user.tool_result y user.custom_tool_result) no se aceptan porque aún no existe ningún turno del agente, y user.interrupt no se acepta porque no hay ningún turno que detener. A diferencia de initial_events en un despliegue programado, los initial_events de una sesión no aceptan system.message.

Cada evento en initial_events se valida y se persiste antes de que se devuelva la respuesta de creación, en el orden de la lista, con un ID asignado por el servidor, exactamente como si lo hubieras enviado al endpoint de envío de eventos inmediatamente después de la creación. Las reglas de contenido por evento también son las mismas que en ese endpoint. Una lista vacía equivale a omitir el campo. La validación es de todo o nada: si algún evento no pasa la validación, se rechaza toda la solicitud y no se crea ninguna sesión.

La solicitud de creación se rechaza en los siguientes casos:

Un evento user.define_outcome en initial_events se acepta bajo las mismas condiciones que al enviar uno a una sesión existente; consulta Definir resultados.



Sobrescribir la configuración del agente para una sesión

Puedes pasar agent en tres formas: una cadena con el ID del agente, un objeto de versión fijada (type: "agent") o un objeto de sobrescrituras (overrides). La forma de sobrescrituras cambia partes de la configuración del agente para una sola sesión. Úsala para probar un modelo diferente o conceder una herramienta adicional en una sesión sin versionar el agente. Para la forma de sobrescrituras, establece type en agent_with_overrides y pasa el id del agente y, opcionalmente, una version (omite version para usar la versión más reciente del agente). Luego incluye cualquiera de model, system, tools, mcp_servers o skills con los valores que la sesión debe usar.

Cada campo sobrescribible sigue las mismas tres reglas:

• Omitir el campo: La sesión hereda el valor de la versión del agente a la que hace referencia.
• Establecer el campo en null, o en un arreglo vacío para los campos de lista: La sesión se ejecuta con ese campo vacío. Esta regla se aplica por completo a system y skills. Hay tres excepciones:
  • model nunca se puede vaciar. Una sesión siempre necesita un modelo, por lo que model: null devuelve un error 400 agent_model_required.
  • Vaciar tools devuelve un error 400 cuando los skills efectivos de la sesión no están vacíos, porque los skills requieren la herramienta read. De lo contrario, tools: null y tools: [] vacían el campo.
  • Vaciar mcp_servers devuelve un error 400 cuando los tools efectivos de la sesión todavía contienen un mcp_toolset que hace referencia a uno de los servidores del agente. Sobrescribe tools en la misma solicitud para eliminar esas entradas mcp_toolset y luego vacía mcp_servers.
• Establecer el campo en un valor: El valor reemplaza por completo el valor del agente. Las sobrescrituras nunca se combinan con la configuración del agente, por lo que una sobrescritura de tools debe enumerar todas las herramientas que la sesión debe tener. Hay una excepción:
  • Un nivel de effort dentro de una sobrescritura de model por sesión no se aplica, y dado que la sobrescritura reemplaza por completo el objeto model del agente, el effort propio del agente tampoco se conserva: una sesión creada con una sobrescritura de model se ejecuta con el nivel de esfuerzo predeterminado del modelo. Para ejecutar con un nivel de esfuerzo específico, establece effort en el agente y no sobrescribas model para esa sesión.

Las sobrescrituras se aplican únicamente a la sesión que creas. No modifican el recurso del agente ni crean una nueva versión del agente, por lo que otras sesiones que hacen referencia al mismo agente no se ven afectadas.

En la respuesta, el objeto agent refleja la configuración con la que se ejecuta la sesión después de aplicar las sobrescrituras. Su id y version siguen identificando el agente y la versión a los que se aplican las sobrescrituras. Esto te permite rastrear una sesión hasta su agente base.

El siguiente ejemplo inicia una sesión que sobrescribe el modelo y vacía la indicación del sistema:

# El `agent` de la respuesta es el snapshot resuelto: cada override reemplaza ese
# campo solo para esta sesión, y el recurso del agente conserva su id y versión.
ant beta:sessions create \
  --transform 'agent.{id,version,model,system}' \
  --format json <<YAML
agent:
  type: agent_with_overrides
  id: $AGENT_ID
  model:
    id: claude-sonnet-5
  system: null
environment_id: $ENVIRONMENT_ID
YAML



Fijar la geografía de inferencia para una sesión

Dado que una sobrescritura de model reemplaza por completo el objeto model del agente, también establece o elimina la fijación de inference_geo del modelo para la sesión: una sobrescritura que incluye inference_geo fija la geografía que atiende las solicitudes de modelo de la sesión, y una que lo omite elimina la fijación del agente, de modo que la sesión sigue el default_inference_geo del espacio de trabajo. El valor sobrescrito se valida contra los allowed_inference_geos del espacio de trabajo cuando se crea la sesión.

El siguiente ejemplo inicia una sesión a partir de un agente cuyo modelo no tiene fijación geográfica, fija las solicitudes de modelo de la sesión a la inferencia en EE. UU. incluyendo inference_geo en la sobrescritura de model, e imprime el valor reflejado en el agent.model de la respuesta:

# Reemplaza el `model` del agente por completo: vuelve a indicar `id`, añade `inference_geo` para fijar.
session=$(ant beta:sessions create <<YAML
agent:
  type: agent_with_overrides
  id: $AGENT_ID
  model:
    id: claude-opus-5
    inference_geo: us
environment_id: $ENVIRONMENT_ID
YAML
)
echo "Inference geo: $(jq -r '.agent.model.inference_geo' <<< "$session")"



Establecer un presupuesto de sesión

Para limitar lo que una sesión puede gastar, pasa el objeto opcional budget cuando la crees. Un presupuesto es un tope estricto sobre el costo de lista de la sesión: la plataforma valora todo lo que la sesión consume a las tarifas de lista públicas, y la sesión deja de emitir nuevas solicitudes de modelo una vez que ese total acumulado alcanza max_list_cost. Establece type en limit y asigna a max_list_cost un amount y una currency. amount es un número entero de centavos de dólar estadounidense escrito como cadena, como "2500" para $25.00; la API recibe una cadena en lugar de un número para que nunca se aplique redondeo de punto flotante. USD es la única moneda admitida actualmente. Cuando la sesión alcanza el tope, se pausa y queda inactiva con el motivo de detención budget_reached. El tope se aplica entre solicitudes de modelo, por lo que la solicitud que lo cruza termina primero y el costo de lista final de la sesión puede quedar una fracción por encima del tope. Un presupuesto solo se puede adjuntar en el momento de la creación: puedes cambiarlo o eliminarlo más adelante, pero no puedes agregar uno a una sesión creada sin él.

El siguiente ejemplo crea una sesión con un presupuesto de $25.00; la respuesta refleja el budget en el recurso de la sesión:

curl -fsSL https://api.anthropic.com/v1/sessions \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d @- <<EOF
{
  "agent": "$AGENT_ID",
  "environment_id": "$ENVIRONMENT_ID",
  "budget": {
    "type": "limit",
    "max_list_cost": {"amount": "2500", "currency": "USD"}
  }
}
EOF

Consulta Presupuestos de sesión para saber cómo funciona la aplicación del límite, qué cuenta para el costo de lista y cómo se comportan los presupuestos en sesiones multiagente.



Autenticación MCP mediante vaults

Si tu agente usa herramientas MCP que requieren autenticación, pasa vault_ids al crear la sesión para hacer referencia a un vault que contenga credenciales OAuth almacenadas. Anthropic gestiona la renovación de tokens en tu nombre. Consulta Autenticar con vaults para saber cómo crear vaults y registrar credenciales.

ant beta:sessions create <<YAML
agent: $AGENT_ID
environment_id: $ENVIRONMENT_ID
vault_ids:
  - $VAULT_ID
YAML



Iniciar la sesión

Crear una sesión sin initial_events registra la sesión pero no inicia ningún trabajo; el sandbox del entorno comienza a aprovisionarse tan pronto como se crea la sesión, por lo que la primera llamada a herramienta no tiene que esperarlo. Para delegar una tarea, envía eventos a la sesión usando un evento de usuario. Para proporcionar el primer evento en la solicitud de creación, consulta Inicializar la sesión con eventos iniciales. La sesión actúa como una máquina de estados que rastrea el progreso mientras los eventos impulsan la ejecución real.

ant beta:sessions:events send \
  --session-id "$SESSION_ID" <<'YAML'
events:
  - type: user.message
    content:
      - type: text
        text: List the files in the working directory.
YAML

Consulta Flujo de eventos de la sesión para saber cómo hacer streaming de las respuestas del agente y gestionar las confirmaciones de herramientas.

Consulta Estados de la sesión para conocer los estados por los que pasa una sesión.



Próximos pasos